Lean Software Engineering

Process change is a difficult business. People get attached to their habits and tribal affiliations. People resist changes that threaten their social status. Effective process change addresses human issues of fear and hope before interfering with workers’ routines. Deming and the Lean thinkers have much to say about this. One thing you can do is to take an evolutionary approach and keep changes small and incremental whenever possible. Sometimes disruptive changes are truly necessary, but they are also risky and should be treated as such.

One of the things that I find most implausible about Team Software Process is the notion that you ought to send everybody off to boot camp for a few weeks in order to successfully launch the process. If that is a precondition for success, then you should brace yourself for failure. If you have to make a big, discontinuous change, it should be done quickly and decisively, and facilitated by experts. If you know where you want to go, and there is a smooth and incremental path to get there, then you should follow it.

If you are starting from a phased, waterfall-type process and you have functionally-aligned teams, then you might start with a Kanban process. I’ll describe the process for setting up a Kanban system in a future article. If you have more project-aligned teams, then you might start with Scrum or Feature Crews.

If you are already using Scrum, Feature Crews, Feature Driven Development, Extreme Programming, or something similar, then you can use that as a starting point. As long as you are consuming customer-valued work and following through to continuous integration, then you have a foundation to build from. From here you could tackle the front end, upgrade to a Kanban process, or you could upgrade your core engineering workflow. Let’s assume that we’re doing the latter for now.

Since Extreme Programming gives us a nice concrete model to work from, let’s start with that. If you can read between the lines of all of the religious rhetoric of XP, then you might see that it’s a scaled down implementation of a V Model workflow. Most of the individual XP practices are concrete implementations of specific V Model states. The notion of the “irreducible interdependency” of practices is a ruse to keep you buying books and training and consulting. Once you start to look at it that way, you may then feel emboldened to substitute those practices with alternative practices that serve the same function with respect to the V Model.

For example, Test Driven Development, if it is done well, is very much like Design by Contract. Given the right tools, Design by Contract is, in turn, a form of Formal Specification . If you are feeling scholarly, Edsger W. Dijkstra’s 1976 book, A Discipline of Programming, explains a design process which is very clearly the origin of both TDD and Design by Contract.  I like to think of TDD as Design by Contract for Dummies, and DbC as Formal Specification for Dummies, so if you’re looking for an opportunity to upgrade your practice, implementing Design by Contract would be an excellent start. And remember, the way to do DbC right is write your postconditions first!

You could also replace Pair Programming with the Capture/Recapture Code Inspection. You could insert Pugh Concept Selection before coding. You could insert Failure Modeling and Threat Modeling before Acceptance Testing. You could add multiple integration stages and insert Taguchi Orthogonal Array testing. You can do any or all of these things (and more) as they are needed. We’ll get into much more detail about all of that as we go along.

But first, if you are practicing Extreme Programming ™ today, please stop thinking of it as Extreme Programming and start thinking of it as Lightweight Lean V Model with Practice Set { Onsite Customer, TDD, Pair Programming, … }.