You can hear here and there that Kanban scales up pretty well. Actually one of Scrum issues, and I believe one that isn’t addressed neatly, is what to do in projects that take more people than a single Scrum team can accommodate. Definitely one thing which is surfaced pretty soon as Scrum team grows is standup meetings.
As you go with three standard questions through growing team it naturally takes more and more time. Soon it can be a problem to fit into short time-box you have for such meetings.
When team are adopting Kanban they usually leave standup unchanged. However it means that, at some point, they face the same issue as Scrum teams do – 15 minutes is not enough anymore.
Recently Jorn Hunskaar shared such story on his blog. It prompted me to combine a bunch of ideas into a single answer that can be a guide how to improve standups organized around Kanban board. I left a lengthy comment on Jorn’s blog although I believe it is worth to share the idea here as well.
Instead of running typical round-the-table with answers about what happened yesterday, what is going to happen today and what issues are there you may try to redesign the pattern you follow on standup.
- First, go through all the blockers (if there are any). These are definitely your pain points at any given moment. It means that you definitely want to invest precious standup time on blockers. This is no-brainer.
- Second, discuss expedite or emergency items (again, if there are any). This is top priority work from the perspective of the whole team. This is something you really need to get done even at cost of delaying other work. Again, something which is worth investing scarce resource into.
- Third, go through items that hasn’t moved since last standup. These are items which may be risky. Maybe they weren’t supposed to move but in this case it would be a quickie – not much discussion needed. Otherwise it is worth to have a brief analysis what happened that prevented moving cards forward. By the way, it means that you should have some kind of mechanism to mark index cards which aren’t moving, which is usually tricky.
- Fourth, go through everything else. One more guidance you can have is discussing items of one class of service after another in order of priorities. In other words you start with highest priority class of service (bugs, critical features or what have you) and discuss all items of this class of service. Then you move to another one. Well, at least this can work considering that you can tell which class of service is more important than other.
One more rule would definitely be reasonable: within each of these groups you start from the right side of the board and go to the left. This shows that the closer an item is to being done the more you want to discuss it as you are closer to complete it, thus bring value to your users, clients and stakeholders.
Now, up to this point there is little difference – you still go through every single work item which is on the board. There is different focus on issues and you may skip discussing obvious pieces of completed work but still, a lot of stuff to go through.
However, given that you’ve just sorted topics to discuss by priority you can just use a simple trick and just finish discussion when the time of the meeting has elapsed, no matter if you were able to finish all the things. It likely means that you’ve covered all the items from first three groups, and definitely all of them from first two, and whatever leftovers you have are items which require least discussion or no discussion at all.
It also means that on a good day you can cover all things, or more things than on worse day, but that’s perfectly OK. What you basically need is to ensure that most important stuff doesn’t go unmentioned.
Going a step further means that you can skip a discussion over a specific groups or sub-groups of items, e.g. a specific class of service, when you see it doesn’t really add any value. If you aren’t sure try to cover it during standups and see what outcome you get. Then you can start experimenting with the plan of the meeting.
Ideally, after some time, you will end up discussing only important stuff, say, blockers, expedited and stalled items and maybe others which are brought by any team member for an important reason and just skip regular work which needs no more attention than a silent confirmation that everything is perfectly fine.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
6 comments… add one
We just go from right to left on my teams, paying special attention to blocked cards. Goes very quickly usually and the right to left focus is because it’s a pull system and helps reinforce that we don’t pull new cards from the back log until we have completed another card.
I like the idea of letting the Kanban board do the talking. A well-designed board should clearly show where the problem areas are. Therein lies an issue. The board needs to be designed to properly reflect the team’s workflow. Too often, teams setup a basic Kanban board that doesn’t add much value to the process. Perhaps the approach you outline backed up with retrospectives, will lead to better board design.
@Josh – If you go through all the cards starting from the right side doesn’t make that much of difference. However, one important thing you get is you help people understand that having a couple of equally important features on the board you should firs focus on the one which is closer to completion, even if this means focusing on a bit different part of software development process than you are comfortable with.
“Reading” the board from the right becomes more important when you accept the possibility that you won’t go through all the stickies on the board during a standup.
Even then, in my opinion, it is more important to start with special-case items, like blockers, expedite or stalled items. If you have time to discuss perfectly normal features which are close to release and skip blockers in development, you aren’t focusing on the right thing. But again, if you go through all the features on the board every time, the only difference is helping people to build the right mindset – what is more and what is less important.
@Vin – You touch a very important issue, which is a Kanban board which is disconnected with the way team works. It can be either a generic software development process set up because no one really put much thought into it during design, or ideal process they’d like to follow even though in reality they’re doing something less-than-ideal or just the board which isn’t updated as the process evolve.
However the simple activity of focusing on the board during standups can help to improve its design as well. I assume team members would step forward and add their two cents if an important issue wasn’t discussed. It may be a very good trigger to change the board. Actually starting the new approach to standups can be a perfect occasion to review the board or make board-related retrospective.
There are also simple visuals on the board which aren’t really dependent on a process team has mapped. Blockers and expedite items are such examples. This part can go well even if your board is screwed up.
@Pawel, in my experience it’s very important to start from the right and go left, primarily because on my teams we mostly make updates at our daily stand-up. This means that cards will get moved to the right..if you start from the left you end up having to keep going back to pull more cards into the value stream. The right-to-left approach makes the flow of the team discussion go well and our focus is primarily on the value stream and where cards are at in our value stream.
@Vin – great point, and I’ve struggled with this in the past. But if they team is clear that the board should reflect the reality of our process and not an idea or simplified version, it comes quickly. Our kanban is fairly complex, but it reflects our value stream well. And the best part about that is experimentation. We modify our value stream in places as an experiment when someone has an idea about how we can work better. We can do this anytime, it always happens during the daily stand-up. We don’t require retrospectives except for what we do daily.
it was awesome!