“Hitting the wall” with your Agile Adoption? Try adding technical practices…

This is a great post that uses the familiar metaphor of the gym and physical fitness to apply to adopting Agile. I’ve seen the pattern described here too often.

Developers start out the first three sprints and produce production ready software every iteration. It seems like everything is going well. Then under the gun of the ScrumMaster to keep their velocity high, they build up technical debt (like sprinters developing lactic acid) by not paying attention to technical excellence and practices that will maintain a sustainable pace. This slows their speed to a halt until they clean up their technical practices and adopt test driven development, continuous integration, mercilous refactoring.

The question for me is not whether or not this pattern occurs, but how to best introduce Agile so teams can recognize when it is happening and address it.

On the Scrum side, folks like Mike Cohn suggest introducing Scrum first (using the iterative or requirements first pattern described in his outstanding Agile Adoption presentation). This has the advantage of allowing the team to self organize around the practices needed to maintain agility.

On the XP side, folks like James Shore recommend introducing the 12 XP Practices first (Mike Cohn describes this as “Technical Practices First” Pattern). The tradeoffs to Jim’s approach is that it is costly to start with all 12 practices from day one. Teams may reject the approach altogether, while getting none of the benefits of the practices. But the teams that do will have sustainable pace and agility.  The benefits to Iterative first or requirements first are that the teams learn how to self organize and undergo the cultural change necessary for bottom up commitment based planning. The downside is that somce Scrum is silent on engineering principles, and focuses on developing a self healing system rather than prescriptive practices. The down side to this is that teams may fail. Yet if they are using the retrospective and sprint review effectively, however, effects of failure are minimized (since they can inspect and adapt) and teams will have the added benefit of becoming a self healing system.

My experience is that the end state of having Scrum teams that us XP is a great combination. The paths to getting there are varied, and I’d rather a group learn how to think for itself then think implementing a set of practices will make them Agile. It’s the mind set shift to Agile principles that is important in my opinion, not the discrete practices used.  This prevents Agile and Scrum from becoming yet another prescriptive methodology that says “do these steps in these ways and you will be guaranteed success”.   What do you think? Have you experienced the pattern described above?

This entry was posted in Uncategorized and tagged , , . Bookmark the permalink.

Leave a Reply