malvasia bianca

I just finished Lean Thinking; it’s my current favorite lean book. One thing that made me jealous: they give several (to me) convincing examples of companies wanting to try out lean, and that brought in some people who really knew how lean worked. After doing what those people said, they immediately got some fairly impressive improvement. But they then managed to improve on this continually over the next few years.

Which, among other things, serves as a counterpoint to some thoughts I’ve been having, and that seem in the air in general. (See, for example, Martin Fowler on agile imposition.) It’s been clear to me for a while that my team’s agile adoption would have been vastly improved by bringing in an outside expert some time ago. (It would probably still be vastly improved by that.) But, among other things, doing so would be tantamount to my saying “we’re going to do XP, plain and simple”. People may hear me as saying that already, but I don’t intend to be saying that. What I would like to be saying is “here are some things that are really important to me” (high quality standards, sharing knowledge, responding quickly) and “I haven’t heard of anything that sounds as effective as XP to reach that goal”.

So one aspect is that I’m jealous of people who have built up the support where bringing in an outsider to show them what to do is effective. But another aspect is that I’m also jealous of people who have concrete touchstones that they can use to continually approve. This is something that, perhaps, XP isn’t so helpful at. The concreteness of the practices can be very useful if you need something specific to try. But they have a finality about them that (to me) makes it hard to use them as guideposts for continuous improvement. For example, we don’t pair program all the time. I’m willing to believe that we’d be more effective if we did, but I don’t have any great way to convince people (even to convince myself) that doing so would be a good idea, and taking it on faith will only go so far. In a current thread on the XP mailing list, Ron Jeffries proposed telling people to find a way to “deliver working software monthly”; a lot of people are willing to believe that that’s a noble goal, but getting from there to XP is a pretty big step.

So what are intermediate goals that can help you see ways to continually improve? (Through which you might end up at XP or might end up somewhere else; if we can continually improve, I really don’t care about anything else.) Here, I think lean manufacturing has a leg up on agile software development: they have goals at a similar level to agile goals (single piece flow or just in time / pull are probably at a similar level to incremental development and no bugs), but I get the feeling that they have more ways to see flaws and to translate those flaws into concrete improvements. (Categories of waste, or stop the line when you see a bug, combined with root cause analysis, for example.)

Or maybe agile is just as good at that; it could (in all honesty, I’m not being facetious) just be my lack of knowledge combined with my lack of skills in the appropriate areas.

Something to work on.