OK, I admit it. This is a biased post. But you should have known. I’m sharing our journey with Kanban for more than a year already and the journey itself is even longer. And I’m still not fed up with all that Kanban thing. But then, after days like today, I realize why I appreciate Kanban that much.
Majority of you was in this situation before – you saw your team working on tasks as planned when someone came with that super-important, top-priority pre-sales project which totally required that your team added widget foo to some application. And it had to be done exactly then.
What I used to do in those situations was anything between panicky search for least loaded engineer and panicky explanations why we couldn’t do that before requested deadline. Either way the word “panicky” was involved. In every situation the threat was the same: we had a lot of pre-planned work to do and needed no additional distracter so what we really hoped for was to get the salesman hell out with his damn pre-sales project.
And now? Now I just put the task on the top of the stack. Well, I do if it is important enough of course. Then the magic happens. In vast majority of cases you get someone to start working on your damn widget tomorrow. Day after tomorrow if you’re less lucky. Glad I could help you that fast. Note: I didn’t tell you “at the beginning of the next sprint.” But now, the best part.
It doesn’t ruin the way we work. We aren’t distracted by your drop in. It is the process we follow which allows us to deal with the issue so quickly.
As I think about that, we hate all those unplanned tasks not because they’re unplanned (we know they’re going to happen after all) but because they force us to change our initial plans. If we had a framework which helps us to embrace those tasks in a way which is acceptable for our dear stakeholders (what a nice way to call salespeople, isn’t it?) wouldn’t that be worth trying?
So what are you waiting for? Go try damn Kanban!
Going to the meeting to tell business folks that you’re going to do your best adding all those crazy things they think they need to get the deal (and not lying on the same time) and then getting back to the team knowing that you aren’t going to change all their plans is priceless.
And that’s the beauty of Kanban.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
6 comments… add one
That’s the same case with pretty much every Agile methodology, isn’t it? Some admittedly discourage teams from modifying the scope of an already ongoing sprint/iteration, but in the end it’s always the team’s call. It doesn’t break planning, just shifts all other stories downward.
Yes, it works that way with pretty much any approach which has “embrace change” printed on its banners. The trick with Kanban is you don’t even need to explain your method. You don’t have to teach your stakeholders what sprint is and why it is forbidden to add anything to the sprint. Oh, we really can’t. No, I’m serious. I mean we really can’t. Oh… yes Mr CEO we’ll make the exception for this time… Like we always do…
A trick with Kanban is that it’s so flexible that you very rarely has to agree for such compromises, which is always good. As a person who is engaged on both business-side and development-side I appreciate that very much.
Of course all these drop ins can ruin the work anyway, but that’s the subject for folks responsible for product management/product ownership.
Pawel, I can not stress enough how awesome it was to read this post. I’ve been there, having the damn CIO show up half way through a Sprint and suddenly surprise us with a promise he made to someone 5 minutes earlier. I would look him straight in the eye (on more than one occasion) and ask how he expected the teams to complete his task(s) when the teams were already committed to the Sprint. His response? “Oh, just be creative”.
At the time, I just thought he should shove the 3×5 index card up… Let’s just say, at the time, I was very dogmatic about Scrum. I hated it, having the CIO disrupt the flow we had achieved. Talk about a velocity killer. It was really before I had an exposure to Kanban.
Now, I would just shoot him a big fake smile and put the card that the top of the board. Maybe I’d sneak into his office and unplug his network cable. Regardless, neither activity would impact the team and their flow.
Derek,
If you can’t teach decision-maker to respect your process find a process which embraces the way decision-maker works. Kanban is a nice tool to deal with issues related with decision-makers located outside of the team.
But then, if problems are more inside the team Kanban is rarely enough to solve them. It seems I’m pretty lucky to work with a great team of disciplined engineers.
What tools did you use? Or only whiteboards with post-its?
Check http://www.getsmartQ.com – a great way to take it online.
Steve,
First you should ask whether you need to take it online. There’s no point in moving Kanban board to the cloud just for the sake of doing it.
If it’s possible I strongly advise not using software to coven Kanban board. But then if you work with distributed team it’s inevitable to use some software.
And in terms of choosing software for Kanban board I can recommend Kanbanery.