I’m not here to go into too much detail on the notion of LEAN’s history. Many agilists will talk to you about its history all over the Internet, but broadly, it came from manufacturing & specifically, Toyota. They helped develop & pioneer the ‘TPS – Toyota production System’ based around leveraging a JIT method or ‘Just in Time’ delivery technique on the factory floor.  The notion being that waste was minimised, be that material or time. You can read more about it here.

In Agile we think about MVP all the time, ‘Minimal viable product’ but the reality is often nothing like it. Scopes of work, contracts & client’s headspaces are not wired up to cope with something that’s an MVP. Everyone despite any Agile transformation programme, often still thinks in Waterfall. It’s nice perception of safety, knowing what’s coming & when, even if its set in complete fiction. Often a finished commercially viable fully gold plated product is the only thing anyone wants. It’s difficult to sell something that’s not fully complete.

And that’s a problem. That’s ‘the’ problem.

Agile delivery teams are more than comfortable with an MVP. I often use the analogy when trying to describe software product iteration to clients, the way Apple update IOS. You spend £1000 on a device running an operating system with bugs & you give it no thought when you’re in the store.  Periodically, updates roll in & the product is enhanced or bug fixed. Yet business leaders want their product or service 100% perfect straight from the off. They don’t want the notion of a flawed product. They want to give their customers the best, from Day 1. No exception.

Typically, Lean is adopted to increase efficiency, only doing the minimum work needed which is valuable, & then iterating that. No gold plating. In a factory setting, it reduces raw material waste, unused off-cuts, that kind of thing. On your project, it has a direct impact on your bottom line. Your margin. What you’re trying to do here, is not do anything ‘extra’ than either what is agreed, in terms of outcome & value & then iterating on that or additional work just to make yourself feel good.

Agile culture & leveraging a LEAN mentality.

That very production system mentioned earlier was rebadged. It went from that, to what we know to be Lean. John Krafcik coined the term Lean in his 1988 article, ‘triumph of the Lean production system’ – the over-arching elements of Lean can be quite complex, comprising of multiple components. Four different notions of Lean are recognized;

• Lean as a fixed state or goal
• Lean as a continuous change process (becoming Lean)
• Lean as a set of tools or methods (doing Lean/toolbox lean)
• Lean as a philosophy (Lean thinking)

Those last two are what this post focuses on.

Let us first understand the key differences of Lean & Agile

Agile – teams emphasise small batch sized work, done in rapid increments to deliver quickly

Lean – teams increase speed by managing flow (usually by limiting WIP)

Both Agile and Lean tend to prioritise customer satisfaction as a primary goal. Agile teams achieve this through focusing on open communication between end-users, & the delivery team.

Lean teams put customers first by focusing on & building foundational processes that allow them to in effect, minimise waste. For me, Lean is much more of a cultural mindset shift rather than a set of tools.

That discipline is one of the biggest issues teams struggle with when implementing Lean on a project. Successful Lean implementations are typically those in which Lean thinking have become part of the mind DNA. Teams do it day in & day out, with the focus on minimising any kind of waste, including time.

Agile teams I work in are often bound to a backlog. Bound to the notion of estimating via arbitrary story points. Bound to a daily stand up & churning through tasks which include preparatory tasks or gold plating for the benefit of the teams confidence. ‘doing it properly’ is transmuted into ‘trying to prepare for everything in case the customer shouts at us’ – with technical delivery, time can be haemorrhaged by working like this. Also, engineers don’t care about the projects P&L do they.

Take the following very simple scenario;

A customer of mine asks me for a website. They want half a dozen features & aren’t quite sure how they want it to look, nor how much budget they have. They are feeling it out.

I could;

1. Produce a low or medium quality prototype outside of the customers comprehension because they aren’t used to wireframe prototypes of websites, safer for me but more confusing for the client
2. I could build a development pipeline (because I may need to build one anyway to satisfy future work for the client), create a backup, resiliency & failover, register a domain & ….I’ve spent three days at this point….
3. Spin up a WordPress site, use a pre-built template, chuck the features in & put it in front of the customer.

I’d always go for c but I know tech folk in my teams who would physically convulse & recoil in absolute horror at that suggestion. But you see, that’s Lean. The customers not going to be happy with that revision, but it eliminates waste & gets us to a viable valuable product as quickly as possible. The customer won’t care about Devops, or backups & wont understand prototyping. They want something they can feel, use & touch so in this example I’ve picked the quickest way to get to a point of value.

Let’s take a second scenario.

I’m about to kick off a project. A standard project, & I get everyone together. We talk about Sprint 0, we talk about getting to know the team. Maybe I run a few warm up get-to-know exercises, two truths one lie for example. Maybe a Lego Scrum session to get everyone’s Agile juices flowing. We set up a Confluence page, a Jira backlog (spit) draft some loose Ways of Working, we get access to the client systems, sort out licenses & hardware needs, and ….we’re two weeks in & haven’t got near the client deliverable. That deliverable happens to be a website. There’s at least four people on the team who could build the site loosely, right now without all the toot above.

