I’m spending quite a bit of time these days helping organizations implement Agile methodologies.  As such I hear the same set of questions and see the same set of issues over and over again.  One of the issues I see quite often is the “long sprint.”  To explain what I mean by this I’ll use a hypothetical conversation with a Team Lead new to Agile.

Team Lead: “How do you deal with the fact sprint planning and reviews take so long?”

Me: “How long is long?”

Team Lead: “Sometimes a week!”

Me: “How long are your sprints?”

Team Lead: “Usually 3-6 weeks.”

Me: “How did you determine that 3-6 weeks was a good length?”

Team Lead: “Because we couldn’t spend 2 weeks out of every month not coding!  We use longer Sprints to avoid spending so much time in review and planning.”

For those of you that are experienced in Agile, you should see a few problems here.  For now, let’s just focus on the “long sprint” concept.  The “long sprint” seems to manifest in organizations that are always sprinting.  First off, this is in direct conflict with the name sprint.  Sprints should be just that, a focused exertion of energy over a short period of time…2-3 weeks max.  So how do we solve our Team Lead’s issue with spending too much time in review and planning and not enough time writing code?  Enter the “Release.”

A Release is a means of building larger blocks of functionality in multiple Sprints. (usually 4-6)  Some Agile methodologies (XP) implement this concept directly, others do not. (Scrum)  There are many reasons to use the concept of a Release, a select few are:

• Some features just might not fit into a two week Sprint.
• Allow team to perform work in parallel to development.  In general team members can do work other than sitting in sprint review and planning sessions.  This is because these sessions are lighter weight and involve fewer people.  You simply review implemented sprint functionality ensuring it meets the needs of the stakeholder and grab the next chunk of the prioritized Product Backlog. (ok, a bit more than that, but you get the point) These two sessions should not take more than 3 days.
• Reduce the overhead of delivering software to production every 2 weeks.
• Reduce the information overload caused by releasing every 2 weeks.
• Define a delivery pace more inline with that of the organization. (the rope in the Drum-Buffer-Rope of Throughput Accounting)

The next logical question is “Do we create a Release Backlog?”  I agree with Mike Cohn in this case and would say no.  I do however, use the concept of a Release Plan or Release Roadmap.  According to Mike a Release Plan contains:

• Graph showing historical velocity.
• Prioritized Product Backlog. (including some big user stories, "epics")
• A predicted range of where we will finish. This should be either a date-range for a fixed-scope project or a functionality-range.
• Personnel assumptions. (Team members and availability)
• Velocity assumptions. ("we’ll go about half speed during December because of holidays and time off")

I would also add the following:

• A Vision Statement.  (“We want to add the shopping cart functionality and connect it to PayPal”)
• Estimated Release Value as I discuss here.

Using the concept of a Release in Agile organizations can be an extremely effective way to increase efficiency through the elimination of waste.  I will try to post more on this topic in the future.  As always, let me know your thoughts.

Further Reading:

Extreme Programming Release Planning:

http://www.extremeprogramming.org/rules/planninggame.html

Mike Cohn on Release Planning:

http://blog.mountaingoatsoftware.com/why-do-release-planning

Mike Cohn on why there should not be a release backlog:

http://blog.mountaingoatsoftware.com/why-there-should-not-be-a-release-backlog

Kelly Waters on Release Planning:

http://www.agile-software-development.com/2008/02/agile-release-planning.html

Now that we have some estimates which include our buffers, we have to see what can realistically get done in the release. This is the process I use:

1. Figure out what individual resource loading looks like.
2. Establish any dependencies.
3. Try to distribute work away from the most loaded resource. (Elevate the constraint)
4. Assess Risks. (I’ll discuss this in future articles)
5. Discuss alternatives.
6. Verify validity of estimates and adjust if necessary.
7. With the new information learned from 1-6, repeat the sequence at least once.

This process should be the primary focus of your Release Planning meeting.  In the following sections I will talk about each of these steps individually.

Figure out what individual resource loading looks like

Use your tools here.  Most Agile tools have a way to examine individual developer loading for a Sprint and Release.  In lieu of that you can use an Excel Pivot Table of your Product or Sprint Backlog to create the numbers.  To do this, highlight your estimate table and click the PivotTable button on the Insert ribbon and click PivotTable. (Excel 2007)  This should give you something that looks like Figure 1.

Figure 1 – Excel 2007 PivotTable Empty

From here, drag the developer into the Row Labels box and Estimate,Min and Max into the Values box.  You should now have something that looks like Figure 2.

Figure 2 - Excel 2007 PivotTable Basic

You will notice that our values all say “Count” and that’s not what we are looking for, we want the sum.  To change this click on each of the items in the Values box and select “Value Field Settings…” and change it to “Sum.”  You should now see something like Figure 3.

