If you visit an Agile conference these days, it’s hard not to hear talks like “Scrum within a RUP project” or “Agile in a Traditional Organization.” From a dogmatic Agile point of view, this reminds me a little bit of a veggie-stuffed beef recipe promoted as vegetarian food. From a management perspective, it means that you are only exploiting about 10% or 20% of the potential of Agile . Many consultants would consider such an implementation as failed, and I’m sure you will find a lot of “Scrumbut” practices in these organizations.
But does that necessarily mean such an approach is bad? I don’t think so. To the contrary, a fast judgment of these approaches often mirrors the arrogance of the judge rather than his or her capability to carefully consider the circumstances. I know this is a provoking statement within the Agile community, so let’s dig into it.
Turning an organization into an Agile one means a change in the organizational mindset and value system. This can’t be done by a single decision or step but needs all members of the organization to embark on a long — and perhaps never-ending — quest. When an organization starts on its Agile quest, it is usually not the whole organization that starts to move but one team, one department, or one manager who catches fire and begins with a change. The nature of the journey is therefore the existence of a mixed organization, with some parts being Agile and others being more traditional. The major theme of the first steps on this journey is compromise; one of their major success factors is pragmatism.
Many teams have gone through this and feel proud of what they have accomplished in the face of a hostile environment. They have gone through significant pain and found their way to deal with it. Looking down at them with the perspective that they are still lacking is both arrogant and counterproductive.
However, there’s a fallacy around these approaches: If you start to credit the pains you still experience to Agile, and if you argue that “Agile only works in the books,” and you had to “make adjustments to make it work in reality,” you have perhaps fallen prey to some misunderstandings about Agile. The misunderstanding I encounter most often is the impression that problems you did not see before starting with Agile were not there. If you cannot prioritize your features, the problem is usually the management issue that no one is really in charge or empowered to take the responsibility. If you cannot build, integrate, and test within one sprint, your test and build processes are often way too slow and ineffective. And, if you find after two months that you will miss your deadlines, you can be quite sure that you would also have missed the deadlines with a traditional approach — only you would have received the bad news later, leaving you less time to react.
This does not necessarily mean that you have to solve all of these problems. Being able to deliver faster with fewer bugs may already be a huge step forward for your organization. So there is value in “Agilebut,” although there is less value than in full Agile.
You can compare the situation with methadone therapy for heroine addicts: methadone mitigates the social effects of heroine addiction and allows patients to step out of drug-related crimes and stabilize their social life so they can gather strength and support before taking the final step of a physical opiate withdrawal. Regardless of whether they actually do this final step, a legal methadone treatment significantly improves the patients’ situation.
But there’s also a downside to methadone therapy: it leads to a physical addiction to methadone that’s even stronger than that of heroine. The symptoms of withdrawal are so strong they can even endanger the life of the patient. Hence, the withdrawal from methadone usually has to be done under intensive care and narcotics.
If you embed Agile into a traditional structure, be aware that you have to compromise. Be proud of what you have accomplished but don’t forget to strive for the “complete picture.” My personal recommendation is to regularly invite external impulses about where you still could benefit from “more Agile.”