I go and update the client after the first sprint, Sprint 0. I tell them all the wonderful preparatory stuff we’ve done. The client, couldn’t give a shit. That could have been two weeks developing value FOR THEM.

That’s the dichotomy of Lean.

Seven Tenets of Lean thinking

The ‘value steam’ is the process end to end which starts with a trigger, (could be an operational value stream or a product/functionality value stream) which whereby when the process is completed, value is delivered to the end user/customer. Lean thinking involves making that process as short as possible, whether its feature release or operational/process efficiencies through things like automation.

Eliminating waste (2 above) focuses specifically on ensuring you are not adding process steps for the sake of it. This requires a considerable amount of discipline.

Not starting too early allows you to adapt rather than having even the most Agile plan locked in. Important & culturally treating people with respect is hugely important.

A manifesto for lean includes;

• Out of respect for our customer, we make decisions which bring the most value with minimal waste
• Out of respect for our employee’s we create environments that allow everyone to do their best work
• Out of respect for our co-workers, we continuously strive to optimise our processes to allow everyone to deliver the most value they can provide.

 Some practical events

Whilst very similar to some Agile events, Lean practices ‘Kaizen’ which is a Japanese philosophy to the commitment to ongoing improvement & personal efficiency. There are some mechanised events you can run to help promote, and work within the structure of Lean (some of these will be familiar with practices consultants already);

DMAIC

It stands for Define, Measure Analyse, Improve & Control – each being obvious.

Define

• What is the significance or business impact of the problem?
• Who is the customer? (Customers can be internal or external.)
• What processes, business units or people are impacted?

Measure

• What are the key performance indicators for the process or situation to be improved?
• How will we reliably measure the current state and the change over time?
• Who will be responsible for measurement and reporting?  How often will data be collected?

Analyse

• What are the potential causes of the problem?
• What priority should be given to each cause?
• How can the data be visualized to bring clarity to the root causes?

Improve

• What is the plan for improvement and how will it be implemented?
• What are the risks of the plan and how can they be mitigated?
• What are the results against pre-defined performance measurements over time?

Control

• How will we document the improvement?
• How will the process be monitored over time to protect against breakdown?
• What have we learned that can be shared and applied in other areas?
• Who do we thank for our success?

5 Whys

Once in a while, leadership is met with subtle, usually quiet resistance to change. Employees either grumble about the programs or simply fail to engage. When we dig into what causes this in some organizations, we often come to the same conclusion. Employees equate identifying problems with pointing fingers at people. They are afraid that improvement and the blame game go hand in hand. The 5 Whys technique is a great way to address this impediment to change.

I built & used the template below on several occasions to extract the why analysis from a particular problem statement. You could do something similar.

There are other ways like A3, but it’s all very similar.

Catchball

It’s a bit of a basterdisation between Agile’s three amigo’s, a PI increment planning session & an experiential retro. Use a physical ball, get everyone in a room & assign one person to outline the problem statement, case for change, etc. The idea being you’re creating a bi-directional feedback loop. Catchball is an effective method of gathering information and promoting discussion around any improvements under consideration. It is most often used for complex initiatives that involve multiple departments, roles, or processes. It is ideal for these situations because it ensures that everyone who should be providing input has the opportunity to do so and can be heard without interruption. Value stream mapping, standard work development, and Hoshin planning are all examples of situations that go more smoothly when catchball is used.

What I’ve learnt so far.

• Lean isn’t Agile, its more, the distillation of what Agile attempts to be. It requires a lot of focus & effort to be a Lean thinker & then stick to it throughout the team.
• It’s often a good idea to warm the team(s) up to the notion of Lean & the focus needed. Especially if they have to work within the broad constraints of their organisation.
• Leveraging hackdays or short focused periods with hypothesis driven outcomes gets everyone into that Lean mindset – everything should center around this notion of validated experimentation.
• You have to as a DM find the sweet spot between project governance & robustness but still doing lean. Ultimately, Lean doesn’t give a crap about backlogs & story points. It cares mostly about validated outcomes & customer satisfaction & getting there as quickly as possible.
• Focus on customer value: Focus on delivering value to the customer by understanding their needs & preferences, and by designing process that deliver products & services that meet those needs.
• Use visual management. Draw pictures over written words. Lots of pictures, lots of Post Its, we’re visual creatures so leverage that.
• Create & foster that culture of continuous improvement & starting from the imperfect.
• Encourage the team to share ideas for product or process improvement & using LEAN tools such as Kaizen events & process mapping to identify improvement areas. Get the team to take accountability for their work.