Agile Advice - Working With Agile Methods (Scrum, XP, Lean)

Everywhere I go, there are three practices that make the biggest difference in overall productivity for teams and organizations. All three practices are part of agile methods such as Scrum and Extreme Programming, but you don’t need to be doing these methods to take advantage of these practices. All of them are relatively inexpensive, and the return on investment for these practices is HUGE!!! Without further ado…

1. A Proper Team Room

This is astonishing: you can expect a 60% boost in team productivity from this single practice! The cost of re-stacking your cubes or office spaces is trivial compared to the benefits. If you are going to do this, do it right! Do the research, hire an agile coach or consultant, but make sure it is done well. One organization I worked with was very excited about their new team room setup. They had a nice open-concept layout with lots of windows etc. But they had also made some big mistakes including that all the developers on a single team would have a low wall separating them from each other. Because of poor layout that would block communication paths, their new setup would actually be worse than their old setup! Some research has shown that you can expect as much as a doubling of productivity (reference). This is one practice you don’t want to let your competitors pick up before you do! Here are some tips on agile team room setup.

2. Short Iterations

Once you have set up your team room, it is critical for your team to have something to do! The fastest way to get your team doing something is to start using short cycles of work (iterations, sprints) to deliver valuable results such as working software. Many software development projects use iterations that are two weeks long or even a month long. I strongly recommend iterations that are only one week long. Again, the benefits are incredible: your team will move through the stages of team development (forming, storming, norming and performing - reference) much more quickly than with longer iterations or no iterations… thus leading to high productivity much sooner. The value here is in the time gained. This chart demonstrates how this works:

The short iterations provide a certain type of pressure that forces team and project crisis to happen quickly. However, because iterations deliver working, valuable results, the pressure is not demoralizing, instead it motivates teams to get through the crisis and reach the norming and performing stages of development quickly. Again, to make this work, there are some critical success factors including methods of allowing team commitment, self-organizing and obstacle removal.

3. Test Driven Development

There is a myth that speed and quality are mutually exclusive. This comes from the idea that you need to slow down to make stuff high quality or that you need to sacrifice quality in order to go fast. It is true that initially you might get gains through these approaches. The really amazing thing happens when you try, deliberately and systematically, to do both high speed and high quality work. In software development this is best done through test driven development. In informal polling I’ve done with teams I’ve worked with, test driven development produces a noticeable long-term productivity gain as well as a simultaneous increase in developer and end user satisfaction due to a substantial reduction in defects discovered after the code leaves the developers. I have seen teams doing this that reduce defect rates to 5% (or less!) of what they once were prior to test driven development… while at the same time delivering projects faster than expected. Since substantial expense is squandered on defect management (tools, support teams, user training, lost productivity, etc.) and since staff turnover is also high in IT and high-tech, the results of test driven development on the bottom line are substantial.

Benefit of All Three Practices

If a team and an organization adopt these practices, get through the initial cost of learning them, then I would like to suggest that your teams can easily double their productivity if not more. For a team of 5 people working on a 100 day project this amounts to shortening the project to 50 days (save $200,000) or get twice as much work done. Clearly, an organization that adopted these practices and perfected them would save huge amounts of money and would be able to crush any competitors not doing this.

Previously I wrote a more general treatment of the benefits of agile and an article that lists other resources discussing the benefits of agile.

Any discussion of benefits should at least say a few words about how exactly to measure those benefits! However, I’m out of time. How do you measure the benefits of agile?

Hey folks, if you found this useful, could you please “Digg” and “Reddit” this article?  Thanks!

Not getting the benefits of agile? Consider the Agile Clinic!

Scrum Study Guide, “The Best Tool for New ScrumMasters”, is now available at Scrum Study Guide. This guide is designed to be an editable tool for helping ScrumMasters do their jobs effectively. With the Scrum Study Guide you are able to keep track of the rules of Scrum, to keep structured notes on your own job as the ScrumMaster, to maintain a list of online reference material, to assess the progress of your team, and to organize the obstacles you are working on.  It also contains a wealth of reference information for learning along the way.

This is the project I’ve been working on for the last several months that has reduced my output here on Agile Advice.  It represents a huge investment of my time as well as several other people who have assisted me in this including Paul Heidema and Garry Berteig.  Purchasing the Scrum Study Guide, aside from its usefulness as a tool itself, will also give you substantial discounts on other services offered by Berteig Consulting Inc.  Finally, if you like it, you can help to share it by letting us know who should get a discount on their purchase of the Scrum Study Guide.  Enjoy!

This might be impossible, but I was thinking that it would be cool to have a single reference of all the possible agile practices.  Obviously, since “agile” is not a single defined method, we must take the word “comprehensive” with a bit of humor (or a grain of salt).  I’ve attached a spreadsheet that represents my first draft (it’s in OpenOffice.org format so that you don’t have to worry about me spreading viruses - if you want it in MS Office format, email me at mishkin@berteigconsulting.com).  I’ve split the practices up into several sections including: “Agile Skeleton”, “Common Practices”, “Basic Scrum Practices”, “Optional Scrum Practices”, “Extreme Programming Practices” and “Lean Practices”.  I’ve stopped there because I’m not an expert on other agile methods such as Crystal, Agile Unified Process or Feature Driven Development.  I imagine that this list will be useful for teams to do self-assessment and to think about ways they might improve.  Perhaps it could be used in a retrospective setting.  Berteig Consulting coaches use something similar to this to assess the effectiveness of their engagement with clients.  If you think of practices I’ve missed or other potential uses for a list like this, let me know in the comments.  My intention is to convert this to a wiki and make it available under a Creative Commons license once it is a little more refined.

