Semantic Werks

Lean software development is an attempt to take ideas from lean manufacturing, popularized by the Toyota Production System, and apply them to software development. Here are a few of my thoughts after skimming the surface of the field.

Lean optimizes a system to eliminate waste. Waste in software production is undeveloped features, stories, requirements. If you have a backlog of requests, or user stories, then you have waste.

A corollary is that ‘time is money’. A lean software team seeks to optimize development to reduce the Lead Time, or time it takes to move a work item from idea to implemented (tested, accepted) feature.

A lean organization will have access to useful quantitative measurement tools, like cumulative flow diagrams. It is important to always understand how the process is moving: is the work item backlog too large? Where are the bottlenecks?

Lean sofware is built with a battery of tests. You cannot reliably develop software without testing. Constant refactoring is necessary to reduce complexity. My feeling is that this complexity is largely accidental, e.g. poor library choice, bad implementations, rather than essential. Presumably the essential complexity cannot be ‘refactored’ away (unless you are a rabid NIH fanboy).

There are several workflows that might help this process. Corey Ladas has an interesting set of posts on conceptualizing workflows as petri nets.

Limiting work in progress (WIP) can be a useful way to enforce lean principles (e.g., focus on lead time rather than feature completeness). One way to do this is to use a signalling mechanism, popularized as a Kanban board, that indicates when a work item can be pulled from the previous work phase.

Lean is not waterfall. Waterfall is the antithesis of lean: plan and estimate everything ahead of time. The problem for  people new to lean is that the lean process diagram looks very waterfall, in that it is a sequential series of steps. However, iteration and incrementalism are at the heart of lean. We don’t pretend to finish the entire product, but rather, a useable portion of it. If that portion is not to order, the appropriate work item goes back in the queue. Because everything is sequential at some level of granularity (a byproduct of the arrow of time!).

Estimation is evil and forces premature commitment; it is often treated by clients as set in stone guarantee, while the developers see it as a rough, and almost certainly changeable, guideline.

A challenge in a lean system is how to decide what subtasks constitute a work item. There is a time cost involved in assessing what a particular story demands (architecture, infrastructure, human resource). I’ve often seen this glossed over in discussions about lean or kanban, as the authors seem to assume that one has a useful backlog on hand.

Since time is the paramount cost, it often makes sense to apply what the Poppendiecks refer to as ‘set-based’ design: develop several competing options simulateneously, until circumstances force a choice. While there are other costs involved, the opportunity benefit from having the ‘right’ option available is typically higher.This is also known as deferring a choice until the ‘last responsible moment’ or real options theory.

The biggest risk in a lean initiative is that the organization will not engage completely with the dramatic change in thinking lean requires. Lean is not about tools or artifacts, it requires a paradigmatic shift in software development.

I still would like to see some studies on when lean isn’t applicable or useful. Can it work with the JPL processes? Embedded software?

A related question concerns how to teach lean in undergraduate software courses. At the University of Toronto, we’ve tried to introduce agile techniques, typically Scrum sprints, to mixed results (in my opinion). The cycle times and project sizes seem too small to make cowboy coding impossible. This is subject matter for another post, however.

Some references:

• the blog Lean Software Engineering
• David Anderson: agile management blog and book
• Derek Bailey’s article on the Theory of Constraints in software
• Implementing Lean Software Development by Mary and Tom Poppendieck
• #kanban on Twitter

This is a bit of a contrarian’s view of new software methodologies. First let’s acknowledge that to date, no methodology has reduced the essential complexity in software development, and there is still no silver bullet. That said, it seems obvious that software development has its flaws, although not as bad as Standish tried to insinuate. In other words, there does seem to be plenty of accidental complexity introduced with software development methodologies. It is increasingly clear that so-called ‘waterfall’ development methodologies are replete with accidental complexity (and in my view, accidental complexity is synonymous with waste).

