Ressources
- Clean Agile - p151
- Le burn de l’agilité
Ci dessous vous retrouverez le paragraphe écrit par Robert Martin, je vous suggère également d’aller l’autre ressource Le burn de l’agilité
Transitioning from one culture to another was not easy. Companies needed external help to transform their organization and a huge demand for a new type of professional emerged: Agile coaches. Many Agile certification schemes were created. Some certifications could be obtained by simply attending a two-day training course.
Selling Agile processes to middle managers was an easy sell—they all wanted software to be delivered faster. “Engineering is the easy part. If we fix the process, engineering will be fixed,” managers were told. “It’s always a people problem.” And they bought it. Managers manage people, and as long as they are in charge, they are happy to have their direct reports working faster.
Many companies truly benefited from their Agile transformation, and today they are in a much better place than they were before. Many of these companies can deploy software to production multiple times a day and have business and technology truly working as a single team. But that is certainly not true for many others. Managers willing to push developers to work faster are using the full transparency of the process to micromanage them. Agile coaches with neither business nor technical experience are coaching managers and telling development teams what to do. Roadmaps and milestones are being defined by managers and forced upon development teams—developers can estimate the work, but they are pushed hard to fit their estimates into the imposed milestones. It is fairly common to see projects that have all their iterations and respective user stories already defined by management for the next 6 to 12 months. Failing to deliver all story points in a sprint means developers must work harder in the next sprint to make up for the delay. Daily standup meetings become meetings where developers must report progress to product owners and Agile coaches, detailing what they are working on and when they will be done. If the product owner thinks developers are spending too much time on things like automated tests, refactoring, or pairing, they simply tell the team to stop doing it.
Strategic technical work has no place in their Agile process. There is no need for architecture or design. The order is to simply focus on the highest-priority item in the backlog and get it done as fast as possible—one highest-priority item after another. This approach results in a long sequence of iterative tactical work and accumulation of technical debt. Fragile software, the famous monoliths (or distributed monoliths for the teams trying micro services) become the norm. Bugs and operational problems are popular discussion topics during daily standup meetings and retrospectives. Releases to production are not as frequent as the business expected. Manual testing cycles still take days, if not weeks, to complete. And the hope that adopting Agile would prevent all these issues is gone. Managers blame developers for not moving quickly enough. Developers blame managers for not allowing them to do the technical and strategic work needed. Product owners do not consider themselves as part of the team and do not share the responsibility when things go wrong. The us-versus-them culture reigns dominant.
That is what we call the Agile Hangover. After years of investment in an Agile transformation, companies realized that they still have many of the problems they had before. And Agile is being blamed for that, of course.