Jan 30
Lean and Agile, real friends and faux-amis
It is a frequently stated fact that Lean and Agile drink from the same source, and a lot has been written about it - around560 000 videos touch this topic, and Google trends show a slow but steady increase in searches combining them through the years. So I am clearly not going to break ground today, but it feels like there is still room for some storytelling which, hopefully, might speak to some of you.
First, how are Lean and Agile related? There are quite a few angles to this question, and I think this article makes a pretty good job listing some of them. But at the end of the day I think it can fit in one sentence: they both are about obsessively directing people’s focus to what brings value in the product that they are working on.
I would happily welcome any divergent opinions on this, and discuss them another time, but for now, it is time to keep this promise about storytelling. So, let me sit in my most comfortable armchair, grab a St.-Germain Spritz, and here we go.
The year is 2015. I am attending my company’s global Lean conference as a local Lean leader for the first time. Besides a sense of accomplishment and a remarkable level of social anxiety, what I remember the most from this day is an intervention from the Agile Center of Expertise. What is Agile? And why should I care, as a Lean practitioner, to push an insurance company administrative back-office towards continuous improvement?
Here enters the Kapla blocks.
First, the facilitators grouped us into teams. Then they made us build bridges made of small wooden sticks, with a complex-ish system of score keeping: we would win points depending on the bridge’s height, length, and frugality in resources. But we were given one last incentive: we were to forecast our target for each attempt, and the difference between our forecast and our result would be deducted from our score. We had three attempts. We were asked to debrief in between each attempt, and also to look for ways to do a bit better the next time. Of course, we did do better. And, more importantly, we did, and the ratio between the time spent talking about it vs. the time spent doing it was refreshingly low. Also, it was fun, but who’s to say it was not mainly thanks to the kapla.
I experimented with Agile principles and Scrum framework with my team as soon as I could on problems we would have otherwise tackled using DMAIC (Define, Measure, Analyze, Improve, Control. Read: Lean 6 Sigma jargon for waterfall methodology).
And it worked.
Our first project was far from perfect in any regard, but we had gathered a full team basically designing its own activity from scratch, going from zero to managing its first file in 4 weeks, and to full speed in 4 months. A major risk was now mitigated for the company, team members had the feeling that they had lived an adventure like never before. I knew that I wanted more of it, and so did everyone involved.
So, it sounds like transitioning from Lean to Agile is a pretty smooth experience, huh?
I was in for a bitter disappointment.
Aretha Franklin (if you were wondering: I changed their name) was one of my most promising Lean project managers. They were focused, and were still open to other ideas, such as design thinking, lean start-up, and so on. So when we had to start a new project that seemed perfect for Agile — re-designing the customer’s experience in a key back-office department, with many unknowns despite strong focus group conclusions— I asked them to become the scrum-master of the project.
A team was gathered, a customer journey vision was shared, and voilà. I was expecting the first outbound call within a couple of weeks, and a learning, growing, thriving team.
But going live, even at small scale, with an incomplete solution, seemed too much for everyone, especially for the scrum-master. 4 months and multiple discussions on what it means to “be ready” later, the project was still stuck in this infamous sprint 0, and all we had to show for it was a half-designed solution, no customers reached at all, a high level of pressure and a general feeling of crisis.
The project seemed deemed to fail. And it was quite tough on Aretha, who was used to success, and depressed by the state of things. So I made a deal with them: if the project was not going to reach its target, we should at least turn it into a learning opportunity. And, this time, launch small, quick, easy-to-understand, customer-oriented experiments but for real.
And so they did.
What happened next? The first customer was called in a fortnight. The Net Promoter Score for the customers who were part of the experiments went up 50 points (which is big, as these things go). And most of the solutions that had been designed for the previous 4 months went into the bin.
Why had it been that difficult? What was so different from our previous way of doing things? “Something something mindset, something something culture, something something fear”.
Ok.
But, what was it in the mindset? What specifically about the culture?
It took me some time to put words on it. And a few conversations that went roughly like this:
“…and this, my friends, is a Minimum Viable Product. — Ha, what a fancy way to say proof of concept.-no, it is not a proof of concept. -so, it is a pilot?-no, it is not a pilot.-Hm. What’s a difference?” (here, insert a long silence).
I started being better able to formulate it very recently, when introducing Objectives and Key Results to a colleague. “Ha, what a fancy way to say KPI.- no, it is not a KPI. — What is the difference?”
That had me thinking. I really wanted to make it clear, because I was trusting this colleague with the product I had worked on for 3 years, and OKR had been a formidable tool to alleviate the pressure on the team while focusing all the stakeholders on our main objectives, and, somehow, it felt like KPI wouldn’t do the trick. What is the difference between OKR and KPI? What is the difference between a pilot and a MVP? And why does it matter?
It is the difference between learning and checking.
It is the difference between learning by doing and learning, and then doing.
It is the difference between showing the way to the team, and trusting it to go as far as it can, and setting unreachable targets, hoping to push people further.
