Xp Critical Mass

XpCriticalMass

This is a work in progress... You'll notice that the end trails off as my mind started to fade. Working as an XP Coach for a team, a Manager posed the question about how we get to a "Critical Mass" where we have a product that can be shipped... these were my thoughts:

Reflecting on how we get to the "Critical Mass" I would like to expand on how we could do that in an agile development environment using the XP Methodology.

The "Critical Mass" is defined as those set of features comprising a system that gives business value to the customer.

So what is "Business Value"? The Business Value of a feature is how important that feature is to the customers ultimate success. This could be automating a manual process, making processes more efficient, reporting on collected data, etc. Unfortunately this most often is not one thing but several smaller items that together as a whole give us Business Value. So what we are stating is that we cannot give our customer Business Value in an individual story, it takes something larger than a story and larger than 1 iteration to give our customer business value. However we do not want to sacrifice small iterations to achieve what has been defined as business value.

Since we know it is easier to develop a system if we can do so in small manageable chunks, we need to continue with iteration plans and story development. We need to continue tasking our stories and estimating how long it will take to accomplish our work. But now how do we keep the stories testable, estimable and manageable? We need to keep our stories small and able to fit within an iteration. But how do we keep the stories small when we can't deliver what has been defined as business value to the customer within an iteration? We need to adopt the concept of "Measurable Progress".

Measurable Progress is a single identifiable feature that can be estimated and tested. Through the planning game, we try to define stories in the context of what is their greatest business need based on what gives them the greatest business value. As we has stated, these stories are usually too large to handle within one iteration. The larger the story, the harder it is to estimate, the harder it is to test and the harder it is to change.

If we have series of large stories, our estimates are inevitably inaccurate which will give our customer and management false expectations as to when the story can be delivered. Similarly, if our story is too big, it becomes difficult to test which affects the quality our feature and adds to the time it takes to implement because of the testing difficulty. To allow us to move quickly in our development efforts, we need to break the stories down into smaller more manageable pieces. This will allow us to provide better estimates which will give the customer a more accurate projection of cost and allow easier tracking of the project over time.

Obviously this does not end here. At the end of each iteration we must evaluate what happened and monitor "yesterday's weather" so that we can more accurately predict what we can do in the next iteration. Over time we get better at estimating and the picture of where and what the project will be becomes clearer.

All of this definition and explanation is necessary to understand what we need to do to get to the "Critical Mass" which is the same as giving our customer "Business Value".

Now a question remains. How do we start a project when the customer does not know what they want or what they need?

What a bizarre question. If the customer doesn't know what they want or need--why is there a project at all? Answer that question and you'll know what they want and need unless, as many programmers do, you mean they haven't done the design for you. The "critical mass" is realization of the minimum set of use cases that will support the business objective--the "make it work" set. If you and the client can't define and prioritize the use cases, and draw the line at essential utility, you need someone with more experience on the project.

How do we give them business value when they cannot define what it is? Unfortunately developers are not customers and cannot define what "business value" is for our customers, nor should they. Assuming that the customer is a domain expert, the developers cannot know everything that the customer knows. If the customer is a member or the team, over time, the whole team learns more about what the needs of the customer are. Also, the customer learns more about what the developers need. Mutual trust between the developers and the customer develops.

This is where the Release Plan is very important and sets the tone for the project. During the Release Plan, the team meets with the customer (as part of the team) and discusses what needs to be accomplished for a system to be released that gives them "Business Value". This list of features or "stories" comprises what is the "Critical Mass" for the project. These stories are estimated using a high-level estimation based on what we know now and measured using "points". It is known that every story and every estimation is subject to change. After all the features are estimated, they can be organized into iterations in order or customer priority. Each iteration defines how much can be accomplished in a set amount of time. How much can be accomplished in an iteration (team velocity) is based on "yesterday's weather" for the development team (how much did we accomplish last iteration?). With estimated stories and known velocity, we can estimate how long it will take to delivery the features that have been requested. This will give us an estimated release date.

This is defined as the first Release.

This Release and release date should be somewhere between 2-4 months away. If it is longer than that, the release may be too big and the discussion should move to see if what the customer has asked for is really what they need.

This is the power and flexibility that XP gives the team. The Customer has the right to add, updated or delete stories at any time during the release. Developers have the right to adjust estimates of the stories. Team communication is key to the success of this.

In traditional development, we have meetings gather what are deemed as requirements. Typically these requirements are a laundry list of "nice to have", "wouldn't that be cool" and other things the customer wants that are intermixed with what the customer really needs such that the customer trusts that given the right inputs (planning stories, acceptance tests) a reasonable estimate and a quality product that delivers what the customer wants is the output. Similarly the developers trust that the customer, the customer shares responsibility for the success of the project. Over time, the development team learns.

Since the summation of these tasks deliver the basis of business value...

So how do we identify what gives the customer business value at the start of a project using the XP development methodology.

So how do we most effectively deliver business value to a customer when the customer does not know what they want?

A: Focus on functionality first - accomplish core business processes, and count on those accomplishments acting as focus points for further business value definitions. -- JasonBuxton