|
There are a variety of principles to choose from when considering adoption of lean software development. There’s the “2 pillars of the Toyota Production System,” or the “14 principles of the Toyota Way,” or “5 principles of Lean Thinking,” or “7 principles of Lean Software Development,” or even “Deming’s 14 principles of management”. And of course, there’s always the old “Agile Manifesto”.
While I think there’s value in most of those things, so much choice leaves a lot of room for interpretation. That can be a good thing, but it leaves me searching for something more fundamental. Before I can get into questions like “why should I be lean?” or “what should I believe in order to be lean?,” first, I have to ask a deeper question: under what conditions is lean software development possible? You might need some of that other stuff in order to act on your goal, but you may not get so far until you are clear about the most basic premises of the problem. To that end, I propose two simple axioms:
Axiom 1: It is possible to divide the work into small value-adding increments that can be independently scheduled.
Axiom 2: It is possible to develop any value-adding increment in a continuous flow from requirement to deployment. The first axiom is not specific to lean software development. It is the premise behind iterative, evolutionary, and Agile development, and has been studied and applied for many decades. It might continue to be a difficult concept for some, but not due to any lack of literature or examples in the world. If iterative development is possible, then lean development may also be possible. The second axiom is more specific to lean development. Lean’s evolutionary predecessors have had much to say about problem definition, team composition, and development practices, but less to say about workflow and detailed operational scheduling. Agile, in particular, seems to encourage a romantic trade-guild culture that resists the kind of systematic discipline that is required for lean thinking. Continuous flow implies we’re going to have to say a lot about how people can work together in order to avoid wastes like inventory, delay, rework, and overproduction. Stating our premises in such stark terms enables us to visualize the problem more clearly: What would a continuous flow of new feature development look like? What would need to happen, and in what order? What resources would need to be available to make that possible? How would roles and responsibilities need to be defined in order to make those resources available when needed? What is the ideal flow? What is the best flow we can achieve with the capability at hand? How can we improve in the direction of the ideal? Then you may find that some of those other principles are necessary to help you realize your goal. |
{ 2008 08 25 }
Kanban discussion
Post a Comment