Figure 3 - Excel 2007 PivotTable Resource Loading

This shows us that Joe has the most work with 3 hours, followed by Bob then Chris.  While this is just an example, in step 3 we will want to try to reduce Joe’s load by attempting to shift work to Bob or Chris.

Establish any dependencies

Don’t spend too much time on this one.  What you want to do is take a look at the priority order of the backlog and see if you need to make any changes due to dependencies.  Obviously you won’t be able to write data to the database if the database has not yet been built.  In my experience, most teams tend to do this intuitively.  Just to be sure, discuss the dependencies of each item as part of the Release and Sprint Planning meetings.  The goal here is to sequence items in such a way that there will not be any resource downtime during a Sprint.

Try to distribute work away from the most loaded resource

In accordance with the Theory of Constraints, we want to try to elevate a constraint by shifting some of its work to other resources.  This step should be fairly obvious with regards to what to do.  A word of caution here.  You may find that suboptimal loading creates greater throughput than a perfectly balanced load.  For example your Team Lead may require slightly less loading due to his need to guide the team.  You may also find the need to overload some of your team members that tend to over-estimate items.

Assess Risks

Due to the short time frames of most Agile projects, you may choose to do this step as an informal part of the discussion of each item.  If your project requires it you may need to build a risk register.  In terms of the PMBOK this is covered extensively in Chapter 11 (Third Edition) and I will cover it in more detail in later posts.

Discuss alternatives

Sometimes building multiple solutions to the same problem yields better results in less time.  In the book Lean Software Development, Mary and Tom Poppendieck discuss this in detail in Chapter 2/Tool 6.

If there is a need for an optimal solution to a given feature, try developing 2 or 3 solutions during a Sprint and let the user decide which one is best.  Often you will find the user wants some combination of the solutions. Obviously doing this is going to add work to the schedule and as such we consider it here.

This is also the point at which the team should ALL have an understanding of the approach that will be used to build out each item.  Often in this dialogue, new ideas are formed that create better solutions.

Verify validity of estimates and adjust if necessary

Give the steps above, you will need to adjust your user stories, estimates and schedule.  You may have found that you can add more features to a given Sprint or that you grossly underestimated what it was going to take to get it done.  Either way, you will probably need to make some adjustments here.  Additionally, check the validity of the new estimates using this technique and add buffers if necessary. 

With the new information learned from 1-6, repeat the sequence at least once

With your adjustments in hand, go through the process again.  This time it will probably go much quicker.  Follow the same steps as before but also make sure the team discusses the adjustments that were made and the associated impact. 

Conclusion

I have found this process usually takes about 3-4 days with a typical Scrum team. (2-6 people)  The first day is all about estimating with the second day being performing the steps above.  The 3rd and 4th days involve backlog lockdown and team commitment.  In the next post I will talk about how this process ties into section 6.5 of the Third Edition PMBOK.  Until then, good luck and let me know what you think!

A great interview with Dr. Goldratt. Many of his comments remind me of the MIT Sloan beer distribution game. What I continue to get from reading Dr. Goldratt is that people solve problems, not processes. While the Theory of Constraints, Six Sigma, Lean, are all good tools, they are implemented by people. Just think about how Bill Smith started using Six Sigma at Motorola or how Taiichi Ohno brought the Toyota Production System together. These were people using the scientific method to solve problems and ultimately improve their companies.

Before I talk about schedule development, I want to touch on estimates a bit more since I've received some questions on this. For those of you that are new to Agile estimation, I strongly suggest reading Mike Cohn's book Agile Estimating and Planning. It covers many of techniques I discuss in this series.

The primary question I received was "How can you be sure your estimates are right?" The first thing we need is an Expert Opinion. According to Cohn, If you want to know how long something will take, ask an expert. In the PMBOK, this is called Expert Judgment. (6.4.2.1 in the Third Edition) While this is a good start, I've found that some experts (read developers) are talented estimators while others are horrible, most are somewhere in between. Due to this fact, we need a few tools to help assess our expert's ability to estimate.

The first tool we need some historical data, in lieu of historical data estimating becomes an educated guess. If you don't have historical data, start collecting it today. For reference, you will need to collect the initial estimate and the actual time taken to complete. Once you have some historical data you can produce the deviations I discussed in my previous article and the histograms shown below.

The second tool we can use is an estimate histogram. For features (vs. bugs) you can compile histograms for each expert on tasks they have estimated to be 1,2,4,8,12 and 16 hour efforts. Remember that any task over 16 hours should be broken down into smaller chunks. What you are looking for is each expert's ability to accurately estimate.

Figure 1 – 4 Hour Estimation Histogram

