2004 essay: Lean Team Software Process

Comments (4)

Print This Post Print This Post

Email This Post Email This Post

Permalink

I wrote quite a lot of material about Lean software development from 2003-2005, while I was still at Microsoft.  Some of that was published inside Microsoft, but none of it externally.  This is one example.  Some parts appear unfinished, but I left it as-is.

:Summary: Analyze, design, construct, integrate, verify, and deliver one feature at a time until the customer stops asking for features.

Don’t treat software like a product


How do you measure software value?  Traditional methods treat software like a manufactured product, as if it were an automobile or a toaster, delivered in one big chunk, maybe with a few optional features.  But is that accurate?  How many features of Word do you use in any session?  How many features will you ever use?  And why do you have to pay for all of those features that you will never use?  No, the product view of software is not all that helpful, and it forces consumers and providers into an adversarial contract negotiation relationship where the customer must either specify exactly what he wants in advance, or must accept whatever the producer is offering in large monolithic units.

An alternate metaphor for software value is a refined substance, like gasoline or ice cream.  The raw material is customer requirements, domain knowledge, time, and energy; and this is transformed into manifest behavior of a computing system.  This view suggests that software has no more customer value than the sum of the scenarios that it supports.  Then there is no bright line that defines “complete”, there is only relatively more or less value delivered.  When I fill up at the gas station, I need more than one gallon and less than 100 gallons, and when the pump tells me I have enough, I expect to pay the exact value of the utility I expect to receive from the product.  Software can be delivered in this way: keep giving me more until I have enough, then stop and charge me for what I have consumed.

Or it could be like telephone service: I don’t know how much I’ll use, but there’s a range that I’ll probably keep to.  I don’t know when I’ll ask for service, but when I do, I have some expectations of the performance of the service.  We agree that you will supply me with on-demand service at a guaranteed level of performance, and I will pay a fee for that service.  Maybe that fee is pay-as-you-go, and maybe it’s a subscription.  I expect you to give me either option.

Software should be the same way.  I don’t want to tell you what I want the software to do.  I want to tell you what I want to do right now, and then I want you to enable that as quickly as possible in a way that is least distracting to me.  I don’t want to specify what I might want to do next year.  I’ll figure that out next year, and then will I expect you to enable that as quickly as possible.  As the relationship matures, you may start to anticipate what sort of things I might want, and then suggest them at an appropriate time in a way that is not annoying.  Sometimes, I might like your suggestion and then ask you to deliver that, but you had better not burden me with the cost of your attempts to anticipate my wishes.

Ironically, Lean Manufacturing treats manufacturing production more like a fluid, with streams and flows.  If we want to consider software value to be more fluid, then perhaps Lean can supply us with the right concepts and terminology to enable that mode of production.  A suitable name for such a solution might be Feature Factory.

[demand][waste]

Q: How do you deliver value to a customer when the customer doesn’t know exactly what he wants, and you don’t know exactly how to build it?  (see Five Orders of Ignorance)

Q: How do you avoid delivering features that the customer doesn’t really need or want?

A:  Continuous delivery.  Analyze, design, construct, integrate, verify, and deliver one feature at a time until the customer stops asking for features.

How might the Team Software Process apply to this solution?


The advantage of the Team Software Process is the high quality of the code it produces.  How much of the Team Software Process can be applied to such a demand-driven model?  How much of TSP actually depends on batching and queueing feature requests by workflow phase?

Start with TSP as defined, eliminate non-value-add work products, and eliminate gaps in value streams.

[TSP exchanges one type of waste, defects, for another, copious bureaucracy. ]

To eliminate gaps in value streams, we might:

* integrate phases into workflows everywhere possible
* compress non-integrated phases
* substitute short, fixed-length iterations for long, fixed-scope iterations
* substitute feature-oriented task scheduling for component-oriented
* substitute feature-oriented proxy estimation for component-oriented
* implement continuous flow of customer-valued features to production code
* integrate security and reliability analysis into value stream
* implement pipelined continuous integration

To eliminate non-value-add work products, we might:

* substitute measurement for estimation
* implement numerical specification of requirements
* substitute executable tests for requirements documentation
* substitute executable tests or automated design analysis for design documentation

This looks like a lot of change.  However, the core workflow of TSP, as represented by the process scripts, remains largely intact.  There are a few minor changes in workflow steps, but most of the changes are in sequencing.

step 1: reduce TSP iteration scope to a single feature
step 2: factor tactical vs stratgic planning decisions, and assign strategic planning to a new fixed-duration replanning iteration
step 3: optimize single-feature workflow according to the opportunities created by the dramatically reduced scope
[...]

Can this still be considered TSP?


Well, I’m not particularly interested in labels, and the customer probably isn’t either.  How many customers actually care about your ISO9000 certification, if it even means anything at all? TSP is a means to an end.  The customer’s end is high-quality product, where quality is defined only in the customer’s terms.  The customer’s terms likely do not include any notion of defects-per-KLOC.  The producer’s end is profit and reputation, which comes from managing cost and consistency.  If TSP, or something related to it, helps us realize our ends, then (and only then) it is meaningful.