There have been a number of improvements suggested. Two popular methodologies (paradigms, really) are Scrum and Kanban (where Kanban stands for pull-based processes). Both seem to be moving to widespread adoption in the industry (Scrum is ahead of Kanban in this regard, I think). And now the real problem starts. As Tom Grant mentions, this is when the bad implementations start. Someone attends a conference or reads a blog, thinks, ‘map the value stream! we can do that!’ and introduces it to his manager. He’s persuasive, and it’s Friday so the manager wants to go home, so a pilot is approved. The champion may even have some form of certification. The result is a half-assed implementation with no senior management buy-in. What is in reality a complex and holistic methodology, requiring paradigm-shifting levels of commitment from the company, ends up failing miserably. There’s push-back against the process — people start to ask where the high-level design is, a crisis arises pulling staff off the project, etc. This is not uncommon in any methodology — the original ‘waterfall’ paper didn’t actually say “lock in requirements first, then develop, then test, and never talk to the customer”

One of the main problems behind this is a lack of objective information on the methodology. Issue 1 is that while nearly every report you read about the process is positive (of the ‘we implemented 2 week Scrum sprints and reduced delivery time by 123%’ variety), they are often biased and don’t control for confounding factors. These aren’t meaningful case studies, but rather experience reports. They typically don’t have a central proposition defined in advance, they don’t explore rival explanations, they don’t generalize to a theory, and they fail to address threats to validity. I’d caution against reading too much into these reports.

For example, we can’t ignore the issue of expertise. For instance, Paul Graham argues that the success of his Lisp-based website, ViaWeb, shows that Lisp is as good as any other language for web development. However, we have no good examples of follow-on successes, and I suspect that what really happened was a) a smart LISP programmer releasing b) at a fortuitous moment. In the same way, the success of Toyota and TPS doesn’t prove that this system is better than any other. What it does show is that Toyota have an incredibly disciplined and focused organization. To my mind, the pillars of TPS — statements like ”go-see” and continuous improvement — are so abstract that they can basically be translated as ‘always do your best’. They don’t strike me as radically different than what any organization that is driven and motivated would come up with. So if Toyota took market share from GM, was it due to TPS or really just the case of a smaller, aggressive company taking over a sedentary and moribund established player? The gas crisis in the 70s certainly played a part, too.

The second issue behind the failure of new methodologies is financial. Consultants and experts with have a vested interest in adoption, not success. Scrum trainers optimize to generate new Scrum masters, not successful Scrum implementations. Certifications prove nothing beyond an ability to sit through a two-day session. This effect contributes to the problem that mushy middle adoption often ignores the core importance of a tool or methodology. There is a focus on the artifacts — the whiteboard display, the continuous flow mapping, the calculation of velocity — over the huge challenge of getting organizational backing for the process. Moving to a lean paradigm for software development is company-changing. It doesn’t seem to me like something that can be done halfway.

Context is important. This is something that thought-leaders usually mention in their writing, but is somehow lost on the wider audience. What worked in Microsoft will almost certainly not work exactly the same way in your organization. It might be a difference in product maturity, developer skill, management interest, etc.

Lesson: organizational maturity seems to be the chief determinant. It’s like arguing that what matters in childhood education is whether you use phonics or ‘look-say’ techniques to teach reading. This focus ignores the massive contributing factors of teacher skill and parental involvement. I’d say that the best predictor of success in adopting a ‘new’ methodology or  paradigm is the nature of the organization, and not the specifics of that methodology.

p.s. I never once mentioned ‘engineering’ in this post.

Having just read a book on Toyota Production System (TPS), and following various developments in lean software development, I was curious to know what Toyota itself was doing with respect to software. Software forms a large part of new vehicles (I’ve heard figures like 50% of new car development costs), so this seems like a good place to use notions like continuous improvement, visual management, waste reduction, etc.

I gather as part of a “Lean” tour of Japan, various Lean software thought-leaders (Mary Poppendieck, among others) had occasion to meet with the head of Toyota’s software division. From the description of the meeting, it sounded like Toyota were doing fairly standard BRUF development — analyze, plan, implement, test, deliver. Some people call this ‘waterfall’ but personally, I don’t think that term has ever been well-defined.  Certainly I doubt anyone has ever said, “Hey, let’s do waterfall on this project!”

So from the initial description, fairly standard development, but, being Toyota, there’s more to the story. Mary Poppendieck elaborated on her understanding, suggesting that in the process control domain, the three month cycle is quite fast (close to some Scrum sprint lengths of 1 month, anyway). There is also some interesting follow-up discussion here and here. The takeaway seems to be that ‘context is everything’.  The other takeaway might be “Toyota isn’t perfect”.

via @agilemanager and @alinahsu