As we can see from Figure 1, Joe (our hypothetical expert) tends to overestimate the amount of time it takes to complete a 4 hour task. While 32 of Joe's tasks that he estimated to be 4 hours in duration actually took 4 hours, 72 of them only took 2.5 hours. In this case, we can leave the estimate as-is since the median of 2.5 is only 1.5 hours off of our expert's estimate. This is in-effect gives us a 1.5 hour buffer which, as you will see, is what we want. If we produce histograms for all other effort sizes we may find that Joe tends to underestimate larger efforts, this would look something like Figure 2.

Figure 2 - 16 Hour Estimation Histogram

Knowing that Joe has a tendency to underestimate larger tasks, it may be in our best interest to try to get Joe to break larger tasks down further. Alternatively, as Mike Cohn suggests, we can provide feature buffers to reduce the risk of poor estimates. Both these methods are valid and have a basis in the Theory of Constraints. We are assuming that Joe's issue with underestimating longer tasks is going to create a constraint during the iteration. My experience has shown me that this is typically true and the use of buffers can help protect the constraint. This is also referred to as Critical Chain Buffers on which there is ample work available online.

To calculate buffer times, you can use the simple "just add 25%" method which may work. In the case shown in Figure 2, adding 25% to a 16 hour estimate would only give us 20 hours, still under the 32 hours seen the most. However, there is only about a 40% chance that Joe will finish a 16 hour task in 32 hours. This is because 60% of the area of the 16 hour histogram occurs from 4-31 hours. A better approach to calculate a buffer is to use two standard deviations which, in this case is about 12 hours. This would give us a buffered task time of about 28 hours. Mike Cohn discusses this in more detail in Chapter 17 of Agile Estimating and Planning. Eliyahu M. Goldratt suggests in his book, Critical Chain, to simply use the median value for a given task, which in this case is about 30 hours, so we can use a buffer of 14 hours.

Whatever method you find works for you, create the buffer as a separate task that is dependent on the primary task. You will want to be able to continue to track estimates independently of the buffer. The goal of this process would be to center the curve over the estimated time.

Now on to Schedule Development...

In my post Planning the Project – Part 1, I talked about the use of financial metrics to determine if we should execute a project or not. In my last post I empirically showed that slight variations in a group of dependent processes can have very dramatic effects on the outcome. So the question is, how do we use these two bits of knowledge to help us estimate? In simplest terms, we want to use some estimation techniques that take statistical variation into account and use NPV and IRR to gauge financial impact. We can use a number of techniques to estimate time and therefore cost. A few of the more popular ones are:

1. Proxy based estimation. (PROBE)
2. Parametric estimation.
3. The Planning Game or Planning Poker.
4. Putnam model based estimation. (SLIM)
5. Evidence-based Scheduling. (EBS)
6. Other various algorithm based models. (COCOMO, SEER-SEM, etc.)

Before we start using any of these techniques, it's good to have a couple of releases under your belt to gauge the velocity of your team. Depending on the Agile methodology, we may want to estimate features, Product Backlog Items, Scenarios, etc. We will want to start by having the teams make a guess at how long it will take to complete these items. I recommend breaking down any item that is estimated for more than 2 days into smaller chunks. Then you will also need to monitor the actual time needed to complete the item. Over a couple releases you should get a better understanding of how good certain individuals are at estimating and how quickly they can actually get things done. Given that information I like to build a "risk factor" or deviation for each developer that is providing estimates. Using this risk factor I can produce min/max estimates more accurately.

Now that you have some data in hand it's time to generate some estimates. I like to use a combination of Evidence-based Scheduling (EBS) and Proxy based estimation. Joel Spolsky has an EBS primer here. Proxy based estimation is simply the act of using similar pieces of completed code as the basis for current estimates, but here again we need data. Let's look at the widget example from Part 1 and look at the specifics. A 6 man-month project is a two month project for a team of three developers. Assuming we use Scrum, we are looking at three development sprints followed by a release sprint. The two week release sprint will be used to stabilize the software by eliminating all the bugs that are deemed unacceptable for release. Each Product Backlog Item (PBI) will be broken into one or more Sprint Backlog Items (SBIs) and used to generate the estimate. I'm just going to use the first PBI which will take the first week of the first Sprint for purposes of discussing estimation. All the other PBIs will be estimated the same way.

Figure 1 - PBI/SBI Estimation Example

Using the historical estimation data you can produce a deviation for each developer that will give you a pretty good range. You can see from the Figure 1 that we have a margin of error of 6.6 days, this is 5.5% of a 120 man-day project. I would be nice if we could reduce this, but let's review what we are trying to do. We are building an ESTIMATE, not an EXACTAMATE! What these numbers really tell you is the confidence you can have in completing the sprints and the release on-time.

