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:

During my presentation at the WI .NET User Group the this past week, I had a number of questions on customizing the TFS Process Template.  I’m going to answer some of these questions in detail on my blog.  The first one I’m going to cover is “Can I lock the original estimate in TFS so I can see how good we are at estimating?”  The answer is yes.  But before we begin, a couple of notes.

First make sure you have TFS Power Tools installed.  For the TFS 2010 RC, download them here.

Second, I’m going to show you how to do it using the MSF for Agile v5.0 Task Work Item Type (WIT).  While other templates are going to be slightly different, you can use this same method as a general guideline on how to do this.

Finally, what we are looking to do here is lock (make read only) our Original Estimate once we start booking time against the task.  Here’s how:

Step 1:

Open the “Task” WIT from the Server.

Step 2:

Goto the Workflow tab.

Step 3:

Open the initiating transition.  (The one that sets up the Active state on the far left)

Step 4:

Select the Fields tab.

Step 5:

Click new.

Step 6:

Select the Microsoft.VSTS.Scheduling.CompletedWork field.

Step 7:

Goto the Rules tab.

Step 8:

Click new and select the COPY rule type and click OK.

Step 9:

Set the fields as follows:

Step 10:

OK all the way back to the Workflow tab.

Step 11:

Open the Active State either by double clicking or selecting “Open Details” from the context menu.

Step 12:

Click New.

Step 13:

Select the field Microsoft.VSTS.Scheduling.OriginalEstimate.

Step 14:

Goto the Rules tab.

Step 15:

Click New, select WHENNOT and click OK.

Step 16:

Select Microsoft.VSTS.Scheduling.CompletedWork for the Field and 0 for the Value.

Step 17:

Goto the Rules tab.

Step 18:

Click New and Select READONLY.

Step 19:

OK all the way back to the Workflow tab.

Step 20:

Click Save.

You’re Done!

Now as long as you don’t enter any work against as task you can continue to modify the Original Estimate field. 

Once hours are booked against the task, the Original Estimate field changes to read only.

Good luck and Enjoy!

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 was recently asked: “What mentoring techniques have you used to help engineers make the move into management?”  Great question!

While there are many tools that can be used here, I think it’s important to start with some key factors in making this jump:

1. Engineers thrive on building things and the resulting sense of accomplishment when it’s built.
2. To improve yourself, the must be an awareness of the improvement area.

Starting with the first point, I’ve seen (and personally experienced) a sense of floundering when engineers are asked to manage others.  Being used to writing code all day they often feel like they aren’t accomplishing anything day after day.  As far as I can tell, there is no way around this and represents the first half of the chasm.  Tool #1, Patience.  We must remind our manager in training that what they are experiencing is perfectly normal and that things take time.  Additionally remind them that the sense of accomplishment will return if they are willing to be patient. In John Baldoni’s book, Lead by Example, an entire lesson (#7) is devoted to this topic alone.  Tool #2, Communicate…then communicate some more.  In the realm of engineering it is common practice to communicate things only once and expect that they are understood, in reality this is rarely the case.  Give people direction, set clear expectations, talk about team goals, discuss the vision of the company…rinse and repeat.  Your team must understand what you expect from them and start including these expectations in their decision making process, this takes time and repetition.  Tool #3, Watch for changes.  As our management in training begins to use the first two tools, have them watch for changes in behavior on the team, however subtle, that may be a result of their leadership.  This tool is the preface to regaining that sense of accomplishment.  As the team begins to respond to our manager in training’s leadership there will be changes to team dynamics.  These changes may be positive or negative depending on the many factors, but awareness of the change is important.  The ability to detect changes in the team based on decisions made by our manager in training represents the second half of the chasm.

On the second point, we need instill in our manager in training (and remind ourselves) that having an awareness of an improvement area is the first step in making changes.  For out manager in training to use the tools above, they must be able to see how certain aspects of their experience, education, personality and management style impacts what they do.  It is the job of the mentor to make them aware of this. (albeit tactfully)  If there is no awareness it is unlikely to be improved upon.

This is far from a complete list but instead represents some of the basics. I hope that it’s helpful and, as always, I welcome your comments.

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

I am happy to announce that we (Rangers) have released the new Requirements Management Guidance for TFS 2010!

This Ranger solution addresses the People, Process, and Technology guidance for Requirements Engineering (RE) using Team Foundation Server. The goal of this guidance is to provide formalized Microsoft field experience in the form of recommended procedures and processes, Visual Studio Team System and Team Foundation Server configurations, and skill development references for the Requirements Engineering discipline of your application lifecycle.

Visual Studio ALM Rangers
This guidance is created by the Rangers who have the mission to provide out of band solutions for missing features or guidance. This content was created with support from Microsoft Product Group, Microsoft Most Valued Professionals (MVPs) and technical specialists from technology communities around the globe, giving you a real-world view from the field, where the technology has been tested and used.

What is in the package?
Requirements Management is a vast area with many disciplines. To address your areas of interest and expertise, we have packaged the content in 9 zip files. The default download is the complete package in one zip file for those who are interested in all areas.

1. Introduction: RM Rangers Guide to the Complete Guide Start Here
2. Requirements Management Planning
3. Requirements Traceability
4. Analysis and Breakdown
5. Requirements Elicitation
6. Requirements Specification
7. Requirements Validation
8. Requirements Change Management and Approval
9. Requirements Management checklist sheet

Great job Mike Schimmel & the rest of the team!

For those of you out there doing TFS 2010 presentations and demos, here is the TFS “stadium graphic” with the new SKUs and branding.

Enjoy!