Lean Thinking and Software Design

Lean software development is a subset of Lean Product Development, not Lean Manufacturing. It is foolish to blindly apply Lean Manufacturing practices to software development. The underlying principles of value, flow, pull and waste remain the same, but the way these principles are applied to software development will look fundamentally different.

Successful software development is about building the right product at the right time for your customers. This means focusing attention on the right places in the portfolio of projects and products that your company provides, and optimizing the entire value stream from "concept to cash" for your customers and the development teams.

Agility is so much more than just adopting Scrum or some other agile process framework. Agility involves adopting a new set of values and principles, and then applying practices through the entire software development lifecycle and beyond in order to provide value to customers earlier and more often.

Agile software development should consist of frequent feedback loops, intense team collaboration, continuous improvement, business and customer involvement, baking quality in and consistent delivery of valuable software. These characteristics are derived from Lean disciplines that can transform software development work and the wider organization.

As Paul Hodgetts points out in his excellent Lean is More whitepaper:

I would put it even more strongly than this. Much of the work software developers do is invisible, particularly when it comes to the thinking involved with design.

It’s not about the mechanics of the process, any more than writing a song is about the mechanics of playing the instrument or enjoying a meal is about the nutritional content of the food. Such reductionism is a false hope for improvement. For example, seeking to create a more efficient process by reducing or eliminating design-related activities in software development as waste (such as design meetings, writing design documents, refactoring etc) will inevitably lead to a product with little conceptual integrity, and fast-track it towards becoming a Big Ball of Mud.

Asking developers to track hours, rather than value delivered, as a measure of productivity is the fast-track to dysfunction and decreasing productivity. Let’s not reintroduce Taylorism to software development through the back-door of Lean.

To see this more clearly we can look through at Kanban and Scrum the lens of lean and agile principles. Kniberg and Skarin, in Kanban and Scrum: Making the Most of Both, point out that Scrum and Kanban are both aligned with the values and principles of both Lean and agile. For example:

While the batch sizes in Scrum are much larger (batching work into timeboxed iterations) and thus likely to not be as lean as Kanban, producing shippable code every 2 weeks is certainly much leaner than a more traditional process which might integrate and release something 2-4 times per year. The shorter you make the iteration, the more you are approaching Kanban.

As a DDD practitioner, one area where I think the careful application of Lean thinking holds a great deal of promise is in strategic design:

Many teams feel that they constantly have to adopt expedient design approaches to meet Sprint deadlines, but Lean thinking combined with strategic DDD frees the team to focus their design work where it matters most. This is for the competitive advantage of their business. It encourages them to reduce the amount of code they write themselves, cultivate domain knowledge, and explore models collaboratively with the business to maximize the potential to develop innovative custom software solutions that leap ahead of the competition in the marketplace.

To learn more about Lean Software Development, I highly recommend Implementing Software Development by Mary and Tom Poppendieck.