Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
What Constitutes A High-Quality Agile Transition?
Posted 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.
- This article is part of a featured topic series on Agile
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Five Key Practices to Agile ALM
Improving Software Delivery Cycles: Pre-requisites and Inhibitors
Agile Practices to Improve Project Management Organization (PMO) Effectiveness
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Is Agile = Scrum?
by
Udayan Banerjee
Posted
Re: Is Agile = Scrum?
by
Dan Puckett
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
-
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... -
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! -
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.
-
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 -
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!
5 comments
Watch Thread Reply