Dear Gemba Coach,
We have a new boss who doesn’t know lean and is asking our lean team to switch to “agile” instead. Any advice?
Tell your boss you’re already doing agile – there is no real difference between agile and lean. The boss isn’t always right but the boss is always the boss. An iron rule of psychology is that people reduce complex problems to the part that they think they can solve. A great insight of lean is being able to make hypotheses about how well a place is doing (and going to do) according to what problems the boss takes on, how do they frame them, and how to they go about solving them (with people or my-way-or-the-highway), and what kind of solutions they prefer.If you’ve been using lean kanban techniques to establish a closer information flow between designers and developers, then agile will probably be a step back.
The real question is: what are you losing from dropping lean and adopting agile? It all depends of what kind of lean you practice. In some cases, you might be making a step up.
I was on the gemba recently in an IT department and had exactly that discussion with the agile manager. They don’t want to hear about the lean approach of the company because they find it too rigid – they don’t think that in their complex, fast-moving environment, standards and standard processes apply to them – and I don’t necessarily disagree with them.
On the other hand, they conceded they have long lead times, a huge backlog, and lots of rework although they’ve been practicing agile for years, which essentially means that:
- They define work through stories: they scope functionalities with user “personas,” specifying what that “user” would like to do to get that and break it down into chunks of work – epic stories and stories – to code.
- They work in small batches: they deliver work once a day or once every two weeks and try to test the code before delivery.
- They work as teams: every morning they have a stand-up meeting to discuss the work to be done and the problems they encounter.
And it works! They deliver.
What would lean bring to them?
Different Starting Points
The hard part. Agile is a hands-down win compared to planning an entire system and having months of code chunked to deliver and made to work together in the end. But it remains a system that organizes the team and stops at the individual coder and thus – the code. There are a lot of techniques in agile to look into code quality, but so far, I have never seen them applied that well.
At the other end of the spectrum, customers of agile teams are much happier because they see continuous delivery of features, but it is unclear the resulting product is better liked or more used that with the traditional waterfall method.
One key issue with agile thinking is that – from what I’ve seen – it is very features based. The resulting software tends to be loaded with features, none of them very useful that do not necessarily perform very well for users on the few key functionalities they really need, on deeper issues such as speed, bugs and glitches, and data security.
Lean starts at a different point – not with the team, but with the developer and the product owner or architect (in lean terms, the chief engineer).
With agile, the team looks at the ticket board, takes one from the backlog of stories and pushes it into the “to do”, “in progress”, “in review”, “done”, queues – many variations on these headers, but they mostly do the same.
When you look at the board, some tickets move forward, some linger. The team reschedules the tickets according to what has been achieved and what has hit a roadblock. Most of the time, the manager is the tie-breakers and makes the final call on what needs to do what and what will be rescheduled.
Lean starts with the developer. The flow of tickets should be at the work station: here’s what you need to work on next, and then next, and then that’s it – like a cook in a kitchen receiving orders from the tables in the restaurant.
The point of bringing the ticket queue to the workstation is to make the person autonomous: they don’t need a team or a boss to know what to do. They can work on their own AND call for help if they hit a snag.
The reason work accumulates on people’s desks is that when they hit a difficulty, they put the troublesome job aside and then start something else – which makes sense. If they hit a second issue, they put a second job aside and so on. We all do it. Some difficulties resolve themselves easily – getting a piece of missing information from someone. Others will linger and fester because they’re the hidden part of the iceberg of deeper problems.
Building in Quality
Lean doesn’t work without andon – the line management is there to be a chain of help. When someone hits a problem, rather than put it aside and work on something else, management shows up and solves the problem, rather than move on to another task. This is never easy but this is how we uncover real problems early on, and crack them.
This simple-but-hard thing is the key to built-in quality: in the end, the product will be much more robust than if we continue work, push all problems down the path and hope that at integration we can somehow solve them all together – see what happens when managers try that with airplane design. Ouch.
And here we come to a major misunderstanding about lean. Andon is not just about helping the developer and training them to do stuff when we can. Andon is about understanding why the developer is having the problem in the first place and where did we go wrong in the work instruction.
The other side of the equation is the architect (in agile terms, chief engineer in lean), the person who keeps a global vision of:
Benefits to customers: features — technologies — integration in the entire system — total cost.
Someone has to design the work. In lean, engineering designs the work in great detail and then uses production problems to refine this design. In Agile, work is designed with a wider brushstroke and the developers find a way to make it work.
In lean thinking, we focus on being careful about what new features we bring to market, and making sure they don’t detract from the overall performance of the product and that they are solidly designed with standards so that production teams know what to do. Innovative features or use of innovative tech is used frugally, in intensely watched projects.
Agile development tends to be much loser with producing code that does the job, and the architects tend to see progress in terms of adding features to satisfy more user needs (caveat – wide generalization here, no two architects have the same point of view on this). This is a fundamental difference that explains much of the agile/lean discussions.
In lean, the feedback mechanism to design is not from the user’s reaction to the complete product once it’s being piloted out there, but from the very process of stop-and-fix (if the designers are actually interested).
In lean, production itself is the test method of design.
The kaizen workshops and sessions are really interesting in lean when we surface deep design issues which can then be explained to engineers. The explanations will only be useful if the designer has a deep understanding of customer benefits, features and the tech needed to deliver them with quality and ease, at reasonable cost. Not easy.
Ultimately, lean techniques are about helping people to see beyond the borders of their functional jobs – the aim is better collaboration through the chain and taking out the costs – waste – of gaps in cooperation (nothing more wasteful than a product users don’t use).
Unfortunately, many lean programs are exclusively focused on making each team more productive and completely miss the bigger picture of “sell one, make one – to make sure you keep selling one.”
To answer your question, it really depends on what kind of lean program you’ve been running. If the focus has been standardized work and standard processes, as some I know are trying to do, agile will be a step up. It will relax the atmosphere and stop you from forcing customers and staff in your arbitrary processes. On the other hand, if you’ve been using lean kanban techniques to establish a closer information flow between designers and developers, then agile will probably be a step back, allowing middle managers to re-take control of who-does-what and no longer look into developers’ code.
The key questions here are: What are you trying to do? Where do you look for gains? What kind of lean do you currently practice? What kind of agile does your new boss want you to do? No advice: It depends!
