Consistently, one of the greatest challenges of agile transformation is simply understanding what it is. Agile cannot do everything, but it can do quite a lot. The lines of division are unclear to outsiders looking in, or to those new to the methodology. In an article for Scrum Alliance, Pratik Kothari gets specific about what agile can and cannot do.
In scheduling, agile enables better feature development prioritization in projects, and when paired with an MVP (minimum viable product) mindset, it can result in faster software releases. Agile does all of this by way of the project insight it provides to teams. But on that same token, having more insight does not guarantee the eradication of scheduling issues. It only offers teams better opportunities to address them.
During prioritization itself, the frequent conversations with the business make stakeholders more confident that project teams will deliver the desired product. However, while agile better enables teams to understand stakeholders’ intent, it does not guarantee stakeholders will not change their minds frequently about what they want. If stakeholders ask for too many or simply unreasonable changes, agile has no mechanism to account for that. Talks must be had so that the business understands what are reasonable shifts in priority, from a product development perspective.
Ultimately, a tight connection with the business reduces the need for rework, which in turn reduces the costs of a project. But when a team is becoming freshly agile, the business should not expect instant cost decreases; costs will likely increase instead, because the team will be operating in an awkward new way. Only after a few months, when agile becomes natural, will the team realize its true potential and bring down its costs of development.
Aside from cost reduction, another often hailed perk of agile is how it empowers teams by way of increased autonomy. But autonomy alone does not create job satisfaction. Trust, encouragement, and the opportunity to take on new challenges are also important in creating job satisfaction.
Lastly, when it comes to tracking progress, agile typically does this through daily standups, kanban boards, etc. The traditional methods of tracking progress do not jell as well with it:
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.
You can view the original article here: https://www.scrumalliance.org/community/articles/2018/january/what-agile-can-and-cannot-do