What Constitutes A High-Quality Agile Transition?

In a number of blog postings, members of the Agile community offer their perspectives on what constitutes a high-quality transition to Agile methods within an organization.

Esther Derby makes a case for applying Agile methods to the Agile transition process itself. According to Derby, an Agile transition is often best managed by applying typical Agile strategies such as learning and adapting, embracing Agile values, and understanding at a deep level how the organization's work is actually done. She writes:

Deterministic planning fails with complex software systems, and it fails with organizational change. Organizations are far too complex, and we need to plan for adaptation, learning, and the fact that the organization will be changing as the plan unfolds.

What are the signs that an Agile transformation is going well? According to Haim Deutsch, a successful Agile organization can be characterized by a number of emotional indicators. These indicators include:

team members feeling focused on their tasks

team members becoming more conscious of how they spend their time

team members feeling proud of their team

testers feeling fully accepted by the team

team members and product owners feeling closer to each other

ScrumMasters feeling proud of their team's accomplishments

team members, product owners, and ScrumMasters feeling more conscious of their capabilities, responsibilities, strengths, and weaknesses

Supposing that an Agile transition doesn't appear to be going well, however, how can it be repaired? Henrik Kniberg offers these steps as one possible remediation path for problems found while implementing Scrum:

Check whether Scrum is being done wrong. If so, try doing Scrum correctly instead, and see whether that fixes the problem.

Check whether the problem is an underlying problem that is just being exposed by Scrum, rather than a problem with the Scrum process itself. For an underlying problem, try addressing the causes of the problem rather than changing Scrum.

Give the team time to execute a few sprints and learn from them. The team may solve the problem themselves.

If the previous items provide no relief, adapt Scrum to mitigate or resolve the problem.

If the problem still persists after adaptation, then perhaps Scrum isn't well-suited for this application. Another process may be better in this situation.

Hi, Udayan. This is Dan Puckett. I'm the author of the original article.

Your point is a good one, and one that I considered while phrasing the article. Personally, I don't consider that Scrum is the only way of doing Scrum, and I don't think I'm alone in this belief. Indeed, Henrik Kniberg's fifth point in his article explicitly points away from Scrum as a process choice.

Henrik and Haim used Scrum as the starting place for their articles, whereas Esther's article seems to be consider Agile methods in general. The reason I put all three of these articles together is that I believe all three articles have valuable contributions to the subject of Agile transformation, not just to Scrum.

I hope this helps clarify my intent. I apologize if my article has given the wrong impression. Suggestions for improved phrasing or different approaches for framing this information are always welcome.

Criticisms of agile in the past include its lack of hard, empirical scientific grounding - it is sometimes called a 'faith based' method. This is especially true for many lean advocates who criticize the anecdotal nature of the arguments promoting agile methods. Even where we consider agile metrics like velocity and burndown, these are usually based on story points, which are a highly subjective measure (the team decides what a story point is - how much work, complexity and risk it incorporates). As an example, agile methods like XP push for shorter and shorter cycles - CI should take less than 10 minutes, deploy several times a day, etc. But there is little in the way of balancing the transaction cost of a cycle (iteration cost) with the benefits of faster feedback and learning. A prominent figure in lean product development, Don Reinertsen, argues the theory of 'economic batch size' used in manufacturing still holds true for creative development tasks - that is, there is an optimal iteration length which balances cost/benefit - shorter is not always better.Above talks about 'emotional indicators' giving a clue to the success of an agile adoption - agile rightly recognizes the centrality of the individual and team in good software development, but I think relying on emotional indicators is taking it a step too far - from a business perspective a happy team is a means to an end, not the end itself. And how we assess success should be based on business value - metrics drive behaviour as well as measuring it. Personally, if I were to tell a CIO I was going to assess success on the basis of how happy his team was, I wouldn't expect to be asked back!