Comments on: 2004 essay: Lean Team Software Process

By: Ben

Ben — Thu, 18 Mar 2010 09:01:28 +0000

An interesting article. As I was reading it I found myself wondering about software like Microsoft Word. I’d suggest that if you’re developing something like Word, where the requirements from a broad range of users must being considered from the offset, your software-as-a service model wouldn’t work. And you could say, well yes, maybe not all software can be developed this way. This leads me to think: how much of the software many of us must develop each day can actually be thought of this way?

I read a fair amount about agile and lean development (and our team has been using Scrum for a few years now) and the thing that strikes me more and more these days is that perhaps it’s not as appropriate in as many cases as the wealth of blog-age on it would suggest!

By: Curious Cat Management Improvement Blog » Management Improvement Carnival #65

Mon, 01 Jun 2009 14:45:05 +0000

[...] Lean Team Software Process by Corey Ladas – “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.” [...]

By: Lean nello sviluppo di software | Encob Blog

Lean nello sviluppo di software | Encob Blog — Thu, 21 May 2009 06:59:06 +0000

[...] trovato questi due articoli che parlano dello sviluppo software in maniera lean: uno è di Corey Ladas, ex sviluppatore Microsoft, l’altro è un articolo di Eric Ries (autore del blog Lessons [...]

By: Corey Ladas

Corey Ladas — Thu, 21 May 2009 03:02:23 +0000

What’s interesting to me about this is how many ideas are already baked into such a short essay:

* one-piece flow
* customer pull
* value-denominated work items
* gemba / genchi genbutsu (go and see for yourself)
* rolling wave planning
* service-level agreements
* inventory limits
* value stream maps
* workflow management
* integrated security and reliability engineering
* continuous integration
* continuous deployment

…and that is on top of a process definition that is already based on Statistical Process Control, standard work, and continuous improvement.

I started this essay in Spring 04, around the time of the first “Scrumban” process definition. This draft is from Autumn 04, according to the timestamped revision control logs.