In her presentation at Agile 2005 Workshop, Mary Poppendieck, talked about 1/3-2/3rd contracts. We think this is an interesting way to structure a collaboration schema for engagement of Agile teams. Here is how it can work:

• The team/ analysts get together with the product owner or customer and write down the requirements and understand the acceptance scenarios as well as objective for each of the requirement.
• The product owner or customer would prioritize the requirements to arrive at a “can’t live without” list of requirements. You can use YAGNI for business value as well.
• The team can provide an estimate of the complete project using whatever estimation methodology they choose.
• The team then calculates what is one-third the time of the project.
• Based on the initial requirements list, the team and product owner would further narrow down only the main work flow requirements.
• For these requirements, the team does further analysis to define acceptance scenarios, presentation and task planning.
• The team develops a no whistles working version [yes it does calls to database and all functionality is actually working] of the project in 1/3rd the time.
• After 1/3rd the time, the team can get together with the product owner and review the functionality.
• After this, we would encounter the following scenarios:
  • If the product owner or customer like what is happening and the original requirement list still stands - continue and develop the project with the confidence that it is moving in the right direction.
  • If the product owner or customer don’t like what is happening and would like to change the requirements or assumptions, then you can do so. Although, this is not ideal, it is still better to do this when you are only 1/3rd done than when you are a 2/3rd done or worse when you are 100% done.
  • More than likely the process of actually getting down to development would uncover and test hypotheses, priorities and assumptions used while actually developing a project and generate new and better idea on how project should actually be developed.
• If you do not decide to change, then the original contract still stands. If you do decide to change, then the team and product owner can discuss the project from a new perspective [almost like a new project].

It is important to note that working version of the functionality above is different from a proof of concept. Proof of concept focuses on determining feasibility of an idea or approach, rather than determining the usability or effectiveness of ideas or approach. The proof of concept might be a step in the 1/3rd - 2/3rd approach but not by itself would be a complete 1/3rd of the project. A software prototype can sometimes work as good way to approach 1/3rd of the project. However, for a 1/3rd - 2/3rd approach, you actually develop 1/3rd of the project. For one project user interface might be the single most important aspect and hence, that would be first addressed during the 1/3rd of the time via a click through prototype. For another project, a core workflow of how various members interact would be important and hence, calls to the database might be important. The 1/3rd of the developed project is incrementally and iteratively enhanced and not thrown away unless found completely unusable.

When the product owner or customer and the team are on their first project or first release together, they can estimate the project in detail. However, as they understand each other and learn to work with each other, the estimates and requirements discussion can be high level or as low level as needed. Hence the above process would work like this:

Rough requirement discussion — ballpark estimate provided — 1/3rd of estimate calculated — 1/3rd of requirement list discussed — 1/3rd requirement list detailed — 1/3rd requirements developed — Feedback

The advantage of this approach is that overhead of meetings and discussions is less and you actually get down to focus on your core functionality sooner.

An important question is to understand why 1/3rd and why not 1/4th or 1/5th or even 1/2 of the project. Well a simple answer is that you can pick a number as you want. For a risky project or unclear domains it is recommended to ruthlessly prioritize and re-prioritize your requirements, you could go to as low as 1/5th of the project. Using the Pareto’s Principle, 20% of all requirements would generally give 80% of all business value. However, doing anything more than 1/3rd is keeping feedback away longer and hence, inherently more risky on relatively risk free projects. If you have multiple workflows that would need to be tested, prioritizing is important. If this is not at all possible [which is highly risky as well], you can start two 1/3rd approaches relatively separately. Even if a contract is not specifically constructed as a 1/3rd - 2/3rd contract, it makes sense to develop each project in this way.

Popularity: 17%

Posted on January 18th, 2008 by admin
Filed under: Collaboration, Outsourcing 2.0, Pricing | 1 Comment »