‘Out-Learn the Competition‘ is a phrase familiar to many product design and development folks – it nicely captures the idea that when we are creating software systems, our focus should be on uncovering and generating knowledge about the problem and the solution – not just writing code. In this view of software development, everything we do should focus on creating knowledge as early, as cheaply and as fast as possible. The software then becomes just a manifestation of that knowledge.
This is a pretty radical departure from the more mainstream view that systems development is about programming, testing and deploying. But its an idea underlying all agile frameworks and methodologies – in fact it is the foundation of any empirical process. Using approaches like Scrum, XP and Kanban, we constantly look for opportunities to inspect what we’ve done, learn from that and then decide what we should do next. We try to deliver working, valuable software as early as possible to begin this feedback mechanism. For example, we demo our earliest working features to customers to see how valuable they are to them, how they use them, and what we should build next.
At a meeting with a group of Lean practitioners last week, it struck me again that the common view that Lean is about increasing productivity and cutting costs simply doesn’t apply to software development. We are not trying to churn out more lines of code per person or more features per hour. In fact we would like to produce the least amount of code possible (code is expensive to write, test, support, enhance, etc). What we are trying to do is generate as much knowledge as possible so we can understand and solve the business problem with the least amount of code.
With this view in mind – we could say applying Lean to Software Development is about increasing our productivity in generating KNOWLEDGE, but not about increasing our productivity in generating CODE. This basic fact lies behind the difference between plan-driven, waterfall approaches and agile, empirical methods. It’s also why transferring Lean practices from the manufacturing and repeatable services world to software development can do the opposite of what was intended – kill value, create waste, drive out innovation.
Don’t get me wrong! The principles and values of Lean still apply to software development. For example, ‘Respect for People’ is probably even more important when you need them to create innovative products than when you want them to create widgets on a production line. But how we translate those principles to practices and tools is very different. To use a metaphor, product development, including software, is about creating recipes, manufacturing is about baking cakes.