What is Lean? Why Do You Need It?
It’s a management system that aims to better serve customer needs with less time, less space, less hassle, less money, fewer people… less less less less to do more.
If you’re in the software business (actually, most services to business), and you want to grow organically – without simply buying capacity through adding staff – you need to grow the business faster than our costs. Which means billing customers more with (relatively) less time, space, people, investment… you get the picture. Without becoming Leaner, you will thrash around, over-obsess on mis-targeted cost-cutting without ever being able to increase your leverage.
What does being Lean entail?
It’s actually quite simple at heart — it’s
- An appreciation of what the customer will pay for (aka value).
In our case, this is often the realisation of business ideas as working systems. It’s the only thing that justifies our existence, by the way. If we don’t create value for customers, we die, and deservedly so.
- An understanding of what tasks actually create that value (aka end to end processes),
Creating value happens as the business idea is transformed into working systems; as it is elaborated into detailed expressions of how the system will work, from text to code on the production system. As organisations, we do this best in standardised processes — we consistently do the right thing in the right order at the right time.
- A progressive engineering-out of everything else (aka waste).
From one point of view, Marx was right: value is created by hands-on work — by technical team members, not by management. It’s very easy to assume therefore that where technical team members are working hard, they must be creating value, but this simply isn’t true. In many Lean assessments, you discover that as many as 9 out of 10 process steps don’t add any value – they don’t perform the transformation that the customer is paying for. The way we achieve being Lean is removing the mindset of working hard is connected to creating value, and look to remove work that doesn’t create value. Less work, more output, more revenue, less stress for all involved. Sounds good, doesn’t it?
Most Software Can (and Should) Be Lean
Most of the methods for becoming Lean arose from manufacturing where standardised processes can be consistently improved to engineer out the opportunities for waste, but when you talk about this in a Software context, you regularly get pushback on the grounds of uniqueness.
(You want to know a secret? Almost every industry and every organisation claims to be unique, far more unique than they actually are. It’s 80% Everybody love ME ME ME for I am a UNIQUE BUTTERFLY posturing and about another 15% misplaced fear of manufacturing as Dark Satanic Mills where no-one’s allowed to think. Lean started from the standpoint of using the intelligence and creativity of everyone, particularly the shopfloor people who actually create all the value)
But I fundamentally don’t think that’s true to anything like the extent claimed. Most enterprise software delivery actually takes place to enhance or repair existing functionality, rather than to uniquely create something new. Functional changes and fixes are normally delivered as ongoing work efforts by standing teams.
A Project is a temporary endeavour undertaken to create a unique product. The temporary nature of projects indicates a definite beginning and end.
An ongoing work effort is generally a repetitive process because it follows an organisation’s existing procedures
PMI – PMBOK® Guide Fourth Edition
This doesn’t mean that projects can’t utilise ongoing work: think of a house build project; many components of the build such as doors – even bespoke ones – are produced using continuous methods. In many enterprises, change is sponsored via Project vehicles, but delivered by continuous work.
Software Change is most effectively and efficiently delivered without overhead that Projectised delivery requires to manage the Risk that comes with uniqueness – it is more akin to traditional manufacturing and continuous service delivery where some variables may be tailored, but the overall process is an ongoing work effort.
The appropriate model for most Software Delivery is usually not that of a Project, but of a Production Line, where Lean methods work better than anywhere else.
This is analogous to the paradigm shift that Henry Ford went through – prior to his production system, every car was built as a Project: a unique, temporary endeavour, delivered by its own unique team. Ford’s system significantly reduced the cost of delivery, while raising quality, rate of delivery and employee satisfaction; all characteristics that business sponsors of Software Delivery constantly (and rightly) demand.
Besides, in the era of capable enterprise software, 80% of a client’s needs are delivered by core functionality that’s common across industry, and the vast majority of the rest is can be achieved with configuration & data. As Schmidt & Lyle observe:
The distinction between “assembly” and “development” is fuzzy at best. As software development tools have continued to mature and morph over the years, the line where development stops and configuration begins has continued to move. In any event, the intent with the [Integration] factory is to truly achieve a metadata-driven assembly process rather than a custom development process.
Yes, there’s a place for custom-build, unique software, just as there’s a place for custom-build, unique cars — just ask Red Bull Racing. And often it is in rarified, highest performance environments — settings like stock trading where the speed of light across the Atlantic is a limiting factor. But for the hugest market segment, true custom coding is like craft build of individual cars — stone dead.
How Do You Start the Lean Journey?
Yes, there are many tools and methods available — Kanban, 5S, Pull Production, Takt Time, Kaizen workshops and more. But to focus on these is an over-simplistic, entirely wrong way to go about becoming Lean.
The fundamental shift is one of culture.
We must build a culture that enables, supports and rewards improvement.
At its heart, everyone in the business (and I mean everyone — from the apprentice to the executive) needs to develop strong mental circuits not for solutions, but for how to develop solutions — a fundamental shift from quick fix jumping to answers to the longer term, more painful but more successful process of deeply understanding problems before jumping to fix them.
To do this, everyone needs to develop the habit of asking 5 simple questions every day:
- What is your target condition here?
- What is your actual condition now?
- What obstacles are now preventing you from reaching the target condition and which one are you addressing now?
- What is your next step?
- When can we go and see what we have learned from taking that step?
To be remotely successful at this, you need sponsorship from the highest level in your organisation to take the time to ask the questions, respond to them and to coach it pervasively throughout the business. It’s not additional to the day job — it is the day job.
Can You Change To This Model?
Henry Ford put it best:
Recommend this post
Whether you think you can, or think you can’t — you’re certain to be right.
Latest posts by Martin Burns (see all)
- Christmas Reading: 6 Books That Will Change Your Thinking - December 22, 2017
- Now Is Not The Time for #NoProjects - December 14, 2017
- Speaking at Agile In The City London 2018 - November 27, 2017