Agile Practices List (OpenOffice format - 68KB)

Mike Cohn has written an excellent article that covers a number of different options that can be taken when someone in an organization desires to implement an agile method.  These Patterns of Agile Adoptions are described as three sets of contrasting options:

1. Start Small vs. Go All In
2. Technical Practices First vs. Iterations First
3. Stealth Mode vs. Public Display

A few weeks ago, after my last update of the Scrum Rules Cheat Sheet, I decided that it might be a good idea to ask Ken Schwaber about what I had developed… He immediately asked if I had checked it against the rules listed in his book Agile Project Management with Scrum. Of course, I hadn’t. In fact, although I’ve read the book, I neglected to read the appendix in which the rules are contained. So, I read it and updated the cheat sheet. I found that there were a few rules that I was “assuming” because I work with Scrum so frequently. As well, there were a few rules that I actually didn’t remember. The cheat sheet is now getting to the point where I would like to break it into two pages, but then it wouldn’t be a cheat sheet anymore… so with smaller font size… presenting, the new and improved Scrum Rules Cheat Sheet. Here is the original article about the Scrum Rules Cheat Sheet.

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?

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.

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.

(more…)

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.

There are quite a number of agile methods that are being used around the world in many different types of environments. This glossary provides a quick-reference translation between the various terms used in these methods. I have also included terms that may come from other non-agile disciplines that are strongly related.

If you are using terminology in an agile environment that is different from the terms listed here, please add your comment and I will update this list. In particular, I am looking for people with practical experience with DSDM and FDD to contribute their expertise.

(more…)

I created this image for a presentation targetted to management. It’s a good high-level overview of what goes on in an Agile Work effort. Feel free to use this or the high res version… just keep the copyright notice on and put a link somewhere in your email/document/presentation/webpage/etc. back to Agile Advice. Suggestions on ways to improve the diagram would be greatly appreciated. I will try to update it… and maybe even get my incredibly talented visual artist brother Alexei to re-do it.

Here’s the high resolution version, good for nice printed material: Agile Work - The Whole Process.

Agile Work consists of seven core practices. These practices form a solid starting point for any person, team or community that wishes to follow the Middle Way to Excellence.

(more…)

Agile Work requires a team to take work items from a prioritized list, break those items into small tasks and then execute those tasks inside of the timebox of an iteration. When first trying agile, many teams have trouble with the task breakdown done in the iteration planning meeting. Here are some hints and tips for making this critical part of the agile process more effective.

(more…)

One of the best ways to go faster is to remove the things that slow you down. This “obstacle removal” is an integral part of many agile methods including Scrum and Lean. Sometimes it is obvious where an obstacle is. There are a few small things that can be done easily to go faster. But to get going really fast, we need to have a deeper understanding of obstacles… and the Art of Obstacle Removal.

(more…)

During the course of an iteration, an agile team is able to track it’s own progress through the use of burndown charts. The team and the process facilitator can use the burndown chart to watch for signs of trouble. As a coach, I find the following five burndown shapes are common indicators of trouble.

(more…)

This page contains a number of links to recommended web sites, books or tools relating to Agile Work. This page will be updated from time-to-time and as this is done, announcements will be posted on the Agile Advice blog. As such, this page will always be “under construction”. If you have links to suggest, I will examine them and put them up in my own time. Please feel free to email suggestions to topics@agileadvice.com.

Update 20070115: 1 new reference!

(more…)

Many people are trying out Agile Work in software development. The current industry climate is one that has focused business stakeholders’ attentions on re-examining their core priorities. Where Agile optimizes on “Time to market”, the offshoring “over-the-wall” approach to software development seeks to optimize on raw dollar cost.

What do you do if your organization is attempting both? There are some good resources on-line about this already, however I have yet to see good case-studies with published figures. Also, much of what’s out there comes in the form of mini-articles that are no more than promotional ads for X proprietary “agile-offshore” solution. Regardless, some of the following may help avoid the worst problems of integrating two quite different approaches.

• Using an Agile Software Process with Offshore Development: by Martin Fowler
• A look at Valtech’s approachfrom within the project. This calls itself a case-study, but no metrics are provided
• The sad and understandable ruminations of Jonathan Nolen on his blog, regarding Agile offshoring and his expectations of the project. These attitudes and cocerns are quite common - this is a good poster for the kind of feeling you might find from developers.
• Vincent Massol’s presentation to Javapolis. No proofs or metrics, though some lessons learned are provided.
• A forrester research article on Agile Outsourcing. Note: this is only the abstract - the article is $350. (I should ask for a commission.
• Some practical advice on agile offshoring from a Thoughtworks fellow.
• Good points about customer proxies that are very applicable to offshoring with agile
• A very good summary of an ongoing conversation about fixed-bid contracts and Agile. It relates to the agile-offshore issue given that often projects are offshoring because of cost-sensitivity, and are thus fixed-bid.
• A look at criteria for choosing offshore partners based on Agile business readiness.
• Article by Scott Ambler on agile outsourcing.