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.
Is Agile = Scrum?
Re: Is Agile = Scrum?
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?
Means to an end or end in itself?
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.
Anecdotal in the Extreme!
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!