« August 2007 | Main | October 2007 »
September 27, 2007
Other Resources on the Benefits of Agile
Having just finished a substantial series of articles on the Benefits of Agile, I thought it might be good to let you all know about some other ideas about these benefits. I don't agree with everyone who has written on this topic, but of course, you can judge for yourself!
Benefits of Agile as portrayed by VersionOne
Benefits of Agile as portrayed by Exoftware
Agile: Turning on a Dime - blog post by Damon Pool
Business Benefits of Agile Development - blog post
Agile and Transformational Leadership - blog post which mentions four benefits briefly
The Value of Agile - long presentation about many levels of agile benefits
Posted by Mishkin Berteig at 04:17 AM | |
September 24, 2007
Agile Benefits: Five Essential Reasons to Try Agile
Although there many other benefits of agile, and although those provide us with other reasons to try agile, the five essential benefits of agile are:
Rapid Learning - disciplined application of the scientific method to explore the best ways to deliver valuable results.
Early Return on Investment - opportunity to use the results of work starting with the work delivered at the end of the first iteration.
Satisfied Stakeholders - engagement in the process in a way that allows meaningful contributions from all stakeholders.
Increased Control - mechanisms to track/measure and therefore steer the direction that work is going so that it meets goals.
Responsiveness to Change - processes, tools, roles and principles that allow a team and an organization to embrace change rather than reject, control or suffer from change.
These reasons are sufficient and apply to operations work, project work and open-ended research work, whenever humans are involved. The above links take you to more detailed descriptions of each of these benefits.
What are some of the other benefits of agile?
Posted by Mishkin Berteig at 10:47 PM | |
Agile Benefits: Responding to Change
The fact that agile methods increase return on investment, accelerate learning, increase stakeholder satisfaction, and enable better control of work are all an interesting result of this final benefit: responding to change.
Responding to Change
The whole idea of "agile", and one of the primary reasons for the choice of this word is the final item of the Agile Manifesto: "Responding to Change". It is clear that this is one of the distinguishing features of agile as compared to a more traditional waterfall or phase-based approach to working. Not so obvious is that this is also true about agile compared to a more chaotic or ad-hoc way of working.
Agile and Waterfall - Change "Control"
In most waterfall or phase-based approaches to working, change control is a technique used to evaluate change requests and then accept or reject them. The practical consequence of this is that "control" often becomes a euphemism for "prevent at almost any price", and we end up with results that satisfy no-one because life changes.
There are, of course, some changes that are accepted even in a change control environment. These changes tend to be the ones that have both a powerful sponsor and a "wealthy" sponsor. The next problem with change control relates to the fact that change becomes very expensive in a phase-based process. It usually means going back to the "beginning" and re-examining the other requirements, the analysis, the design/architecture, the development/construction, the testing and the impact is necessarily large for all but the most trivial changes.
Agile methods turn this on it's head. By allowing (nay, building in!) change every iteration, every cycle, the team and the organization start to get good at accommodating change. The value of this effect cannot be over-estimated; getting good at doing change is a natural consequence of accepting change all the time in a structured manner, and in fact, leads to all the other four benefits: increased learning, increased ROI, increased stakeholder satisfaction, and increased control. The cost of change stabilizes over time instead of increasing exponentially!
Agile and Chaos - The Illusion of Changability
Unfortunately, I am not aware of any studies that target chaotic (non-process) environments to see what kind of results they have in delivering results. (If anyone is aware of such studies, please let me know in the comments!) That said, I think almost everyone has had some experience in environments where the winds of change were so severe and fickle, and the structures to support working with change were non-existent, that chaos reigned. These environments are almost completely negative: things don't get done in a timely manner nor with an acceptable level of quality.
Often the reason for this lack of structure is about flexibility, needing to work in an environment which is also extremely chaotic. Sometimes its worse though: management or stakeholders are the cause of chaos without understanding the consequences of their actions.
Agile methods put a sufficient structure in place to build some discipline, and still remain adaptable. This sufficient structure is often built by gradual application of various agile practices until there is "just enough". This process does require dedication and will, but because it is gradual, it is often much easier than trying to suddenly put in place a full-scale disciplined process.
As these practices are implemented, the team and organization gradually become better and better at accommodating change.
Agile Benefits: Rapid Learning
Agile Benefits: Early Return on Investment
Agile Benefits: Satisfied Stakeholders
Agile Benefits: Increased Control
Agile Benefits: Responsiveness to Change
Agile Benefits: Summary Article
Posted by Mishkin Berteig at 07:35 AM | |
September 22, 2007
Scrum Rules Cheat Sheet - Updated!
Okay, here's yet another draft of the Scrum Rules Cheat Sheet. I've added two optional rules, a note about Truthfulness as well as re-wording or clarifying a few other rules. This is an update worth checking out! I would love to hear comments from people about how well this is communicating, how useful it is, if there are things missing or if you have any other suggestions for changes. Thanks! This is the original article about the Scrum Rules Cheat Sheet.
Posted by Mishkin Berteig at 04:33 PM | |
September 21, 2007
Team Room Photos
Bill Wake has a great collection of photos of team rooms for agile teams.
Posted by Mishkin Berteig at 05:32 AM | |
September 20, 2007
Agile Benefits: Increased Control
One of the reasons that agile provides stakeholder satisfaction is because of increased control. This increased control is a benefit in its own right. The word "control" must be used carefully... some agile approaches and practitioners are justly wary of the word and its common uses. This particular benefit of agile is often a little surprising to people how have believed the myths around agile that it is a chaotic-anything-goes type method. Let's look at how an agile approach provides more control.
Increased Control
The person responsible for prioritizing the work (the Product Owner, Queue Master, Product Manager) is the locus of business control in an agile environment. This person exercises this control in a number of ways. First and foremost is through the constantly evolving queue of features or results to be delivered by the agile team. Here the Queue Master has final authority based on influence, knowledge, experience and formal appointment. The Queue Master can control the immediate and long-term work of the team through the use of this prioritized, never-frozen list of work. Every iteration, the team will accept the highest priority items according to their capacity (or velocity) and complete those. This fine-grained direction of the team is impossible in a traditional phase-based approach to working where often the "change control" process is a bureaucratic nightmare whose end result is the team preventing the business from getting what it needs.
Clearly there is more control. At what cost? Well, the previous three benefits of agile mentioned indicate that there is no financial cost (in fact there is a benefit), there is no intellectual cost (again there is a benefit), and there is no decrease in satisfaction (yet again, there is a benefit). So what is the cost? There is, unfortunately, one very deep and difficult cost: the team doing the work loses control over deciding what is valuable (cost-benefit). I know that in many IT organizations, this is a terrible political cost to pay for IT management and it is a terrible "status" cost to pay for technical folks.
Fortunately, even these losses are offset by other aspects of the agile process and its benefits... again, around the question of control.
In exchange for taking complete control over value determination, the Queue Master must grant complete control over solution discovery and implementation to the team. Of course, ideally there is close collaboration. However, if there is disagreement, this is the standard dividing line of responsibility in an agile environment. So now, to the benefit of those doing the work, they are given complete control over how to do the work and this can be an incredible benefit: it allows the full run of creativity and problem-solving skills to come into play.
Agile Benefits: Rapid Learning
Agile Benefits: Early Return on Investment
Agile Benefits: Satisfied Stakeholders
Agile Benefits: Increased Control
Agile Benefits: Responsiveness to Change
Agile Benefits: Summary Article
Posted by Mishkin Berteig at 09:17 PM | |
September 17, 2007
Agile Benefits: Satisfied Stakeholders
So far, we've discussed learning and value as benefits of agile. Now we turn to a more human side: satisfied stakeholders. Agile methods provide multiple roads to satisfaction for customers, users, business people, bureaucrats (okay, maybe not _all_ bureaucrats), team members, managers, shareholders, and interested passer-by. There are three primary mechanisms by which this occurs: engagement, trust-building and feedback-control. [UPDATED: added link to explanation of Commitment Velocity]
Satisfied Stakeholders
There are so many different stakeholders for any given project or work effort, it is impossible to make generalizations that apply to them all. This is one reason why methods such as Scrum do not define any roles for the stakeholders. Nevertheless, as a concept, stakeholders are important people to consider when thinking about an agile approach to working. How is this method going to improve the satisfaction of our stakeholders?
Engagement
Some stakeholders are satisfied simply to be involved, to know what's going on, to be part of something that is progressing. They have no need for specific results or specific contributions. Rather, these stakeholders might be looking to learn, trying to increase their influence, or simply curious about the work being done.
Agile methods provide improved engagement for these stakeholders using two simple mechanisms: visibility and frequency of delivery. Visibility comes in that anyone is welcome to come to the demos, to walk through the team room, to examine the burndown charts or task boards, or simply to ask questions of the team members. Frequency of delivery through short iterations gives a stakeholder the opportunity to see progress (or change) on a regular basis. This visible change satisfies engagement simply because of the potential it represents: hope for the future, opportunity to influence.
Trust-Building
Another set of stakeholders are more concerned about results. And not just any results, but reliable, predictable results. Results that you can depend upon. Agile methods are ideally suited to help these stakeholders. The visibility, capacity measurement and commitment aspects of agile methods all help these stakeholders come to understand, rely-upon and ultimately trust the work of the team and the organization.
Here there is a substantial pitfall. There are a few agile practices that _must_ be put in place and followed rigorously in order to develop this trust. First, the team must keep a consistent time box for both duration and effort of work. Every iteration or Sprint must be the same amount of work time. Secondly, the team must use estimation and tracking of tasks that is compatible with "commitment velocity". Thirdly, the team must use iterations short enough that these stakeholders don't get frustrated waiting for the commitment velocity to stabilize. Fourth, the team must get it's work up to a level of quality where defects are rare rather than expected. Finally, the team must be protected from interruptions. Don't forget: two hours can waste two weeks!
All this is not easy, and doesn't happen quickly. Trust is a deep and important quality for both people and organizations so it is worth the investment.
Feedback-Control
Then there are the contributors. The people who, for various reasons, some legitimate, need to make their mark on the work. This group should include the team members themselves! These stakeholders are interested in providing input into the process, seeing the results of that input, and then being able to have another chance based on those results. Business people want to see the results of their work in the marketplace and use those results to get better. Users of software, consumers of media want to have a say in what the next version looks like. This is the level of active engagement.
Agile methods provide opportunities for active engagement, for feedback and control, through the backlog or queue of work, through the demos, through participation in the team's discussion about the work, and through the visibility of seeing their contributions take effect in "real time".
Now control is obtained through the specific rules of engagement in one's particular agile method. In Scrum, this is through the role of the Product Owner and the Product Backlog, the daily Scrum, etc. Each agile method has a defined set of practices and guidelines about how ideas, suggestions and criticisms are handled. Fortunately, those mechanisms are oriented around visibility, adaptability and speed so that frustrating delays in seeing results are rare.
Other Satisfactions
In some methods, team members are ignored or downplayed as stakeholders. In many agile methods, the importance of the team's well-being is given high priority. Agile methods reduce micro-management, reduce command-and-control management, reduce shoddy workmanship. Agile methods increase the need for creativity and problem-solving, the level of responsibility, support an honest working environment, increase the chances of delivering something that will actually be useful (and used), increase the challenge without causing "death marches". All that said, agile methods are not for everyone!
Agile Benefits: Rapid Learning
Agile Benefits: Early Return on Investment
Agile Benefits: Satisfied Stakeholders
Agile Benefits: Increased Control
Agile Benefits: Responsiveness to Change
Agile Benefits: Summary Article
Posted by Mishkin Berteig at 11:12 PM | |
September 14, 2007
Aides for Complexity - Understanding the Applicability of Agile Methods
In the ScrumMaster training, I include a diagram that has a simple idea: to map the areas of complexity in a problem based on two dimensions: Agreement and Certainty. This diagram is an adaptation of the diagram by Ralph Stacey found in this article called Aides for Complexity by Brenda Zimmerman. This diagram or model can be used to help us understand where and how agile methods can be applied.
In the simplest way possible, if we have both Agreement and Certainty on a problem, then an agile approach is probably applicable, but not necessary. As we move away from that bottom left quadrant of the model, the usefulness of an agile approach increases since agile methods promote learning, careful search, feedback mechanisms, multi-disciplinary work, etc. The top right quadrant, "Chaos" is, like the bottom left, a case of possibly useful, but not a guarantee of any success. So agile methods seem most suited for a broad sweep of the diagram starting from the upper left and going down to the bottom right. Like so:
Posted by Mishkin Berteig at 01:11 PM | |
September 12, 2007
Agile Training - Discount Period Almost Over
The 15% discount offered by Berteig Consulting Inc. on its fall courses is almost expired. If you "Save a Spot" or "Register" for a class on or before Sep. 15th, you will still get the discount. Courses are filling up quickly! Courses are being offered in Toronto, Beijing, Fort McMurray and Ottawa. (UPDATED: guess I missed that link when I first posted this... probably most of you figured it out anyway, but still DOH!!!)
Posted by Mishkin Berteig at 08:30 AM | |
Teams FAQ - Good Reference for Agile Process Facilitators
Christopher Avery, who has written a book about teams called "Teamwork is an Individual Skill", has a good reference page on his web site about teams. From his FAQ, here is his definition of "team":
A team is a group of people whose personal outcomes are obviously linked to a collective outcome -- such as a successful project -- and who work together to maximize collective and individual outcomes. "Team" also refers to the quality of group relationships that allows ordinary individuals to achieve extraordinary results together -- such as a project that surpasses its goals.
Posted by Mishkin Berteig at 05:39 AM | |
September 11, 2007
Agile Benefits: Early Return on Investment
We wouldn't do agile if we didn't think it was better in some way. More and more, I am seeing the adoption of agile methods being driven by business management (rather then engineering). There is a clear reason for this: agile methods offer the possibility of early return on investment compared to other methods of working. This benefit is only one of five essential benefits of agile, but it is one of the most practical and easiest to measure. Therefore it is important to clearly understand how agile methods can deliver this benefit... and how they can fail to do so!
Early Return on Investment
The basic process structure of agile methods consists of the short cycles (iterations, Sprints) of delivery of valuable results. The key word there (aside from "short") is "Valuable". Now in software, "valuable" is relatively easy to define. One definition that works nicely is "Running Tested Features". In other industries or types of work, valuable is defined in some other way.
An agile process delivers valuable results every single iteration. This provides the basis of early return on investment. The organization can then take those results and start to realize their benefits immediately after the very first iteration... ideally... (which we will come back to in a moment).
Here's a graphical contrast between a traditional waterfall approach versus an agile approach that maps value delivered vs. time.
The waterfall project delivers all its value at the end - the red spike. An agile project starts delivering value very early on, increases to a maximum rate of value delivery and then gradually tapers off. The reason for the shape is simple: at the start of the project there is often a fair amount of uncertainty, and some dead-ends are pursued before getting to the really valuable work, and then as that work is completed, the team starts working on lower and lower priority features.
The early delivery of value has an additional benefit. By delivering value early, the time value of that investment is increased. Revenue or cost savings can be realized sooner and therefore more funds are feed up for other investment.
Sounds great, what's the catch?
Agile Pitfall: Not Getting Done
This benefit being realized rests completely on the assumption that the work delivered at the end of each iteration is actually valuable. If for some reason it's not, then this benefit falls apart completely. Most organizations when starting with agile, cannot realize this value immediately because their teams do not deliver completed valuable results. Rather, most organizations are set up so that a team delivers an intermediate result which is useless on its own. Realizing this benefit of agile methods often requires substantial, strenuous, disciplined change in the way that people work, teams are set up, bureaucracy functions, and management supports it all. Perfecting agile is sometimes a lengthy process. Fortunately, the other benefits of agile do not depend so heavily on this assumption.
Agile Benefits: Rapid Learning
Agile Benefits: Early Return on Investment
Agile Benefits: Satisfied Stakeholders
Agile Benefits: Increased Control
Agile Benefits: Responsiveness to Change
Agile Benefits: Summary Article
Posted by Mishkin Berteig at 03:08 PM | |
September 10, 2007
Agile Benefits: Rapid Learning
So what exactly are the benefits of agile? Why are people, teams and organizations so interested in agile processes? What about agile caused it to become a popular and rapidly growing approach to working? I have seen five essential benefits that come from implementing an agile methodology. Here I describe what I think of as the most important benefit of agile: rapid learning.
Rapid Learning
Ken Schwaber tells an anecdote about Scrum:
I was talking with the CIO of a large organization. He complained to me that he would run projects that would take 12 to 18 months and at the end of the project he would get something that he didn't actually want. I told him that I can deliver what he doesn't want in one month.
This is one of the clearest advantages of an agile approach: rapid deliver helps you learn what you truly want and need because you can see actual results instead of "intermediate" results. If you are building software, you can see a working system and get real concrete feedback about it. Users, consumers, and other stakeholders can participate more effectively in determining what you are building.
That's learning about the product... but agile methods also allow you to learn about the process used to build the product. Every time a team of people goes through an iteration of work, they learn how to do that work more effectively, more efficiently. At the end of each iteration there is an opportunity to change the style of work.
Learning about product and learning about process are both accelerated by an agile approach. The shorter your cycles (iterations, Sprints), the faster and more effective your learning.
Unfortunately, the catalyst for learning tends to be crisis or "failure". As Ken's anecdote describes, the first iterations will almost certainly deliver incorrect or poor results. Not only that, but the compressed time cycle is challenging for those not used to it. The crisis comes out in many different ways, and being aware of this feature of agile methods is critical to gaining the benefit of rapid learning.
Agile Benefits: Rapid Learning
Agile Benefits: Early Return on Investment
Agile Benefits: Satisfied Stakeholders
Agile Benefits: Increased Control
Agile Benefits: Responsiveness to Change
Agile Benefits: Summary Article
Posted by Mishkin Berteig at 09:54 AM | |
September 06, 2007
Four Methods of Perfecting Agile
Most organizations start doing agile (or Scrum or lean or ...) imperfectly. Someone introduces a few practices or a manager gets a team some training, or a person starts using agile terminology. And things might improve, particularly with the use of iterations. One of the core ideas of agile methods is to have frequent delivery of valuable results. In fact, this core idea can be used to drive the improvement of an agile process. How? Here are four methods of perfecting agile by expanding the definition of done.
Perfecting Agile
Let's suppose you already understand the benefits of agile. With these benefits in mind, you would like to improve the organization's ability to deliver working, valuable results at the end of every iteration so that you can get better at realizing those benefits. The primary way to do this is by expanding the definition of done. You can imagine this like so:
On a regular basis, the team/organization find ways to bring work done in either the preparation stage or the close stage into every iteration of the agile portion of the project. By moving the work from these "bookend" stages into the iterations, you reduce the amount of time spent in those stages and simultaneously create a more complete delivery every iteration. The "definition of done" is now expanded to contain the results or value delivered by the work that was taken out of the startup and shutdown stages of the project. By expanding the definition of done, each iteration delivers a more "complete" increment of value, and there is less work done before or after iterations in order to plan or deliver. This gradual process allows the team to get better at doing agile.
There are four methods for transferring work from the start and end of a project into the iterations of a project.
Expand the Agile Team's Skill Set
In some ways, this is the simplest and most common approach to expanding the definition of done in the agile portion of a project. By training, coaching, mentoring, re-assigning or hiring, a team's capacity to do work is expanded and used to expand the definition of done. As a simple example, a software developer might learn to use an automated unit testing framework and therefore expand the definition of done to include some amount of unit test coverage of delivered code. In general, training, coaching and mentoring existing team members should be preferred over adding people to the team since the addition disrupts the team's development and can increase communication overhead among team members.
Expand the Agile Team's Authority
Sometimes, a team is not able to do part of the preparation work or close up work because they are not authorized to do so. This may be a policy, a unspoken assumption or a bureaucratic procedure. By giving the team (or some person on the team) the authority to do this work, the team can find ways to do it every iteration instead of having to work through another non-team individual. Again, a simple example here is a situation where a technical person is given permission to talk directly to an end user in order to reduce the need for up-front requirements gathering and analysis and reduce the need for end-of-project user acceptance testing. The obvious challenge to do this is the question of trust (or lack thereof).
Automate an Existing Manual Process
Automation is often given far less than its due consideration. This is primarily be cause automating a process is an investment of work in and of itself. Fortunately, it is often easy to measure the ROI or savings involved with automation. In many agile environments, heavy automation is critical and a huge enabler for very short iterations. Automated testing, automated translation, automated build processes, are all common areas of improvement. Agile teams should always be looking for opportunities to automate their own work. In this way, the automation work itself is transformed from a separate project to a responsibility of the team.
Remove Wasteful Processes
There are some parts of the project preparation work and the project close up work that are pure waste! There is no independent value to these activities, nor is there indirect value to them. An excellent example of this sort of thing is an approval process that _always_ grants approval ("rubber stamping"). One insurance organization I worked with as they were converting to an agile approach discovered that their "second stage" approvals always allowed proposed projects to proceed. Since they often incurred a 4-6 week delay for this approval process, it became obvious that they should "get rid of it". Now, what they actually did is made it so that it became a parallel review process rather than a gated approval process; this was so that the true purpose of the activity could still be met: to help stakeholders understand the projects that were being worked upon. Here, there is no need to take this approval process and somehow work it into every iteration. An agile approach tends to increase the visibility of the work anyway, so it may be discovered later on that the review process can also be done away with.
Agile is often implemented in a limited fashion when it is first adopted by most teams and organizations. The four methods of expanding the definition of done can help a team or organization get better at doing agile and therefore reap more of the benefits of agile. These methods are simple: expand the agile team's capacity, their authority, have them automate manual processes and remove wasteful activities from the process.
Posted by Mishkin Berteig at 03:32 AM | |
September 03, 2007
Scrum Rules Cheat Sheet - Updated!
After feedback and use in a number of different circumstances including training and coaching, Berteig Consulting has made a new Scrum Rules Cheat Sheet (pdf) available. Corrections to the old version include a "Basic Rule" about managing defects, as well as several changes to improve clarity.
Posted by Mishkin Berteig at 02:40 PM | |