Mattias Skarin
Transcript
Welcome everyone.
Let's take a seat and let's kick off this show. Let's get it on the road.
Please, welcome. Take a seat up front. Don't be shy. I won't bite. At least not yet. Really? No.
Okay, let's get started. My name is Mattias. I'm a crisp guy. I work in Stockholm. And I'm very passionate about finding better ways to do product development. And a couple of ways I've stumbled upon, of course, Kanban. And I've applied Kanban in many different cases, situations. So I thought, let's share some of the insights with you. And very recently I released a book, the one on the right hand side from my perspective. And I won't talk about the details of each case which you will find in the book. What I will do is I will talk to you about some of the things that happened across these cases. That you might find interesting.
Things like, okay, so what happened next? Okay.
So, I did a small experiment before I came into the room. I created a conference Kanban. And I actually created some tickets there. So we get new attendees coming in, they sit down, they listen carefully, really, really carefully. Then they pick up the phone, oh no, I checked my email, ask a question, stand up and leave. But what? This doesn't program you? What? No one went up and left when I moved the ticket on the board? What? Why?
Well, an obvious reason could be that I created this and you didn't.
This has no meaning to you.
So that's an important insight.
If it doesn't mean anything to you to have a visual board or the stuff that's on the board, you probably are not going to pay a lot of attention. That's an important insight. So the first thing you need to do as a coach who implements Kanban is to actually validate that the stuff that you put in means something for the people that work there.
Company is a good way to build shared behavior. So you can create shared behaviors in a team, you can create it across a value chain, across departments. What it does is as people interact, they start building trust with each other. And they get a sense of adherence. This is what we do together. We act in this way. And that builds trust. And this trust is your leverage to do improvements. So the first question you're going to run into is, of course, like, why the heck am I going to start putting post-its on a wall and move them across? And if you ignore that question, then most likely what people will do is they will ignore your board. It has happened to me. I'll give you that. But what if it could mean that we could act as a unit instead of individuals? Would that mean something to you? Yeah. Actually, that makes a lot of sense. So, I will introduce to you Skarin's Law. It's not... Often you get the chance to introduce a new law, so I decided to take my chance. So here it is. It says, the number of improvement initiatives you will see in a common system is directly proportional to the trust the members have in that system's purpose.
So if there's no trust in what you're doing and believe that that is value adding for the people that work in that system, they probably aren't just going to ignore it. And you'll see things like a wall where nothing is moving. Things like that. So I'm going to share some insights across four different case studies. Kanban outside IT, Kanban using across different market units and across a company, in change management, and a final story, what happens when you run Kanban and you burn up and fail.
What can we learn from that? There are lessons we can learn. So I thought I'd share some of the insights across these cases. And I won't go into details in each case. What I will talk about is how did we introduce Kanban? What was the tipping point? Where did it move from being something alien to something we like and care about?
What happened next? That's the kind of things I will walk through. So let's start with the first case, Kanban outside IT. And to give a little perspective, so this is a back office department at a bank. So these guys don't build software, they don't even manage software, they manage services, pension, payments, reimbursements, things like that. So the way Kaman got introduced was one of the managers of this team, a team of roughly 20 people,
saw Kanban at the ops department and she said, well, what would happen if we would use that? She had been looking into Lean in IT and some other practices, but this felt more like her thing. So she asked me to come along and figure out how to introduce Kanban. And what we did was we invited the team, we did a half-day training on the principles behind Kanban, not the board, sort of like, okay, what's the benefit we're trying to get? We did a retrospective, like, okay, so what are your challenges? And then we drew a Kanban board together, and then we asked the members basically to give a sense of vote of if they felt that this would be helpful. And we ask them to actually do a thumb vote. What would this be helpful for? Yes, absolutely. Well, maybe, but I'm willing to try. No. We got the thumbs up. Okay, so we said, let's do it. Now, a little bit of perspective.
This is not your ordinary team.
They are self-going from day one. Actually, they were even before I met them. If you come to them with a problem, they will solve it before you exit the room. And I'm not talking about the managers, I'm not talking about every single member in this team. So you just gotta start wondering What the heck do you need Kanban for? You are self-organizing, you are self-going.
What are you going to use it for? And I had this question in my mind. I discussed it with the manager, but we said, okay, we don't really understand, but let's try first before we stop this experiment. So we gave them some leeway and we got started. Now, the first thing we did was get the board up. And in this moment, they actually created a really neat board. They had a lot of interaction. The team met in front of the board every week, every day. The manager came every Wednesday and asked what are the problems we need to solve and went on and just crashed that problem.
Of course, things that they invented is elks are great whip limits.
One really cool... thing that this team did was they introduced a totally new way to go about and do improvements.
And I call it Fika-driven improvements. And Fika in Swedish is a name for having a coffee and a chat.
So this team, to give you a sense, they are not the top of the hierarchy and the strategic importance of this company.
So whenever they have a problem, okay, this software I'm working with sucks, or someone else keeps bashing me, or why don't people do as I think they should be doing, should be behaving?
They don't go up to top management and ask others to behave in a certain direction. They have to find other ways to get help. And one of the really neat things they did was when the managers saw they wanted help from the other team, like a front-end team, They will start by just having coffee with the members of that team for like three or four weeks, getting to know them, and after they did that, they ask, okay, what type of problems do we see together that we need to resolve? And once they've done that, they went and resolved it. And these guys did some amazing things. They got other teams around the company to do the things they wanted. And they even got a software team who never had time for them because they were just doing... So getting things to the backlog of the software team meant doing... small, big important things. They were asking for small changes like, okay, how can we just simplify entering this information so it doesn't consume a lot of time?
They got one member from the software team to sit beside them for one day and actually hacking in the changes at the same time as they were working in that system. So really, really cool ways which they actually went and improved things.
What was the tipping point? Well, two things, right? They cared a lot about seeing the full picture of what they were working on.
And they also cared about making sure that important things, some legislation bound, actually did not get lost somewhere. So if they had a ticket and someone would accidentally be sick, what Kanban helped them to do was for everyone in the team to see that and engage and actually solve that problem. So when they noticed that, that's when they said, actually, this is a really helpful tool for us.
One important learning we did was, if you ask them if they use Kaman today, they would say, well, yes, sometimes. And they do this in times of very high stress. There are times of the year where they suddenly have a lot of work and a lot of time pressure, and other times of the year where things are fairly smooth. And what they do is that they apply Kanban during this time. where they have a lot of stress.
We did measure flow, right? So we looked at what's the number of tickets that flow for the board, we collected metrics, but that was more like learning if we were focusing on the right things. It was not the primary tool to drive improvement.
The real improvement pace in this scenario was so high that the charts couldn't keep up. And looking at the charts was like looking at all things. So what we had to do was simply observe where are problems, and then when we agreed on that that was a problem, then go and attack it.
So first case. Now a little challenge for you when I walk through these cases is to think about what are the patterns that goes across these cases.
Case number two, Enterprise Kamba. A little bit of background again.
So this is a company, roughly 500 people, divided into two different departments. One marketing department with three distinct marketing units, value flows. An IT department with multiple teams, like five, six teams into development, and then change management and operations. A couple more details that's important to understand is they had different opinions about what the state of things was. If you walk to the marketing department, they will say, well, you know, they do agile and they've been doing it for three, five years. We don't see shit.
Development would complain, actually, there's really heavy processes around us. That's what stops us from doing things. And if you want to ops, they would have a completely different opinion. They would say, we are overworked and please just stop. Pushing so many late changes, right? You can't go and change a day before a release because we have to redo all our integration testing.
Right, so very different opinions about what to fix.
This is a very traditional company, so this is not your next Spotify. And this is one of the reasons I find it really interesting to work with them, to learn. So how can a traditional company that does have a lot of legacy improve? What happens if you don't have the next superhero people in your department? What do you do then?
They are responsible for big parts of the country's infrastructure.
Now imagine what that means. If things break, they don't redeploy the web server.
This put a lot of attention to quality, right? And one of the reasons why you see this build up in many very distinct processes.
They also, a little complexity note, they have roughly 600 systems which they maintain in a single moment. So it's not just about the teams doing development right now. It's a lot about the other systems they also need to manage. So that gives you a little bit of perspective.
How did we get started? The first thing that happened was I got pulled into a meeting with a manager in the marketing. And she drew up a picture, and we together drew up a picture on a whiteboard. Rake, they don't redeploy the web server.
This put a lot of attention to quality, right? And one of the reasons why you see this build up in many very distinct processes.
They also, a little complexity note, they have roughly 600 systems which they maintain in a single moment. So it's not just about the teams doing development right now. It's a lot about the other systems they also need to manage. So that gives you a little bit of perspective.
How did we get started? The first thing that happened was I got pulled into a meeting with a manager in the marketing. And she drew up a picture, and we together drew up a picture on a whiteboard. So we asked, so what happens when an idea goes from start to into a development team? Tell me the journey. And we saw a lot of different agents being involved in this process. And the road for these ideas was not very clear. We actually agreed that we didn't have an idea of how this really happened.
Now, what we didn't do is take this picture, walk out to the development department and say, we have an idea of how to fix this. We'll just scrap these agents, have a one-to-one relation with each development team, and then get started. No, we didn't do it that way. We thought this might be a clue. But it's probably not the only part of this problem. So what we did was
We interviewed a couple different people across this value chain during one day, asking them, okay, so what are the challenges that you see?
Based on that, I suggested a number of experiments to do. One was trial of Kanban, but there were four or five others.
We walked them through in a room where every single team was was there. So we said, here is what we see, here's the stuff we'd like to try. Then we asked the members in that room to basically do a thumb vote again. Would you be ready to try this experiment?
And four out of five got a yes, and the fifth got a no. I don't see the value in doing that. So we said, okay, let's drop that for now. And if this problem keeps coming up, then maybe we'll pick up this experiment. And here's the first tipping point.
That we did listen to the people that worked there, and if they have a really good concrete idea why this was pretty useless, we said, okay, let's skip it for now. We didn't push it on them.
So we got started. We got a Kanban board up and running. And we got some interaction going on across different marketing departments, development departments, op departments, etc. The first thing that we observed is, okay, so these guys are working agile, they're using Scrum. We ask a simple question. Where's my product idea? And it turns out that was really hard to answer. So this is Scrum Master, one of the development teams, going through her Scrum backlog, trying to think of what product ideas she needs to put on a Kanban board. And that was a non-trivial exercise for everyone involved, but we finally got that up.
What was the tipping point? Well, one of the experiments that we suggested was stop doing sprints and move to continuous flow. So this meant for the development teams to abandon a practice and a habit they've got used for for many years. But they accepted that, said, okay, let's give it a try. Now the first important tipping point was in a situation after roughly one month, then two of the developer teams said, you know, we want to do this, but we are constrained by a couple of big blockers.
And what we did was we said, okay, We won't push new things into this flow unless we have resolved your blockers. So we created a space on top of the board saying, here's blockers. And we said, as long as these blockers are red, we are going to hold back new product ideas.
That was a really important message that we gave them. That, okay, this wasn't about creating a Kanban board, this was about improving things. And the company was willing to take pretty high risks for the well-being of the people that worked there. This was not just words. This was tough choices that they were making. And we were making them in the situations where we saw the problem, right there and then.
How did we do improvements? Well, we tried a very simple approach. We got managers and scrum masters to once a month look at a chart and the board, just half an hour every month, and figuring out, okay, so what is the end-to-end lead time for things?
And based on that, they have to suggest problems, ways to solve problems, and the new experiments.
Then after one month we analyzed this experiment and asked ourselves, okay, do this actually help us or not? A couple of things that we noticed was early on, it was very coarse grain to look at the full lead time from start to finish. We need to break this down to smaller chunks to get an idea of what consumes the most of the time.
The other thing that we also observed that what the heck? I mean, okay, we can be as fast as any, but if we don't build things that people like, who's gonna care? So we added a section to the end of the Kanban board where if we put the product idea after it's been deployed, We ask for feedback from the marketing departments and the people using the product. So is this okay? Is this cool? Or does this suck? And it will give us very blunt feedback. And based on that, We put the ticket on the top. Was it popular? On the bottom. And if it was on the bottom, then we collected a number of people involved in developing that product and did a root cause analysis together.
Now a couple of things that are interesting from this case is this.
We did estimations, really simple estimations on the product ideas early on. So we estimated a small, medium, large. So small being yellow, medium being green, large being blue. And then we correlated this to the real outcome. So, okay, how long time did it take to actually deliver this?
So what do you observe?
So you said it's a pretty straight line. Okay. Anything else you observe that's...
No correlation between those ties.
So no correlation between those ties. That's very interesting, right? And we observed that as well. Actually, it seems like it doesn't really make sense. The initial estimate that we do has very little correlation to how long time it takes to actually release something. So there are other agents at play other than estimation the size that actually are more correlated with lead time than the initial estimation. So here I suggest an experiment. So I said, okay, let's just scrap estimations. I have one category. Let's call it like 80 days or 80 days totally off, like three, four months.
They didn't accept this experiment though.
They said, no, let's keep doing small, medium, large. Okay, so I said, no big cost doing that, so let's keep on doing that. But here's a situation where we could have learned from our outcome, but really didn't.
But what this led to was a lot of questions about, okay, so what are these other factors? And that's when we started to problem solve and analyze.
So where are they today? Actually, they don't run Enterprise Kanban across the same teams anymore. What they have done is actually people from the IT department have physically moved and are now sitting inside the business development teams.
Now they may run Kanban, it's sometimes since I visit them, and I think they do in some cases, but they don't do it in the same way as we did when we started. Why?
Well, because I think they have other problems now. Kanban was really useful in growing their maturity, it was really helpful in ensuring conversations across the value chain happened, but when we resolved the biggest blockers, we needed to find other ways to work, and they've done that.
So some of the learnings. So Anticrust Kanban was really critical to open the door for conversation across its departments. And some hard.
Focusing systematically on just improving end-to-end lead time worked.
These guys did a trick. They just resolved one problem after another until they can deploy in a couple of days.
Now the hardest part involved shifting old habits. So I will give you a story. One of the things that we struggled with was getting acceptance that a development team could deploy things into staging and production. That was a sensitive topic and we had to talk with a lot of different stakeholders to try to get acceptance for this experiment. Now it actually came to a point in a meeting where we had discussed things so long and we asked, what are the, are there any
other comments to why we shouldn't do this, and that room was silent. And one of the developers actually said, okay, then tomorrow I will do it.
And no one objected. But no one said yes either. So after a time, it comes a point where you need to jump.
You have an existing practice, you have an example of something better, I talk to people, but then at some point, You need to go do it. Can't stay on the safe side all the time.
So these guys improved with a factor of two within roughly one year. So they now have twice the speed. I think actually they have more. But just to give you a sense of how fast things actually work today.
Let's talk about this case. So this is Kanban in change management. And again, a little bit of background. So this team actually works inside, into the enterprise Kanban value stream.
And the way that it got started was the managers observed what happens with one of the development teams that they were using Kanban, and they were asking, okay, would this be helpful for us? And they went and attended a course, a Kanban course, and on the train home, they started to sketch their own Kanban board.
And they said, how are we going to introduce this to the development team that we have? So I got pulled in, and on the first session, we actually did a retrospective. We asked, so what are your challenges? Just tell me, what do you struggle with? And we made sure that we got them visible on the board, and then we dot voted. So which challenge should we start with? Turns out this too.
We have lack of time, we have lack of tests. That's what we need to fix. So we proposed the experiment and asked them, alright, lack of time, we think Kama can help out in that. Would you be willing to try it?
And we asked for a thumb vote. And they said, all right, I'll be willing to try it for two months. So we said, okay, let's go. Let's start from there. That's where we got the common board up and running.
How did we improve? Well, one important aspect of this was the managers were really motivated to help out this team. And they did a lot of upfront work to make sure the team got a good situation to work in. They made some hard presentations, they got visualization up and running, they were engaging improvements, etc. And here's one of the managers who's observing the charts that she has outside the Kanban system. But actually, there were a couple of steps.
First thing we did, we're just focusing on freeing up time. For two months, it's just freeing up time. Make sure we get some slack into the system. That's all we did. Limit WIP, remove non-value adding work, say no to parallel projects, just get that out of the system.
The next thing we did is that we focused on building behaviors shared by the team and their managers. So we focused on making sure that we worked as a unit and we trained that unit to actually problem solve. We kept on doing that for some time.
And then, when they felt this is working, and you can see they were starting yelling to other cities, come and look at what we're doing, this is really cool. Then we started pulling in other functions, and they were looking at, oh, why can't we do things like that? And they started their own experiments.
Now the final step. And also one of the more difficult was from this point we had reached a local optima.
From this point, we actually needed this team to spend less time together and more time with upstream teams. So here is a challenge, right? We build this really strong unit. It has a really core sense of itself. And now we're asking it to be a little less strong. So that was a mental challenge, a leap, so to speak, that we had to discuss for quite some time before they were willing to make.
But one of the things that we did recognize was we did not need to change the organization in order to improve flow. We didn't break up this team. We kept it as it was. We just asked them to change how did it work, to spend more time out with the other agents around them that needed their help and expertise. Here is a challenge, right? We build this really strong unit. It has a really core sense of itself. And now we're asking it to be a little less strong. So that was a mental challenge, a leap, so to speak, that we had to discuss for quite some time before they were willing to make.
But one of the things that we did recognize was we did not need to change the organization in order to improve flow. We didn't break up this team. We kept it as it was. We just asked them to change how did it work, to spend more time out with the other agents around them that needed their help and expertise. And we got that in place instead. So some learnings. Active leadership through all steps were critical. And I can very clearly see that the step that were hard was when the leaders were struggling mentally if they were willing to make the leap or not.
Getting visualization was key.
And you don't need to change the organization in order to improve output. You might come to that point in some situations, but there are many things that you can try before you need to come to this situation. And I think this proves this. At least the data and the output that we got shows us this worked.
So now let's look at a case that didn't go as smooth. Let's see what we did differently.
So a little bit of background. Here's a platform company, it's an open source company, building software which is used and supported by companies around the world. So they have teams, development teams, they're using Agile, and they're really happy with it. So I had been working with these teams to help them get the practices in place, and yeah, they were working pretty fine. Now, in the middle of all these teams, and actually in the same physical room, is a team of very senior developers that have been there for many years, actually since the company started.
And they are working, well, at least they are sitting together. They are pretty single, so they are not used to work in a team environment. You can see that they're very strong individuals, right? Yet they are humble enough so that they can talk about things. So one thing that you could observe if you walked into this room is you could see a team saying, well, actually, you know, when I want help from like difficult stuff, it takes forever. And if I were going to ask the same question to the architectural guys, they wouldn't reflect that situation. They would say other things.
Yet they sit in the same room. Isn't that bizarre?
So how did we get started? Well, in the same way, we did a team retrospective. We asked them to come up with the challenges that they wanted to pursue. And the top challenge was, we want to work as a team. All right, let's do that. So here comes the Eagle coach, and he suggests an experiment. Let's do Kama. Because that has worked in all the other teams I've been working with. So I said, let's do it.
So I got a visual board in place. I got an agreement, I thought, to do a stand-up every single day. Now, one thing that we observed is one or two of these members in the architectural team, they wouldn't show up at the stand-up. Or if they would show up, they would show up half an hour late, 50 minutes late, and things like that. Some of the members did. Some of them actually agreed on and kept doing what we had agreed on.
So I introduced the concept of, okay, so if someone is late, let's make sure that that person, if it's late five times, buys a beer for everyone in the team. So we can have a team. Think that worked?
No, absolutely did not work. So nothing happened and I started observing that the things they had on the command board, they weren't moving. They were just hogging there on the board. So I started pushing them a bit more and I said, okay, so you know, we don't need to do this for my sake. I did a retrospective after one week with the guys in the room and said, we don't need to do this, right? You tell me what you want to do. It's not up to me. If you still want to pursue this, let's do it. If you want to scrap it, I'm fine with it. Yes, we want to do it. We want to do it. Okay, so we kept on doing it. Now, other things that you will notice was that the behaviors that these guys showed did not correlate with what they said they were going to do.
There were situations as we started a stand-up, a scrum scrums with all team members, and the senior developer would come into the room, instead of standing as everyone else was doing, he was just sitting down.
Okay, what I need to talk about now.
So things like that, that was treated.
So after we had that very honest talk with each other, the team and I, we decided, okay, let's do a root cause analysis together. So we got everyone in front of the board. We did a root cause of the situation. We do not work as a team. Why? Okay, so this is a little bit messy, but here's one thing I learned quite some time after this case.
There's actually one guy that's openly admitting, I don't really have a clue what working as a team means.
I didn't see that. So I said, okay, let's continue on doing Kamba.
Hell no, right? We're going to work as a team, right? We have to push this and create the team charter, get everyone to sign that, and well, guess what?
Crashed and burned. Came to the point where I realized this does not work and my trust has now been depleted, so I shouldn't push anything in this environment anymore. I've tried my way, it's time for someone else to kick in and take responsibility to evolve this team. If that's the team themselves, it's the CEO, I really care, they should try to find some other change agent. So here comes the important question. Why didn't this work? And there are a couple of factors, some that can be attributed to the team members, of course, and some that can be attributed to me. And I'm going to share the things I learned based on this.
How could I have approached things? Well, based on this root cause analysis, there were actually important information that I discarded.
For example, working as a team had multiple different causes, reasons that we could resolve. We could have this team focusing on smaller scope. We could have this team doing things smarter about automating stuff. But I chose to pursue the tri-curriculum thing. Without listening in on the other different approaches.
So if you are in a situation like this, if you are open to other solutions to your problems during the problem analysis phase, you are likely to get a lot more buy-in
and real commitment on the change experiment that you are proposing.
So this I'm doing differently now. So I'm always open to see what other ways could I go about doing this and not just having the one I have in my head and pushing that from day one.
So the morale of the story, right? I could have pursued other root causes. And I had some signals I could have changed. I didn't.
I did not raise the behavior issues in a one-on-one format. I could have taken a couple of people aside and just talked to them in one-on-one. I chose to raise this with a team at once. It didn't really work out.
And final reason is if a team is under very heavy stress, they are not very likely receptive to ideas, doesn't really matter what type of ideas that you come along with.
So if you find someone in this situation, find ways to decrease this stress before you start suggesting experiments to pursue.
Now, if you see a behavior which you don't like and you see contradictory to good practice, and you want to share this, so make sure that you are the mirror and not the judge. So the situation could be, I see, put forward the problem and just be blunt about it, but not necessarily put in value statements. So I see that you are sitting down during our daily stand-ups. That's being blunt. What's your opinion about it? Instead of saying, I see that you sit down during a daily stand-up, and I think that sucks. Now you put a value statement into that observation. So you can be blunt about it, but you don't necessarily need to put your opinion about why or how good or how bad this is.
So let's sum up a couple of things.
Right? First questions.
This is a question to you. What patterns did you see?
Where are you observing? Right. Let's listen to this guy.
Trust in death? Trust people in death?
Yes, so trust them. In all this experiment at work, we trusted the people to get us feedback on the experiments that we put forward. And we didn't pursue the ones that they said, no, this seems useless. Any other?
We should listen to people.
We should listen to people, right? Very important.
So a couple of things I learned across these cases I'd like to share with you.
If you treat people as thinking beings,
they will treat you in a similar manner. And this is really key when you come in as a change agent, because that's the first test that you are going to be exposed to. Are you pursuing this other mean than mine? If you don't pass that test, they're not likely going to listen to your ideas.
So, applying a tool like Kanban, the goal, is problematic. Because now you are stuck with thinking, that's what we're going to do, I'm going to move posts on the board. No, most likely what you need to do is listen,
Discuss options. What other ways can we go about this? And then solve problems together.
The second learning, it was really key to get a movement to time system level improvements with the team's maturity evolvement. So let's assume a team did some really good things and they felt they were on the right path. Now for us that worked across the teams, it was really critical to make sure that when the team came to this situation, we could give them trust that we would work and solve things outside the team's borders, so that they would continue feeling that this is going the right way.
So the tripwire here is if you are not pursuing systematic improvements on a system level, you're going to find yourself walking into a situation where things will stop.
So the behavior that we are looking for is to involve management in improving end-to-end flow. A real simple way to make sure that we can time the things and improve beyond the tool.
Third thing, if the experiment is big, if it's scary, suggest a small one.
But do something. So the behavior or the habit that you need to train yourself and your surrounding with is Always do something. If you want to, it's a big leap, do a small thing, but do it today. That creates a spirit that we always move forward and that's what makes initiatives happen.
So, there's a really simple improvement algorithm that you can apply.
You can ask yourself, what consumes end-to-end lead time?
And then let's make that a little bit easier. And you repeat this in a hundred or so cycles. And guess what?
You are going to be a Formula One car.
It is that simple.
Now, of course, this algorithm is simple. The choices and the problem solving can be hard.
And I'll share some of the things that you need to be aware of. Now, as you move across different maturity stages, you will see that some tools are very useful at some stages and others less. So in the beginning, before we had any process put together, Waterfall was excellent. It created order out of chaos. Then we found out, no, it sucks. We found a better way.
And then we could see, well, actually, we could work with Kanban.
Oh, actually we can use a digital Kanban tool, no need to move post-its and all that overhead. And there are more steps. So when you do these improvements, when you take a team or organization through improving their capability, you are left with a puzzle.
Are you going to stick with the existing approaches that you tried so far?
Or are you going to be open to other approaches which you never tried, but other people suggest to you?
And guess which one that you need to... apply to improve for a long time. You need to be open to other means, which means which you haven't seen before, before you stumble upon them.
So how do you see them? How do you see the things that are obvious for others, but not obvious for you?
Well, there is a clue here.
Give up the copy-pasting technique. That's useful in some situations, but not all. And then instead, make it your goal to make it easier to deliver value. Every single problem I showed you across these cases would have gotten up on the radar by just asking that question.
So, that's my summing up. If you want to read more about the cases, go grab the book. If you want to ask questions, I'm here. And I advise you to go and do some experiments.
Thank you.