6 min read

An introduction to lean thinking

Craig Rogers on Apr 8, 2021 11:19:00 AM

An infrastructure for co-ordination could be described by four flows: a flow of work, a flow of knowledge, a flow of information and a flow of decisions.” ¹

The second in a series of three blogs; now that we have explored waste, we can get into lean thinking. My plan is to introduce the lean principles here and finish off the series with some practical tools we could use to start having more lean conversations across the business.

Lean excites me. I know, I should get out more. However, if an Agile framework directly addresses some of the business jargon we often hear; better, simpler, faster, cheaper, smarter for example then I am all for it.

Lean is a flavour of Agile, just like Scrum or Kanban. It’s a way of thinking, a mindset grounded on Agile guidelines and principles. Because it is derived from lean manufacturing concepts, specifically waste and just in time production I think it is very practical application of Agile. We can easily see how it’s been used before and to what effect. And this helps us to visualise and see it’s benefits more clearly.

If you are an Agile team at Eagle Eye, the chances are that you are using Scrum or Kanban or a hybrid in between. Lean thinking has recently been added to the latest Scrum Guide (2020), so if you’re following Scrum its worth learning more about. And the chances are that if you are using Kanban, you have or should have already been introduced to lean or waste at a high level. If you haven’t, then consider these blogs as a backfill till we can do something better.

Regardless of whether you are doing Scrum, Kanban or neither of them there should be something here for you because Lean looks beyond teams and knows that real change often needs to happen from the top and be applied across the organisation.

Tackle the elephant in the room

Lean has its own set of principles, seven in fact.

So, at this point I’m imaging people shouting at the screen, “WE DON’T NEED MORE PRINCIPLES”.

And if you are one of them, fair enough but let’s also consider that Agile is an overarching term which captures the common thinking of the various strands of Agile. If Agile is a toolkit, then the guidelines and principles are tools to reference, guide and use as you wish.

And as illustrated above in the way we are using Agile as stands, there is nothing stopping us from picking our own brand of blend of Agile. Different courses for different horses. Maybe we need a few new, practical and high-level tools in our toolkit to help us on our Agile evolution. And Lean gives us that.

A word on systems

I will find it difficult to discuss Lean in the next two blogs without discussing systems. Systems thinking is pretty neat, most things are a system. An organisation is a system, teams are a system, process is a system, product is a system. When you apply system thinking to things, you see them less emotionally which is normally good. Ok, so we have that tech debt issue we’ve failed to tackle. Shouting about it hasn’t worked. Let’s apply some lean / system thinking to it and try and ensure that it has a measure that is comparable with other work streams.

The lean principles condensed

It has dawned on me that taking everyone through each principle one by one will be tiresome for you (and for me) so I will save us that pain and try and fuse them together seamlessly. Here goes …

Eliminating waste is the most fundamental lean principle. Lean goes hard on waste, and it should do. According to Black Swan², it is not unusual for waiting time on a project to be roughly 80% of the whole project duration. And that’s just one type of waste, the “waiting waste”.

In an organisation that has looked to eliminate waste, there are often many passes at the types of waste so that the organisation is as lean as it can be. It is unlikely a one pass exercise, and likely one that needs the whole business to buy into and support.

Let’s consider this for a moment as I think it is important. You could make a team or a department as lean as it can be (read efficient if you wish), however there would likely be inefficiencies in and around that team which directly influences it so if we ignore them, we are not looking at the whole system and are not optimising the whole.

It’s useful to look one or two levels higher up (or down) to see what is happening as that can directly influence or cause problems. The example often cited in an Agile context is whether our customer contracts are weighted in favour of either party; the business or the customer. There was a study whereby a vice president of a sales company said they could sell an Agile approach 60 -70% of the time.³ Like waste, I’m struggling to think why we wouldn’t be curious about seeing the whole more frequently.

You gain the most value, which in a software business is producing new information when you address something that is high risk or on the critical path first. So, you amplify learning by looking at that big risk or having that team exploration into the big questions that the new feature raises first. Maybe it’s that dive into the new tools that could help with the work. The flip side of this statement is that any activity that does not generate new information is a potentially a source of waste for removal. Old tests which offer no new information but are still run could be perceived as a form of waste for example.

To amplify learning and learning opportunities keep options open for as long as possible aka decide as late as possible. If you don’t, you may be closing a route which would best serve you later. In a volatile, uncertain, complex and ambiguous (VUCA) world, this is more relevant than ever.

We want to encourage wide thinking rather than deep thinking, especially deep thinking early on. Once you’re in that rabbit hole, it can be hard to leave. Lean encourages you to freeze decision making for as long as you possibly can. Defer decisions till the last possible moment. Why? Because by keeping options open you are more likely to make better, more informed and lower risk decisions … and to draw back to lean manufacturing, make just in time decisions where our understanding is at its greatest and our uncertainty is at its lowest.

The principle deliver as fast as possible is possibly a contentious one, however it shouldn’t be. The crux of what this is saying is simply to get fast feedback loops in place. So, if you are doing Scrum you have two-week feedback loops, so long as you hold a review. It’s a good idea to hold a review. When done right, delivering fast can be valuable as it gives us more feedback loops. Feedback loops are critical to learning and improvement as we test what we’ve built and discover new insights and information. Rapid delivery can also reduce risks and complements the decide as late as possible principle.

I’ve left the hardest two till last. Maybe with a more experienced and astute lean head on, I’d have tackled them first (remember back to amplify learning), however hopefully you’ll forgive me.

Integrity shouldn’t be hard for us, it is after all one of our company values, however sometimes it is. You can have integrity in the system, that our product is well designed, works and is reliable. You can extend this out to the organisation level, that the whole system gives a consistent and clear message. The key aspect of integrity is that integrity is higher when information flows smoothly across the business.

[At Netflix,] everybody gets all the information. What we’re trying to do is build a sense of responsibility in people and empower them to do things.” ⁴

And empowerment shouldn’t be hard, however it feels like it is. And this is where I think the other Lean principles really help establish a sense of power within the teams. If we do some of the other principles, you take some steps to start to empower teams. I gave a spiel a while back about trust, empowerment, autonomy and it has dawned on me that I missed purpose. That would have sat nicely in the middle. We need to start trusting the teams to make their own decisions. Hand off power to the teams to make their own decisions, make mistakes, learn from them, grow from them and become more autonomous as a result.

In the book Lean Software Development, there was a section that said that every team should have its own accountant. Now, this may be a step too far, but the premise is good. If a team is accountable for its budget, accountable for its performance then isn’t that a step towards empowered teams? At a base level, we start to give the teams more control on the decisions they can make for themselves. In a world where we realise that our motivators are no longer financial or measures of success, empowerment and autonomy matter greatly.

A lean organisation would understand that we need to empower the people who do the work to make decisions … and help to make that change happen.

Summary

I want to return to the quote I started the blog of with as I think it works well to summarise some of the lean principles.

“An infrastructure for co-ordination could be described by four flows: a flow of work, a flow of knowledge, a flow of information and a flow of decisions.” ¹

Hopefully by now you start to see some lean loveliness building up, an interwoven and intertwined plethora of goodness waiting for you; practical, solid, common-sense, proven, grounded principles derived from engineering and production concepts.

Some key points to take away from this blog: