First let’s start with Ward Cunningham’s definition here.  The way I explained this at MADdotNET was poor at best.  ;)  While I tend to include measures of waste in technical debt, this is NOT generally shared by the Agile community.  Simply put, technical debt is the cost (debt) from hasty software design and development.  Steve McConnell expounds on this here.  I hope this clears things up!

I presented “Succeeding With Agile & TFS 2010” for the MADdotNET User Group last night to a full house.  I want to thank everyone for the turnout and the great questions and discussions!  I’m going to try to post some articles as follow-ups to some the the questions that were asked last night that didn’t get the attention they deserve.  Some of these topics will be:  Agile Estimation, Technical Debt, Code Churn and including bugs and refactoring on the Product Backlog.  Let me know if I missed anything you want me to cover.

For those that are interested, here is the presentation:

Making the transition to Agile can be challenging for even the most seasoned organization. Having good leadership and the right tools can make all the difference. Drawing on nearly two decades of experience Chad will be walking us through methods that can be used to avoid common pitfalls and using Team Foundation Server (TFS) 2010 as an Agile platform. In this highly interactive session, Chad will demonstrate some of the new features of TFS 2010 as they relate to Agile estimation, planning, execution and measurement. If your organization is considering a migration to Agile or the TFS 2010 platform, you are encouraged to attend.

I presenting the above topic tonight at the Wisconsin .NET User Group.  Register Here!

I will also be giving the same presentation at the Madison .NET User Group on March 3rd.  Register Here!

Look for a presentation in the Chicago Land area towards the end of March.

Inspired by Michael Dubakov's article Flow. Discover Problems and Waste in Kanban, I thought I’d spend some time looking at Value Stream Analysis.

We talk a lot these days about delivering value to our clients, but many of us don’t understand the details of how that is accomplished.  Sure we understand that raw ones and zeros couldn’t be sold for the same amount as the aggregated application, but let’s take a more concise look at a couple questions?  1) How do we define value.  and 2) How do we analyze the process by which we deliver value? (Value Stream)

The first question we seek to better understand is the definition of value.  Without diving head first into an economics discussion, we can simply look at value as our client’s perceived worth of the product or service we provide.  This has a dollar figure attached to it.  While one can argue that value is also inclusive of the qualitative aspects of our product or service, it is not easily measured, so for purposes of this discussion can be ignored.  I defined a method of assigning a dollar value to SaaS features in one of my previous posts.  This method can also be used to determine the dollar value of a release, iteration, feature or task on either products or services.  With a dollar value in hand we can begin to look at answering question #2.

As we begin to examine our Value Stream, I would be remiss without mentioning the work of all the people that have contributed work in this area, Eliyahu M. Goldratt, Taiichi Ohno, James Womak, Kent Beck, Mary Poppendieck and Tom Poppendieck, to name just a few.  In Tom and Mary’s book Lean Software Development, they present Tool #2 - Value Stream Mapping which gives us a good way to visually represent our Value Stream:

If we look at the figure above, we see the typical steps that an Agile team may follow transforming an idea into reality.  There is active work that is done on the idea/feature (above the line, value add) and time when the idea/feature sits dormant. (below the line, waste)  Examining the timing of the above hypothetical flow, we can see that the overall process took 18 weeks with 11 weeks (61%) delivering value and 7 weeks (39%) of waste.  This example is a bit far fetched but is meant to provide a simple means of showing how the map works.  You may find it more useful to use days as a unit-of measure or even hours.  The point here being that you may be able to reduce your feature time to market to only 11 weeks if you could only avoid wait time.  If we assume that the feature we are developing will provide $5000 of value in the market, (to our clients) then at 18 weeks we are only delivering $278 of value a week, whereas we hit $455 a week when we do it in 11 weeks.

This can be a very useful tool for improving the productivity of your development organization but we need one more piece to make it effective.  Since we are not developing one feature at a time we need to understand the effects of multiple features flowing through our value stream.  If we only seek to optimize the flow of one feature’s flow we may do that at the expense of others.  We must look at the system as a whole and try to optimize elements that will reduce our wait time for all ideas/features currently in progress.  This is not an easy task.  You should look at the steps that are costly first and try to identify the pain points in those steps.  For instance, if there are days lost because team members are unaware of a status change, seek to implement a tool that sends automated emails on status change.

In summary, here are the steps to analyze your value stream:

1. Create a map of the steps that an idea takes from concept to delivery.
2. Measure the value-add and wait time of a number of ideas as they flow through this map.
3. Assign a dollar value to your ideas and measure your current weekly value and share this with the team.
4. If changes were already made to try to increase the flow of value, did they work? By how much?
5. As a team, come up with changes that will increase the flow of ALL ideas through the system.
6. Implement these new changes and go back to #2.