I can hear people screaming now, "But Chad! You shouldn't do this in Agile!" Really? I disagree. Agile is not an open checkbook that allows development to just keep working on projects indefinitely, it is a mechanism to Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.¹ We still need to create estimates that allow the business to plan on a software release by a certain date. Remember, we can choose to add or remove scope as necessary but we MUST meet our release dates. We estimate to gain a level of confidence that we can, in fact, meet those dates. As we move forward in the release and learn more we will continue to plan and execute as we monitor the project during the execution phase. This is the "Plan-Do-Check-Act" cycle prescribed by the PMBOK.

If you haven't already figured it out, I'm working my way through the Planning Process Group section of the PMBOK. (3.2.2 in the Third Edition) This article covers .3 through .8 and a bit of .9. I'm going to go into a bit more detail on Schedule Development in my next post.

1. Principles behind the Agile Manifesto - http://agilemanifesto.org/principles.html

Before I get to much further in this series I think it’s important to talk about the culture that this works best in.  Kaizen is a way of thinking about your organizational culture, the concept of continuous improvement and the elimination of waste.  A key element in the Toyota Production System (TPS), it seeks to humanize the workplace while increasing efficiency and revenue.  Ok, so what is it?  The Kaizen method consists of five basic elements which are:

1. Teamwork
2. Personal Discipline
3. Improved Morale
4. Quality Circles
5. Suggestions for Improvements

You will often hear Kanban and Lean Software Development mentioned in the same body of work as Kaizen but it does not only apply to these techniques.  The Kaizen organization is one that is constantly looking to improve itself, one that is open to critique and one where its employees feel empowered to participate in improving it.  These characteristics are not common place in many organizations, but given the current state of the global economy they may well start to be.

Figure 1 depicts how I think about Kaizen as it relates to TOC and Agile.

Figure 1 - Kaizen, TOC, Agile relationship

There are many facets to initiating a project according to the PMBOK.  Questions like, “Should we do this project?” and “Will we be able to deliver results?” all need to be answered.  To answer these questions we need to run the core process of this step, Scope Initiation.  The Scope Initiation process has, as do most PMBOK processes, Inputs, Tools and Techniques and Outputs.  Inputs include things like the product or service description, statement of work, strategic plan and historical information.  The Tools and Techniques include things like project selection methods and expert judgment. Finally, the Outputs are the Project Charter and the Preliminary Project Scope Statement.  I will examine the relevance of these documents in Agile Management one at a time.  Additionally, given the fractal nature of Agile development, this step can be used at the release level or at the individual iteration level.

The Project Charter is used to authorize the project and document its business need.  In Agile this step is very important as it helps create a unifying vision for the product or service.  It is easy in an Agile environment to lose track of the original intent, this document can help remind the team of what and why of the project.

The Project Scope Statement defines the deliverable requirements, boundaries of the product or service, methods of acceptance, etc.  This statement is present either implicitly or explicitly in most modern Agile methodologies and is usually represented by one or more artifact.

Agile correlation for these two documents are shown below.

Brought forth by Dr. Eliyahu M. Goldratt in his 1984 book titled The Goal: A Process of Ongoing Improvement, the Theory of Constraints is an idea and process that seeks to optimize a system by identifying and eliminating its bottlenecks.  The process is comprised of five, fairly straightforward, steps:

1. Indentify the constraint.  This means you will need to be able to measure a systems performance in order to identify its constraints.  I will talk more about that in later articles but for those of you who can’t wait, take a look at David Anderson’s book Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (Coad Series)
2. Exploit the constraint.  This means that you should do everything within your power to make sure that the constraint (equipment, people, policy) is never idle.  Again, I will talk more about this item in future articles.
3. Subordinate all other processes to the constraint.  In Lean and Six Sigma this is known as “balancing” and is simply the act of keeping other phases in a process in-line with the constraint. This step introduces the concept of Drum-Buffer-Rope (DBR) as a mental model that can be used to explain subordination.  The Drum is the physical constraint (rate) of the team, the Buffer protects the Drum so it always has work flowing to it and the Rope is the flow of inventory into final product by way of the implemented process.  David Anderson has a good explanation here.
4. Elevate the constraint.  This is the improvement step.  Consider ways to improve the throughput such as removing inefficient or time-wasting process, hiring more people, buying more equipment or tools.  In my opinion this is where the meat of TOC is and I will spend significant time on this topic in future articles.
5. If the steps taken in #4 have caused the constraint to move, go to #1.

In future articles I will discuss how TOC can be used to improve the efficiency of your Agile teams primarily during the Planning, Executing and Monitoring phases of your Agile project.