This is the third post in a short series on how Morgan and me went about to introduce Kanban and some Lean thinking to two support teams of the Avega Group office. You can read post 1 and post 2 before this to get the complete picture.
With this post I wanted to do some reflections on how the introduction of Kanban took hold for the teams and also what Morgan and me learned in the process. We are used to do this for IT-projects and teams working with system development or maintenance.
Reflection on the result for the teams
First week
The immediate and positive responses from the group was reactions like:
- “This is very clear and shows us what we are doing”
- “I can see dependencies between our tasks. And on the ones where we wait for others”
- “We have greater understanding for what we do. And other can see that (what we do) also”
- “I think our effectiveness went up 25 %”
This is all related to visualization and the simple act of putting stuff on the wall (or the board) if you ask me. It’s also very common for teams starting with agile practices to get this kind of boost just by showing what they are doing.
There was also also a buzz around these new different rituals ( morning meeting, moving cards, creating avatars) that made the first week a true revelation for the teams.
One of the more interesting signs of that was that they spontaneously started to evolve the board:
- Both teams used different colored stickies to further communicate
information.
- One team used a color for each big project they were in. The question was what that helped them with. It was easy to see if one project was taking over the board but did it help them to prioritize? Not so much probably
- The other team used a more common Classes of Service concept grouping their tasks in Urgent, Normal and Low priorities
- One team considered adding a new “To Do”-column for stuff that goes on during the year. So they could prioritize the week from that backlog.
Also it was great to see them starting to collect statistics for what had been completed each day. One team left that on the board to “feel good about themselves” and then put it into a binder for later processing. We have suggested a simple SPC diagram for starters to track progress and deviations.
Second week
The second week the focus has not been great. We tried to urge both teams to do a retrospective on how to improve their process and work but that was down-prioritized. To which Morgan said (love this): “If you gained 25% effectiveness – why not re-invest 5% of that time in improving your further work”
As it seems the week has been very busy and people have been in and out of the office. This has led to skipping of morning meetings and not updating the board, tasks not on the board.
Me and Morgan have to take some of this responsibility on us. We gave them very few instructions and tools and just told them to get going. And they did. But without guidance and continuous coaching to get them further the first inspiration seems to fade quickly.
I think this is also very common – a lot of teams “pick up agile” and just get starting but soon run into problems or don’t know how to go further. That’s the whole idea of a coach. Using the Shu-Ha-Ri thinking they early on need constant guidance and firm advice to follow the rules strictly. So we left them on their own a bit to much maybe. We have promised to ask them if we may coach them on a more daily basis.
Coaches reflection
So that’s how our teams have coped. But what (if anything) did Morgan and I get out of this?
First and foremost we had to up our game. We are used to talk to teams in the IT-business. Many of the have heard of agile or even Scrum and Kanban. We know the common problems and pitfalls – so we are ahead before we start.
But here … we had to go in with a humbleness and use a different language. And, very important, we had to understand what the problem really was. This is a very common mistake that I fall into from time to time – just coming with solution to problems that don’t exist.
So we couldn’t use buzzwords that everyone would smile and nod to. We couldn’t use explanations like Littles Law and “WIP is bad” but rather had to argument using other words. Really hard, but also very good for our own understanding.
We cannot emphasize the use of simple exercises enough (see the first post). That made a lot of difference and gave us a common platform to refer back to. We also introduced the exercises in terms of their business (Imagine 3 projects, one is this important one, the other one …).
We tried that particular exercise on an other colleague that just stop in her tracks and said: “Point taken!” She just GOT IT. Those are the exercises you want to use.
With great powers comes great responsibilities
Something that Morgan and I have discussed is that we left our teams hanging a bit. We gave them tools and told them that “this is a simple process that you can apply to whatever way your are working today”. But without proper coaching and a helpful hand it quickly degenerates.
I think that this is what has happened to Scrum in many cases. People gets ga-ga over the power of Scrum and starts to implement it with the knowledge at hand. That leads to that the core values of Scrum and agile easy get misused or misunderstood. And then you end up in implementations like:
Yes – we are doing Scrum here. Well we have no board, or Scrum master or product owner. But we have daily meetings and don’t much documentation.
Kanban – of course. We have been running it a year! Well we don’t have any WIP-limits and not all tasks are on the board…
Implementing a process change will be hard. Problems are bound to occur and those will help you to improve your process. But inexperienced teams will need guidance (firm at the outset) through that process.
To just inspire them and not follow through with proper coaching was not very nice or professional of us – we will do something about this. Soon.
Conclusion
This has been an interesting journey to follow so far. It’s just beginning of course but already we have seen progress and decay (our bad to some extent). I’ve learned a lot by trying to teach some simple practices in a domain I knew little about.
To do this together with Morgan has been great. It really good to have a speaking partner as you coach a team. Try it for yourselves.
And please – do try to implement Kanban in non-IT related business. You will learn a lot from it. But don’t leave them alone – they will need your help.