What Constitutes A High-Quality Agile Transition?

by Dan Puckett on Mar 14, 2011 |

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.

Related Editorial

Five Key Practices to Agile ALM

Agile Practices to Improve Project Management Organization (PMO) Effectiveness

Enterprise-class API Patterns for Cloud & Mobile

Agile Maturity Model Applied to Building and Releasing Software

Agile workshops and training

Related Sponsor

Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Is Agile = Scrum? by Udayan Banerjee Posted

Re: Is Agile = Scrum? by Dan Puckett Posted

Means to an end or end in itself? by Esther Derby Posted

Anecdotal in the Extreme! by Colm O'hEocha Posted

Is Agile = Scrum? by Udayan Banerjee

It is interesting to note that there is an implicit assumption in this post that agile refers to Scrum. Is it a valid assumption today?

setandbma.wordpress.com/2011/01/24/what-makes-a...

Re: Is Agile = Scrum? by Dan Puckett

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.

Thanks for posting!

Re: Is Agile = Scrum? by Dan Puckett

In my reply, "...Scrum is the only way of doing Scrum..." should read "...Scrum is the only way of doing Agile...". Ironic mistakes are a specialty of mine.

Means to an end or end in itself? by Esther Derby

Hi, Dan -

You might also be interested in this article, Achieving Agility: Means to an End or End in Itself? (www.estherderby.com/2010/06/achieving-agility-m...).

The point isn't which flavor of agile you pick, rather, it's about becoming more effective at delivering valuable software.

The path depend on where you start from; the choice of method depends on the nature of the work.

e

Anecdotal in the Extreme! by Colm O'hEocha

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!