Lean has been described in many different ways. The view I am promoting here is specifically for Lean being applied to software development. This is quite different than when Lean is applied to problems in the physical world such as manufacturing and product development. Software has unique challenges and they require a different method of applying the Lean mindset and principles.
Lean can be thought of as a combination of mindset (belief system), principles used for guidance and practices.
The Lean Belief System
Take a systems thinking approach. Systems thinking tells us we have to look at the whole. That focusing on aspects of our challenge will result in unanticipated side effects. Furthermore, the belief is that the system within which people find themselves almost always has a greater impact on their performance than their abilities. Hence, when looking to improve the performance of an organization a Lean-thinker will look to improve the system and not so much the people in the system. This is in direct contrast to most of our popular methods which tend to focus on only certain aspects of the systems within which we find ourselves (see Framework Tunnel Vision).
People will do well in a good system. You can think of this as Lean’s perspective on ‘respect people’. ‘Respect people’ is a mantra of the Agile community but it’s hard to tell what that means from a decision point of view. Respect people to do what? To do their best? While that may be true, doing their best may not be good enough – not if they are in a bad system. Systems thinking and believing that people need a good system within which to operate means we must focus on improving our systems as well as our people.
Be committed to quality. This has often been called ‘build quality in’ but it is much more than that. It is a commitment to high quality – to not just the quality of the product, but to the quality of the process. Yes, the process – that very word which is somewhat denigrated in the Agile Manifesto. Be clear, I’m not saying we should be committed to a process, rather I’m saying if we think there is a method by which we’re supposed to work then we must work that way to achieve our best results. In other words, we don’t have conversations about ‘is this good enough?’ For example, if we say that we believe having test specifications are a good thing then we always have them. We do this because we have a belief that the system causes most of our errors, our process is part of our system. Hence, if we have errors then we most likely have something wrong in our system. If we don’t fix it now, more errors will result. More waste, more cost. If you have a leak in your basement when do you fix it?
A Commitment to Continuous improvement. One of the innate human characteristics is to strive to improve. Improving our methods is more than a business imperative, it is essential to provide meaning to one’s existence. Continuous improvement should involve how we work and be and not just the results of it. There is a business an human aspect to this. Both very important.
Leadership. Unlike the Agile Manifesto which does not mention management once in either manifesto or in its principles, Lean puts a strong requirement on management to lead an organization in the beliefs just mentioned. This is managers as leaders.
Lean Software Development Principles
Drive from business value. Lean is about the delivery of business value incrementally, predictably, sustainably and with high quality. Driving from business value provides both a great return on our capabilities as well a method of aligning across the organization. As Don Reinertsen says – “There is more value created with overall alignment than with local excellence.”
Create Visibility. This means visibility of our work and our agreements. Our agreements are both between management and those doing the work and between those doing the work. These typically involve creating explicit workflow agreements. These explicit agreements enable everyone to know what is going on and is the basis for Lean’s visual controls. Visual controls are a special kind of information radiator that visualizes both he work and how the work is being done.
Achieve flow through the elimination of delays and rework (eliminate waste). This is often characterized as “just in time.” While developing software (either in IT or product development) is not the same as building cars, this mantra is orders of magnitude more important in software than in the physical world. I would suggest that all challenges in an organization will manifest themselves as a delay in feedback, a delay in feedback or a delay in value delivered. It stands to reason then that a focus on eliminating delays will improve our workflow.
Manage queues and work in process. It is important to both not be working on too many things and not have too many things be waiting to be worked on. Working on too many things causes delays in our workflow. It causes people to wait on each other. While people talk to the clear task switching that results the much more insidious aspect of this is just having work wait around. This is one of the more important aspects of Lean – it shifts our focus from doing what we do better to eliminating the delays between the work itself. Again, in software this is way more critical than in manufacturing or physical world product development. A quick look at what happens when delays between code and test occurs provides huge evidence for this.
In Summary
I am suggesting to look at Lean as a combination of mindset, guidance and practices (which I admittedly haven’t specified as yet).
Core Lean beliefs include:
- Taking a systems thinking approach
- That people will do well in a good system
- We must be committed to quality
- We must have a commitment to continuous improvement
Lean Software Development Principles include:
- Driving from business value
- Creating visibility
- Achieving flow through the elimination of delays and rework (eliminating waste)
- Managing queues and work in process
It is important to note that we can take these beliefs and principles and apply to them to any set of practices we undertake. We can also use them to see why some frameworks and methods work and how we can improve them. The question isn’t whether you should be doing Lean or not. The question is whether Lean’s beliefs seem right to you.
Al Shalloway, CEO
Net Objectives
