BT

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:

  1. Check whether Scrum is being done wrong. If so, try doing Scrum correctly instead, and see whether that fixes the problem.
  2. 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.
  3. Give the team time to execute a few sprints and learn from them. The team may solve the problem themselves.
  4. If the previous items provide no relief, adapt Scrum to mitigate or resolve the problem.
  5. 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.

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

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

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!

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT