Mark Levison has written up a great list of Scrum Smells on his blog Notes from a Tool User. Check them out! There is a lot of great information there. He also asks your help: if you know of common problems with Scrum, see if you can add them to the list!
One of the challenges with agile methods is to get a clear perspective on how to measure process improvements. I recently had a brief discussion with a C-level executive at a small organization about this. His concern was that cycle time was meaningless because it depended so much upon the size of the work package. So how do we use cycle time as a meaningful measurement? What else can we use to measure process improvement?
Let’s look at the difference in measuring cycle time in an agile vs. non-agile environment. Then we’ll get to other measurements.
First, let’s define cycle time. From iSixSigma we have:
Cycle time is the total time from the beginning to the end of your process, as defined by you and your customer. Cycle time includes process time, during which a unit is acted upon to bring it closer to an output, and delay time, during which a unit of work is spent waiting to take the next action.
This definition is important because it gives us a clue about the potential difference between a waterfall vs. agile method of delivering value. Let’s imagine the typical process used in a waterfall environment. The following are the high-level steps:
So from the start of the customer request formally submitted to the time that the fulfillment of that request is made is our true cycle time. There are a few important things to note here. First, there is a queue of work based on requests made but not yet scheduled. There is another queue for work scheduled but not yet started. We know that if we can reduce the size of these queues, we can improve cycle time in a general sense. Second, we know that most organizations of any significant size will have different queues based on the urgency of the request. For example, a high severity bug discovered in the production system of a company’s largest client will be treated differently than a wish list item for a small not-yet-client. These two requests won’t even go in the same queue: the high priority problem will be quickly escalated to a support or development team that can work on it immediately. Third, it is tempting for the development group to measure their local cycle time. This is a Really Bad Idea since it leads to sub-optimizing behaviors. For example, it is easy for the development team to improve their cycle time by sacrificing quality… but this just causes the QA cycle time to increase, and probably the overall cycle time (true cycle time) is affected more than the local improvement in the development group’s cycle time.
Now let’s look at the steps that occur in an ideal agile environment:
So the ideal method of doing agile has a maximum cycle time of two months to deliver from the time a request is made… how many teams are doing this? Not many.
The ideal is extremely difficult to accomplish. Getting to that state requires that the development organization catches up to the business side so that there are zero pending requests at the start of each iteration. It also requires that the business side users and stakeholders are able to articulate their requests so that they are small, and appropriately detailed for the team doing the work.
A realistic agile implementation actually is a lot more messy. Depending on the type of request, the cycle time for a piece of work can vary widely. Some low priority items may take years even in an agile environment. A low priority request is made and approved but then never quite makes it into a project… and then once in a project never quite makes it to the top of the team’s product backlog. This is interesting to look at sometimes, but it points out another important aspect of measuring cycle time: mostly we care about average cycle time (or some other statistically interesting aggregate measure).
The predominant factor in most organizations’ cycle time is the number and size of the queues they use as work is processed. In most organizations there are several queues and most of them contain large numbers of requests or bits of work in process. Queues represent huge amounts of waste. It is easy to see that queue size and cycle time are closely related: the more items in a queue, the longer the cycle time.
This leads to a simple conclusion: regardless of lifecycle approach, reducing the size of an organization’s queues is one of the easiest ways to reduce cycle time. What are some common queues? There are often queues of projects, queues of enhancement requests, queues of defects to be fixed, queues of features, queues of tasks, queues of email (large inboxes), queues of approval requests, queues of production database changes. The number of queues increases the more an organization is oriented around functional groups, and the number of queues decreases the more an organization arranges work to be handled by cross-functional teams.
This is where queueing theory and agile methods intersect really well. Cycle time is related to the load on your system, in particular your units of work processing. In most organizations, teams are created to handle work. The more work given to a team simultaneously, the higher their utilization level. Many organizations like high utilization levels because it gives them a guarantee that people are doing valuable work all the time that they are paid to work. This is a completely false benefit and in fact is extremely destructive to overall productivity. From queueing theory we know that the cycle time for a piece of work increases exponentially to the utilization level. We see this whenever we over-load a server… but for some reason we fail to see this when we overload a person or a team or an organization even though it still happens.
Cycle time is also related to the variability in the size of the work packages. Low variability means that the exponential factor related to load is low, and high variability means that the exponential factor is high. In other words, if you have a highway that only allows motorbikes, you can have a very high load without getting bad traffic jams. On the other hand, if you have a highway that allows anything on it, you get traffic jams even with low levels of load. This is why HOV or commuter lanes and the left lane in multi-lane highways don’t typically allow transport trucks and buses. This result from queueing theory is not intuitively obvious so it is even harder for us to apply to software development.
But apply these two ideas, load and work size variability, we must if we wish to create a high performance development organization. The simplest way to do this is to have a single team work on a single project at a time and use iterations to ensure that the work being done is always exactly the same size - the size of the iteration.
It is possible to have very short iterations and still have a long cycle time. Many organizations make a few common mistakes with agile that cause this. If the work done inside each iteration is restricted to pure development work and everything else is done outside the iterations, then cycle time likely stays long. A common example of this is having the QA folks remain separate from the development team and do their work after a development team releases their work.
There is really only one way to avoid this: have a comprehensive definition of “done” that is met by the team every single iteration. This ensures that all work from idea to release for a given customer request is done inside a single iteration. A side effect of this is that all the pieces of work need to be small. It also gets rid of all the queues except one: the queue of ideas approved for delivery. With a single queue to manage, it becomes easy to measure cycle time, and therefore easy to improve it.
Improving cycle time can now be done in a few ways:
Once you have control of cycle time, it is possible to make reasonable measurements of productivity and two more metrics become extremely important (not that they weren’t important before, but they are easier to work with now). The first is Return on Investment (ROI) and the second is customer satisfaction.
ROI is in its simplest form a measure of how much benefit there is to doing something as compared to the cost of doing it. It takes into account the importance of time and timing, the importance of other options you may have, and of course, hopefully takes into account the business reality of your work. It also takes into account costs.
In software development, the primary cost is the cost of the staff doing the work, and the time factor is your cycle time (Ah! that’s where we use it). If you have a consistent team working on iterations that are always the same size and if you have little or no work being done outside of the iterations, it is very easy to calculate ROI in a useful way. Simply measure how much value a given iteration worth of work will generate and divide by the cost of the team for an iterations (and if the team is not yet doing work as it comes in, take into account the time value of money since the work might not be done for several iterations). Now, productivity is simply a measure of the Return for each Team-Iteration. Dollars/iteration. Simple. If the team’s productivity goes down, you can ask some really simple questions:
Customer satisfaction can be measured in many ways. If you have already started using agile practices, there is a good chance that your customers will already be more satisfied than they were before. This will show up informally through word-of-mouth. However, it is good to have a more systematic way of measuring customer satisfaction. One of the simplest and most commonly used methods of measuring customer satisfaction is the Net Promoter Score. From WikiPedia:
Companies obtain their Net Promoter Score by asking customers a single question (usually, “How likely is it that you would recommend us to a friend or colleague?”). Based on their responses, customers can be categorized into one of three groups: Promoters, Passives, and Detractors. In the net promoter framework, Promoters are viewed as valuable assets that drive profitable growth because of their repeat/increased purchases, longevity and referrals, while Detractors are seen as liabilities that destroy profitable growth because of their complaints, reduced purchases/defection and negative word-of-mouth. Companies calculate their Net Promoter Score by subtracting their % Detractors from their % Promoters.
The Net Promoter Score is closely linked to quality including the hard-to-measure parts of quality like responsiveness, ease of use, and fitness for purpose.
Cycle time also affects customer satisfaction. The faster you can respond to requests by customer, users or other stakeholders, the more likely they are to be satisfied. This happens for two reasons: fast response time means that solutions are more likely to still be useful and correct when actually delivered, and it also gives more opportunities for feedback.
In fact, if we look at these three measures, cycle time, ROI and customer satisfaction, we see that they form a mutually supporting and cross-checking system of ensuring productivity and effectiveness. Measuring anything else muddies the waters and can cause sub-optimal behaviors. The real challenge for most teams is realizing that all their local measures of performance and effectiveness may actually be causing harm (unintentionally) because they draw the team’s attention away from the three organizationally important measures.
Cycle time is the measure that is most closely related to process improvements, but ROI and customer satisfaction should also be used to ensure that process improvements don’t accidentally harm the organization.
This looks good: Agile Coach Training - Aug. 1-3, 2008. I’m not directly affiliated although Deborah Hartmann and I work together frequently.
After a rigorous submission process, a total of five presentations by Berteig Consulting staff and affiliates are accepted into the program for the Agile 2008 conference in Toronto. The five presentations are:
Berteig Consulting is also using the vendor talk slot to provide additional value to conference goers with an introduction to using OpenAgile to run a small business.
OpenAgile: A Method for Business Development (30 minutes, vendor talk) - Paul Heidema and Mishkin Berteig
Last week I gave a talk in Waterloo, Ontario on the topic of Delivering Successful Agile Projects - A Team Approach
. The slides and a bit more info can be found on the Berteig Consulting site. There was a great deal of interest so I have also scheduled a public agile project management / certified ScrumMaster course in Waterloo.
This was actually cribbed from a Bruce Schneier blog post about security…
Security engineers see the world differently than other engineers. Instead of focusing on how systems work, they focus on how systems fail, how they can be made to fail, and how to prevent–or protect against–those failures. Most software vulnerabilities don’t ever appear in normal operations, only when an attacker deliberately exploits them. So security engineers need to think like attackers.People without the mindset sometimes think they can design security products, but they can’t. And you see the results all over society–in snake-oil cryptography, software, Internet protocols, voting machines, and fare card and other payment systems. Many of these systems had someone in charge of “security” on their teams, but it wasn’t someone who thought like an attacker. Â
There’s an interesting parallel between this statement and how most software quality is handled. Quality and Security are similar. In fact, I see security as a very specific subset of quality-mindedness. Certainly both require the same mindset to ensure - rather than thinking merely “how will this work”, a quality-focused person will also, or perhaps alternately think: “how might this be breakable”. From this simple change in thinking flows several important approaches
 Schneier goes on to ponderÂ
This mindset is difficult to teach, and may be something you’re born with or not. But in order to train people possessing the mindset, they need to search for and find security vulnerabilities–again and again and again. And this is true regardless of the domain. Good cryptographers discover vulnerabilities in others’ algorithms and protocols. Good software security experts find vulnerabilities in others’ code. Good airport security designers figure out new ways to subvert airport security. And so on. Â
 Here again - I think it’s possible to help people get a mind-set about quality, but some do seem to have a knack. It’s important to have some of these people on your teams, as they’ll disturb the waters and identify potential failure modes. These are going to be the ones who want to “mistake proof” (to borrow Toyota’s phrase) the system by writing more unit tests and other executable proofs of the system. But most importantly (and I can personally testify to this) it is critical that people just write more tests. It is a learned skill to start to think of “how might this fail” until it becomes a background mental thread, always popping up risk models.A related concept is Demmings’ “systems-thinking”, which, applied to software quality, causes one to start looking at whole ecosystems of error states. This is when fearless re-factoring starts to pay off, because the elimination of duplication allows one to catch classes of error in fewer and fewer locations, where they’re easier to fix. There are many and multifarious spin-off effects of this inverted questioning and the mindset it generates. Try it yourself. When you’re writing code, ask yourself how you might break it? What inputs, external state, etc. might cause it to fail, crash, or behave in odd ways. This starts to show you where you might have state leaking into the wild, or side-effects from excessively complex interactions in your code. So quality focus can start to improve not only the external perception of your product, but also its fitness to new requirements by making it more resilient and less brittle. Cleaner interactions and less duplication allow for much faster implementation of new features.I could go on, but I just wanted to convey this sense of “attitude” or “mindset,” over mere technique. Technique can help you get to a certain level, but you have to let it “click”, and the powerful questions can sometimes help.
All credit for this is due to Mary Poppendieck as this is entirely cribbed from her Agile2007 talk on agile leadership.
A man walks into a quarry and sees three people with pickaxes. He walks up to the first one and asks, “What are you doing?” The first quarry worker irritably replies, “I’m cutting stone, what does it look like? I cut stone today, I cut stone yesterday, and I will cut stone tomorrow!” The man asks the same of the second person who replies, “I’m making a living for my family.” The man turns to the third person and asks him, “so what are you doing here?” The third worker looks up for a moment, looks back at the man with a proud expression and says, “I’m building a Cathedral!”
The moral of the parable is likely clear, but it bears applying to organizational dynamics. Basically, consider that everyone gets annoyed with aspects of their jobs. The question is one of response. Basically, if a person is annoyed with his job, does he:
Cathedral builders are absolutely critical to a healthy organization. They push the organization towards a vision, often propagating the high-level vision throughout all levels of the organization. Unfortunately, these are also people who annoy the stonecutters and paycheque earners, because they won’t participate in the complaints, and they agitate for changes which make it hard to ignore things and just “do the job.” But your success will rely on them… find them, shelter them, and grow them. And whatever you do, don’t “promote” them into positions where they aren’t effective. Empower them, and if you need to add salary and title that’s fine, but let them find their own area of maximal contribution. Guaranteed you, Mr. business owner, aren’t smart enough to see what that is.
Organizations that fail to see this remain mediocre or failing organizations. Organizations that find ways of harnessing their workforce and coaxing people into the next level of engagement, succeed.
Great little article on InfoQ: “Powerful Questions“.
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…
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.
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.
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.
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!
For the past three months I have been working with Paul Heidema (our VP of Marketing) to use OpenAgile to run our business. I thought it might be interesting for folks to see a screen capture of how we have arranged things in CardMeeting to do our planning and tracking. The yellow cards are labels for our Cycles, the white cards are Work Queue items, and the blue cards are Tasks related to the item. The orange cards represent special information (eg. obstacles or ongoing work) and the green cards represent reflections and learning for each Cycle.
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!
Wonderful article by Martin Fowler that discusses the relationship between individual productivity, cost, team size, time to market and value delivered. Some very interesting conclusions. This is critical reading if you are a manager!
Nice little article over at ITWorldCanada on “Detailed Development Specs Up Front a ‘Worst Practice’ Says IBM“. Pretty standard agile/scrum message. It’s nice to see it being delivered at ProjectWorld. I wish I could have been there :-) Anyone reading this at the talk, I would love to hear your comments.
Called “Mr. Squiggle” after an Australian TV show, this exercise looks great! Thanks to Patrick Kua for this great idea.
Geoffrey Wiseman has written a post on InfoQ about Complaint-Free Iterations. I like the idea. Check it out and participate in the discussion there.