10 Awful Reasons to go Agile
Agile is no magic spell
There are many reasons to work in an Agile way. Organizations may seek ways to adapt to changing insights, increase customer collaboration, and/or improve their focus on value. These are great reasons to go Agile.
However, there are many misconceptions of the benefits of Agile. As a result, people choose Agile approaches for the wrong reasons. Today, I will discuss 10 awful reasons to go Agile.
As always, I’m interested in your feedback. Do you recognize these reasons? Do you know other awful reasons? Let me know in the comments!
1. To go faster
Agile has never been about delivering faster. If anything, Agile may even be slower than traditional approaches. If it’s all about fast delivery, I would recommend doing a thorough analysis, a solid plan and delivering according to the plan. The downside of this, however, is that you may not build what the customer actually wants. Customers may change their opinion on what they want as they learn more.
Agile typically has repeated moments of reflection that will consume time. On top of that, Agile embraces changing requirements which can even lead to rework. The crux is to be on top of changes and minimize wasted effort. This doesn’t make Agile approaches fast. But the upside is that the actual desires make the narrative.
2. To be more efficient
Sadly, I have witnessed Agile implementations that were combined with cost-cutting measures. The typical reason to do this is the false notion that Agile approaches are more efficient.
However, the most important reason to embrace Agile is to be more effective in creating value. This doesn’t automatically mean that Agile also increases efficiency. On the contrary, when people move towards a different way of working, they typically need time and space to adjust. They might even become temporarily less efficient.
Agile may lead to more efficiency. One of the aspects of Agile is to improve the way of working to create value. But this is not always the case and betting on more efficiency is dangerous.
3. As a quick fix
Embracing Agile is a journey. Every organization is unique, so every organization has a different journey. Agile is no quick fix. You can’t simply roll out Scrum, SAFe or any other Agile approach and expect miracles to happen.
People who believe they can quickly fix the organization are others following themselves or fooling the organization they sell their solution.
4. To ignore the actual issues
Agile is not going to solve your organizational issues. On the contrary, it may put a spotlight on them, seemingly making it worse. The reason for this is that many issues will occur more frequently due to the iterative nature of Agile.
In every iteration, teams deal with the slow approval process, the constant unavailability of a crucial stakeholder or the absence of important data to make decisions. Agile makes issues more prominent and also offers ways to deal with these impediments. But if the issues remain ignored, the so-called Agile approach of choice will not help.
5. To have no managers
Agile approaches advocate self-organizing teams that find the best way to achieve the desired results. Teams don’t need managers to tell them how to do their work. But this doesn’t mean they don’t need to work with management or leadership.
Management and leadership should adapt to be effective in an Agile environment. They should be able to set and communicate the company's goals to allow the teams to find the best way to reach these goals. They should be enablers and facilitators by helping teams to be effective Agile teams and help remove barriers to growth.
6. To implement Agile tooling
Unfortunately, Agile is often mixed up with implementing so-called Agile tools, like Jira. Before you know it, these tools have been set up in such a way that they become a burden for the teams. Navigating the tools becomes a time-consuming nightmare and reporting is all about ticking boxes and getting tickets to the status “Done”.
Tooling can be great when it is following the goals of the Agile journey. They should not be the main topic of attention as they will not solve issues with individuals and interaction and collaboration with their customers and users.
7. To avoid long-term planning
There’s a myth that Agile rejects long-term planning. People believe Agile teams only look one iteration ahead (somewhere between 1 week and 1 month). At the end of the Iteration, they plan the next one. With that, these people argue, that Agile doesn’t work with long-term planning.
This is too simplistic. Agile teams indeed expect changes to happen. So they will not have fixed detailed long-term plans. But they need to have a longer-term goal to move towards. After all, without a goal, how can you know you are on the right track? The goal should be focused on the desired outcome, the desired value. These goals can have a target date and teams can use this to assess how the progress towards the goal.
On top of that, most Agile teams work with a backlog that has topics they expect to work on. They may not exactly know when they will do what, but the backlog does reflect how the team expects to reach their goals.
8. To avoid commitment
Another myth is that Agile teams don’t have to commit to things anymore. In the bad old days, teams were forced to commit to delivering according to a dreaded long-term detailed plan. With Agile, they are freed from the shackles and they can excuse themselves by saying the world has changed, impacting their ideas on what to do.
Obviously, the harsh reality of working in a highly competitive environment doesn’t change by using Agile approaches. Teams may not commit to a predefined output. They instead commit to achieving the desired result. They commit to outcome instead of output.
9. To avoid documentation
Another false idea is that Agile does away with documentation. After all, the Agile Manifesto states:
“Working software over comprehensive documentation.”
However, this documentation largely is about everything that is being written down before creating even one line of code. In the early 2000s, it was commonplace to have several phases of requirement gathering, analysis and design before coding started.
The Agile approaches advocate creating smaller chunks of working software to show to the potential users and other stakeholders, learn from this and then determine what to do next. By showing a working product instead of a requirements document people have a better opportunity to determine they like what you create.
Still, most teams need just enough documents to create the piece of product. On top of that, they may need to create other documentation enabling the users to use the product effectively or documentation to comply to legal demands.
10. Agile is better than traditional approaches
My final awful reason for switching to Agile is believing it is better than traditional approaches. However, this is context-specific. Some product environments may be predictable with few expected changes. Using Agile in the context may prove to be a burden with many useless meetings because they don’t fit the need.
And there are many different Agile approaches that work in specific contexts. Some of these may be too heavy for a small team while others may not work with more than 10 teams.
Every approach works in a certain context. The trick is to find or create the best approach that works for your context.
