The other day I was asked to discuss how we can improve the way one of our software development teams works. Well, actually it was rather something like “Pawel, help us to implement Kanban” but, as it soon appeared, it wasn’t that simple.
A typical discussion about implementing Kanban
Me: So where do we start?
Colleague: Um, I’m not really sure if Kanban is really for us. Convince me.
Me: I don’t want to. If something doesn’t suit your team I’ll be the last person to convince you to implement it.
Colleague: So where do we start?
Me: Maybe with problems you and the team have. I guess there are some otherwise we wouldn’t be talking now.
It isn’t about applying recipes
The discussion changed its course. We immediately switched from discussing Kanban to talking about issues and looking for a solution which would be suitable in each and every individual case. If one of problems is people don’t want to have yet another place to do task management, and they can’t abandon either of current systems, introducing Kanban board may not be as great idea as it initially appears.
If you start discussion with the conclusion already fixed in your head you will not only miss opportunities to improve but you also risk applying the wrong cure and making the situation worse.
It is OK if you just don’t know
A couple of times through the discussion I came up to the point where I had no idea what the right solution might be. And this is perfectly OK. It’s not about playing knowledgeable person. It’s about giving the good advice or not giving any advice at all.
What more, admitting that you don’t know the answer is just a starting point for digging deeper. Each of these moments triggered some changes in our analysis. If we can’t go further here, maybe we should try there. Let’s stop talking about techniques which may or may not work and make a fast-paced Q&A session about potential issues the team may face. Or maybe let’s do mental walkthrough of processes the team covers.
As it appeared each time we admitted that we don’t know helped us with coming up with a reasonable conclusions at the very end.
Adjust tools for people, not the other way around
When you know some method or approach and it works fine for you, you are always tempted to apply it in other environments too. The problem is other environment means other people. As a result your approach may not be so great anymore.
But who said you can’t change the approach? Are methods we use some kind of dogma? Actually choosing a subset of techniques or practices from any given methodology is usually better than not using them at all. And if you choose wisely even a couple of small changes may yield significant improvements. So yes, do adjust methods before applying them.
That doesn’t mean people shouldn’t change ever. Of course they should. But motivation to change should be intrinsic and not enforced from outside, i.e. because manager told so.
A funny thing is that with this approach you can end with similar conclusion to the one you started with. The difference is now you are more likely to succeed as, even though you aim at the same target, you will choose different way to get there.
And in case you were curious, yes, we eventually came back to Kanban.