I just finished reading Sam Guckenheimer and Neno Loje’s new book “Agile Software Engineering with Visual Studio.”  Great job guys!

Some observations:

• They appear to provide a fairly clear picture of Scrum.
• I love the fact they cover mura, muri and muda.
• I don’t like their explanation of technical debt.
• Great discussions on “Analysis Paralysis.”
• They pull in Lean and Kanban very nicely.
• Tacit knowledge is mentioned.
• Inclusion of Product Backlog grooming which many Scrum books overlook.
• Good discussion on Kano Analysis. (nice picture of Stephanie Cuthbertson and team!)
• Good discussion on Empirical vs. Defined Process Control.
• They present some great information on metrics and agile.
• Finally! A good description and discussion on Emergent Architecture!
• They talk about using branching sparingly then dive into a head-on discussion of a mature branching schema. I would have liked to have seen a discussion of lighter-weight methods.
• Sam and Neno advocate for integration as often as possible.  Awesome!
• The handling of testing is a bit dicey and appears to target the use of TFS/Visual Studio over good Agile practices.
• Good discussion on exploratory testing!
• Don’t care for their “Handling Bugs” section.

Quotes I really like:

• “you do not measure planned tasks completed as the primary indicator of progress; you count units of value delivered. “ (pg. 8)
• “Lean turns governance on its head, by trusting teams to work toward a shared goal, and using measurement transparency to allow teams to improve the flow of value and reduce waste themselves.“ (pg. 14)
• “Note that this does not mean that all tasks are known on the first day of the sprint. On the contrary, tasks may be added to the sprint backlog whenever necessary.“ (pg. 29)
• “mastery of Scrum is really for the whole team, not just a designated individual.” (pg. 76)
• “Unfortunately, using metrics to evaluate individual performance is often horribly counterproductive” (pg. 81)
• “use branches sparingly and intentionally. If you need to do something temporary, use a shelveset instead. ” (pg. 162)
• “A potential dysfunction is that integration fails. Integration issues, such as merging, are a common source of unhappiness and waste in teams.” (pg. 197)
• (Regarding test automation) “Automation is useful when it achieves high coverage and when the tests will be used many times for many configurations across many changes in the software under test (SUT).” (pg. 219)
• “work should be sequenced to facilitate getting PBIs through acceptance testing to done as quickly as possible.” (pg. 235)

This is a very good primer for using TFS and Visual Studio Ultimate within a Scrum environment!  This book coupled with Scrum.org’s Professional Scrum Developer course and you should be up and running in no time!

Over the last few years I have worked with teams that feel a need to using Branching as part of their “best practices” tool set. The ALM Rangers were even nice enough to show teams how to build a mature branching scenario in their Visual Studio Team Foundation Server Branching Guide 2010.  PROCEED WITH CAUTION!  There is a large overhead in using branching and merging.  The branching part is easy, it’s the merging part that will kill you.  Done infrequently, the merge process can be a huge undertaking in many cases taking days to complete.  Here is a quote from the original VS 2005 Branching and Merging Primer:

A branching and merging strategy involves a tradeoff between risk and productivity. You trade the safety of working in isolation for the increased productivity of working with other people. The productivity increases come with a cost—the additional effort required for merging software assets sometime in the future.

Often, there is no need to adopt branching as the teams are small enough or using shelves will suffice.  If you feel you need to branch, do so for the right reasons.  What are the “right reasons?”  In a nutshell, you absolutely NEED to isolate some code from other teams/repositories.  Examples might include:

• Development on a new feature is continuing while the current version is releasing.  (branch by feature)
• Teams are practicing design by contract and only want the final contract to be used by other teams. (branch by team)

What are some branching and merging anti-patterns to watch for? Here are few (thanks Chris Birmele):

• Merge Paranoia—avoiding merging at all cost, usually because of a fear of the consequences.
• Merge Mania—spending too much time merging software assets instead of developing them.
• Big Bang Merge—deferring branch merging to the end of the development effort and attempting to merge all branches simultaneously.
• Never-Ending Merge—continuous merging activity because there is always more to merge.
• Wrong-Way Merge—merging a software asset version with an earlier version.
• Branch Mania—creating many branches for no apparent reason.
• Cascading Branches—branching but never merging back to the main line.
• Mysterious Branches—branching for no apparent reason.
• Temporary Branches—branching for changing reasons, so the branch becomes a permanent temporary workspace.
• Volatile Branches—branching with unstable software assets shared by other branches or merged into another branch.

  Note   Branches are volatile most of the time while they exist as independent branches. That is the point of having them. The difference is that you should not share or merge branches while they are in an unstable state.

