Agile is not a “just add water” proposition—applying it on top of an otherwise unchanged business will not guarantee success. Some businesses and some projects are better inherently suited to agile than others, and failing to acknowledge this could cause bad friction during agile implementation. In an article for InfoQ, Ronit Eliav identifies six ways agile projects can get stuck in place:
- Unsustainable system architecture
- Limitations of existing tools
- Culture gap
- Difficulty scaling up
- Not the right type of project
- Bogged down by collaboration
Agile Held Back
Knowing how much design documentation is enough to get started with an agile project is seldom straightforward, but everyone can agree that “too little” can be as dangerous as “too much.” Eliav finds that, when there is not enough design, teams run the risk of just piling old code on top of new code, ultimately resulting in an inflexible architecture that cannot pivot. When there is no long-term ability to pivot, there is no agile.
Another issue is with the agile tools that teams use. Particularly, most of the tools are intended to be used by software engineers, not business users, and they cannot satisfy enterprise IT’s aims. Additionally, many of the tools are large, unwieldy, and full of unused features. Problems will occur if someone goes to use these tools without recognizing their glaring limitations.
Culture gap is a third barrier Eliav identifies. There are programmers who enjoy being mole people that work in isolation, but agile demands teamwork and communication. Lone wolves must be persuaded to work with the rest of the team, because there is no future for loners in the changing IT landscape.
That being said, proper collaboration—especially over long distances with remote teams—is its own can of worms. Eliav discusses an ideal case of collaboration over distances:
When teams from different physical locations, and often different geographies use the communication tools to capture all the different types of information and accelerate information flows, they often make improvements in both the process and the final outcome, making the teams stronger and more productive. Tools prevent processes from being stuck because one test group is behind or a business user involved in user acceptance testing went on vacation without remembering to run procedures. Since communication and coordination – both internally and with customers – is often difficult due to logistics, locations and timing, an end-to-end communication framework for agile team collaboration is essential to help people work together more effectively.
Remote agile projects have many moving parts. Trying to scale agile in large organizations has a multitude more moving parts. Now you have to juggle interdependent teams while remembering to keep marketing and sales (among others) in the loop. If there is no consistent approach developed to handling coordination, then alignment will be scattershot.
Finally, one more way that agile can go wrong is when it is used on a project that just does not need it. For instance, a small project with a tight scope and few risks likely does not need agile. Additionally, Eliav notes that some management structures do not mesh well with agile. With the example of pyramid structures, “it is often the case that the number of teams working together end up being larger than what is really needed for the project.”
For even more warnings, you can view the original article here: https://www.infoq.com/articles/ways-agile-static