I am spending most of my time as of late providing management consulting services to my clients.  Most of them have made, or are making, the transition to Agile and often facing the same set of issues.  While I think there is no replacement for a good Management Consultant/Agile Coach, a close second is reading as much as you can from those who have successfully made the transition to Agile.  With that, I would like to present a select list of my favorites:

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

Glen B. Alleman has a great post on teams trying to use technology to solve their issues.  First tenant of the Agile Manifesto:

Individuals and interactions over processes and tools

I see supposed Agile teams doing the direct opposite over and over again.   I’ve seen really well run projects using nothing more than email and an Excel spreadsheet…and lots and lots of leadership and communication.  :)

Another book to add to the list:

Pascal Van Cauwenberghe has a review here.

I received a couple comments on my post about Prioritizing SaaS Features.  One comment was focused on the use of EV and AC which I will address later, the other was on the use of Ideal Hours.  The comment on Ideal Hours was from Rob Park, an Agile Coach from Colorado.  Here is an excerpt from Rob’s comment:

The one thing I feel is optimistic about your calculation is the ideal hours though. Ideal hours are not actual hours, so I think you need another factor in there to convert to actual hours based on actual velocity trends.

Great point Rob!  While Ideal Hours are not representative of Man Hours, there are a few tools I use to try to get them as close as possible i.e. the conversion factor as close to 1 as possible.  First, team members sign up for tasks and estimate as part of the iteration planning and decomposition process as discussed here.  Second, estimates for specific team members are tracked against actual time as discussed here.  This gives us our margin of error for a specific team member that we can use to size our buffers.  Third, we use the process described here to evenly load the work onto the team for the iteration. Finally, if tasks change hands during the iteration, estimates and cost curves are adjusted accordingly.  This may cause an item(s) to get descoped during the iteration and technical debt to increase, but this hopefully will be addressed as part of the next iteration.

So why not just use Man Hours?  I like the concept of Ideal Hours because it gives you more flexibility on estimates.  The term Man Hours has rigid foundations in project management that do not work well in the Agile world.  Think of it this way.  With Ideal Hours we try to approach real Man Hours and use a factor to determine how right (close) we are.  With Man Hours we consider estimate accuracy a measure of how wrong we were.  Ideal Hours just fit better into Agile thinking.

I’ve talked about using your Value Proposition(VP) to rank features by dollar value here and using Ideal Days to estimate duration here.  Now let’s combine the two and look at total value based prioritization of features or PBI’s.  In essence what we are doing is giving the highest rank to features that will yield the most value in the least amount of time.(cost)  To calculate cost we will need some measure of cost per hour.  If you have the actual numbers, use them, if not here are some tools you can use.  Work hours in a year: 2080 Annual salary:  $50K=$24/hour  $100K=$48/hour.  Margin for overhead: 20-30%.  With these tools let’s assume that our team makes on average $90K annually.  This gives us $43 an hour.  Adding 25% we get about $54 an hour.  From here we can simply multiply our cost per hour by our Ideal Hours to get total cost per feature.  Subtract our total cost from our value (sales) and we get the profit per feature.   We then prioritize (rank) by profit.

As you can see this moves our prioritization around a little bit.  The nice thing about the above is that we can automate it.  In your Agile Management System each feature should accept a VP rank and an duration estimate in Ideal Hours.  You will also want to have a mechanism to enter the Value of the release, $100K in the example above.  Using these inputs your system should be able to auto-prioritize your features for you.  Now that you have cost, you can track EV,PV and AC on your CVE vs. CVP graph.  I don’t like the PMI term “value” in the EV and PV metrics.  Their old names used to be Budgeted Cost of Work Performed(BCWP) and Budgeted Cost of Work Scheduled(BCWS) which I think is more fitting. Either way, don’t confuse the term “value” in these metrics for revenue.  The value they represent is the cost, i.e. the value of the work.  For this example, we will assume that the estimates were correct and AC and EV are equal, that is, there is no cost variance during the release.  The graph would be similar to that of Figure 1.

Figure 1 – CVP, CVE, PV, EV & AC

I know there are some hard-core Agile managers out there who believe that we should not concern ourselves with revenue estimates.  Some think that simply managing costs while we continue to iterate is enough.  If you are of this mindset, let me ask some questions.  How do you know when your costs are nearing your sales?  How do you determine if your project will be profitable?  If given multiple projects to work on, how do you choose the most important one?

I would also like to remind you that I have not taken risk into account yet, which will again change the priority of the features.  I will try to cover this in future posts.

As always, I would love to hear your thoughts on this.