• Development Freeze—stopping all development activities while branching, merging, and building new base lines.
• Berlin Wall—using branches to divide the development team members, instead of dividing the work they are performing.

Remember, think long and hard about jumping into branching and merging.

Some additional reading:

Fowler on Feature Branching

Fowler on Continuous Integration

Betting on a greyhound race can be tons of fun.  You find a cool sounding greyhound, check the stats, then lay down $20 to win. (or some other bet variation)  We are ecstatic when our greyhound wins, collecting our money and touting the prowess of our keen eye for the stats.  When we lose, we attribute it to the dog having a bad day, the weather, the law of averages, etc.  If we are an avid better, we may begin to use complex formulas that take into account the dog’s past performances, current weather conditions, time of day, etc.  In fact, my wife’s uncle has written a book on such formulas for greyhound racing.  Even after an exhaustive amount of work we are still left with a game of chance each time we place a bet.  As hard as we try, predicting the future is hard, improving our chances takes significant effort and in the end we may be left with nothing more than a 1 in 10 chance of being right.  We’ll come back to this in a second…

Let me now turn the focus to that of software project estimation.  I’ve been spending time lately reviewing all the COCOMO II (B. Boehm et al.) material along with concepts of variable covariance. (as I talked about in this blog post)  What I am realizing is that formulas used by COCOMO II bare significant similarities to those used in gambling, e.g. greyhound racing.  We look at the empirical data (if we have it) from the team’s past projects and try to determine (guess) certain characteristics for our new project.  For example, in COCOMO II’s early design model, Person Months(PM) is estimated using the following formula:

PM = A x Size^B x M

Where A is a local coefficient that depends on things like organizational practices and type of software.  Similarly, B is an exponent that reflects the increased size of the project based on its novelty with Size being measured in thousands of lines of source code.  Finally M is another multiplier based on seven project specific attributes defined as follows:

M = PERS x RCPX x RUSE x PDIF x PREX x FCIL x SCED

I’m not going to go into each of these as the information on this formula is readily available.  The thing to understand is that each attribute is a value from 1 to 6 that represents a guess. (albeit an educated one)

What you will find in any traditional estimation system is something very similar to COCOMO II.  Tons of factors looking to measure this or that, complex formulas and a good mix of probability theory. In many cases today, this type of method simply won’t work.  Why? 

If we look at the challenges in quantifying each factor above we can begin to understand the reasons. 

A - Organizations change practices on a regular basis, fail to keep the necessary empirical data, face frequent significant technology changes.

B – Team membership changes which may impact team cohesion, varying degrees of market understanding and regular changes to the architecture driven by market demands.

M – Platform difficulty not understood early on, team changes effecting personal capabilities along with experience and poorly understood reuse model.

To wrap this all up, I thought it would be fun to consider our greyhound race being run as a modern software development project.  First, we are betting on not who wins the race, but how long it takes each dog to finish.  Further, we are going to change the track during the race (but we’ll announce it to the audience) and swap out dogs here and there to keep it interesting.(the dogs are just running right?)  :)  Anyone want to go to the track?

While I’m by no means advocating for companies to stop estimating, I am advocating for simpler, less risky and more cost effective models such as Planning Poker tied to Release and Sprint Planning coupled with a Product Roadmap.  These tools used with a good Agile approach are showing us a more sensible way forward.  I’ll try to explain some of the ideas around why we “bet on the dogs” along with some tools to help us move away from this in future posts.

As I mentioned, I received numerous questions during my presentation at the WI .NET User Group a few weeks back.  One of the them was: “Is there a way to add the subject of a user story as an explicit field?”  After probing the individual a bit, I discovered he wanted to be able to sort user stories bases on this field.  As a recap a user story is typically in the form:

As a <type of user> I want <some goal> so that <some reason>

In this post I will show you how to add the <type of user> or user story role to the user story in TFS 2010.

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 User Story 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.

Step 1:

Open the “User Story” WIT from the Server.

Step 2:

On the Fields tab click New.

Step 3:

Setup the new field similar to that below.  You will probably want to change “MyCompany” in the Reference name to be the name of your company.

Step 4:

Still in the Field Definition dialog, click on the Rules tab.

Step 5:

Click New, select ALLOWEDVALUES and click OK.

Step 6:

In the ALLOWEDVALUES dialog continue to click new and enter the desired roles until you have all the roles you want to use.

Step 7:

Click OK back to the WIT editor.

Step 8:

Go to the Layout Tab.

Step 9:

Right click on the Column node under Group – Classification and select New Control.

Step 10:

Setup the fields similar to the following:

Step 11:

Click Save.

Your’re Done!

Your User Story screen should now resemble the following:

You will also be able to add the Story Role column to queries and sort and filter by it.

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 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!