What Agile Can and Cannot Do
A journey worth understanding
4 January 2018
Agile is a relatively new way to direct software development that has been gaining momentum in the IT industry. Many organizations are adopting Agile practices, blindly trusting that the method will be able to solve all their issues. However, it is not a magic pill that will solve the problems of the organization. It is indeed a mindset shift and a big, positive step toward software development excellence. However, nothing will be automatically solved. By following Agile practices, you will recognize early indicators of problems that you can solve before they become too big or complex.
Let’s talk about what Agile can and cannot do for several common software development problems.
The project schedule is one of the major pain points in software development. Many project schedules overrun, which ultimately results in missed market opportunities and a negative return on investment. Many teams shift into Agile in hopes that their schedule overruns will be solved.
What Agile can do: Because your development iteration will be small, you can mitigate your risks by prioritizing only the required set of features. A powerful strategy is to complete the minimum required features and go to market quickly to gain the most market share. Also, with this strategy, you can release features fast and provide value to your customers much earlier in the development lifecycle. In the current method, you might be releasing once in every three to six months, but if you transition to Agile, you can release more frequently.
What Agile cannot do: In Agile, you gain insight into your project schedule so that you can make the required changes in priority to control the project timeline. It is unrealistic to expect that your team will never run into scheduling issues once you train them in any Agile method. If you feel that it is taking too long to complete feature work, reduce the number of items that are not required and make sure that only the required tasks get done. With Agile’s short iterations, it is possible to know how the team is progressing and what the current schedule looks like.
By gaining insight into the project schedule, you will have opportunities to make the required changes that are more important for the business. However, this insight will not directly protect you from schedule overruns, and it is your responsibility to recognize scheduling problems early and mitigate the risks. Even after adopting Agile, if you face a scheduling problem, identify any opportunities to make course corrections. Although Agile gives you early insight, it is your responsibility to solve the problem.
Businesses are dynamic, and it is next to impossible for the business team to lock down priorities for the next year or beyond. This was a common problem before Agile; many projects developed feature X when the business team was expecting feature Y, or they found that feature X was no longer relevant to the product.
What Agile can do: You can more frequently change priorities that make sense to business. The business team will feel more confident about what is being developed and that it will meet their expectation. You can reduce waste almost immediately because of frequent interactions with business. If you determine at the end of the cycle that the team applied the wrong implementation, it will cost more to fix that scenario than it would have if the misjudgment had been identified earlier in the cycle.
What Agile cannot do: The ability to change priorities frequently can be rewarding as well as disconcerting, because business might change its mind and make many changes that will ultimately increase costs. Educate your business stakeholders to prioritize the right features, or at minimum establish a structure in which a thoroughly scrutinized backlog is prioritized.
We need to recognize that prioritizing is a way of supporting the work and should be carefully applied. If it is not, it will create churn for the development team, resulting in waste. Transitioning to Agile will not solve your problem of constantly shifting priorities, but it will enable you to tackle the changes more efficiently.
If you have ever faced a situation in which, even after being Agile, you were not getting anything done, review your backlog. Were you able to give clear direction to the team with the appropriately prioritized backlog? You have the power to support the business by accommodating changing business needs, so this capability should be used wisely. However, having the capability does not mean that you must continually change the requirements. More frequent changes are symptomatic of a product owner who is reluctant to identify or solidify the requirements.
Cost is one of the crucial aspects of any software development project, and if cost is not handled appropriately, it will heavily impact the project’s profitability. The goal of many organizations is to handle cost efficiently by transitioning to Agile.
What Agile can do: Agile empowers you to change feature priority early in the development cycle, which will enable the business to maximize profit. You can increase cost savings by delaying features that are not required. Also, one of the goals is to release frequently, which means that you are tapping the market early. Identifying issues early on reduces the cost of development. Finding issues late in the development cycle will increase costs.
What Agile cannot do: We should recognize that Agile teams in the early days of adoption need constant coaching and time to settle down. Therefore, we should be ready to invest in that initial cost. The notion that the team will be productive from day one is an unrealistic expectation. In fact, the team can take even a few months to adjust before delivering at their maximum potential. In your early days of adoption, you will see a spike in cost, so prepare for it.
In Agile, you can reduce your rework and provide what is needed for business. If you feel that you are not getting what is expected, despite the training and coaching, wait for some time and let the team settle down. Examine your original intention of wanting to be Agile, communicate to your coach and team about expectations, design a realistic plan by when you can see results, and let the team find its own path to excellence. Have faith in your team and be patient during the first step of being Agile.
No organization likes to run projects without using an appropriate method to monitor progress and ensure that the team remains aligned with the original goals.
What Agile can do: There are various metrics available in Agile for tracking progress. Attending daily stand-ups or visiting the whiteboard will give you a current and true picture of the progress.
What Agile cannot do: If you have used traditional ways to collect metrics or have viewed color-coded weekly and monthly reports, then you will be disappointed after transitioning to Agile. You will certainly miss your reports. Agile is a more collaborative approach whereby you must make an effort to attend Agile ceremonies to get the true status or progress of the project.
In Agile, there are more practical ways to gain insight into the current progress of the project. It is more of a collaborative effort in that it encourages you to frequently interact with team members. Relying on those color-coded reports, which depend on the person who creates them, may not be a true representation of the progress.
Ensuring team satisfaction
Team satisfaction is one of the huge benefits of being Agile. Individuals who are engaged and motivated give better results, and attrition in the team is reduced. Team members will feel connected to each other and challenged by their goal to meet business expectations.
What Agile can do: Agile allows autonomy for the team members. By signing up for what they really would like to work on, they can try new challenges. When members sign up for an objective, they feel committed to it.
What Agile cannot do: Even after adopting Agile, Agile cannot motivate your team. You must also trust your team to tackle new challenges. Trust is a crucial factor in the success of any team. Do not get in their way, and let them explore their own transition and path.
After transitioning to Agile, are you still forcing team members to sign up for objectives? Are you not trusting them to try new things? If your answers are yes, then think about changing your approach. Your team members might already be demotivated, feeling that Agile is not working for them. What is stopping you from empowering the team to sign up for its own commitments?
Every organization has its own goals and expectations when transitioning to Agile; however, you must strive to identify and resolve problems. The transition to Agile is a mindset shift. When you understand the power of being Agile, you will find answers and simple, workable solutions. It is a journey and a change, which is always hard. Embrace the change and enjoy your Agile journey. You will not regret it.
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
Current rating: 4.7 (3 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.