So that we can easily find ways to constantly improve while collaborating effectively and sustainably, I like kanban as a tool which shows what constrains transforming concepts into cash. I believe it allows us to see the whole system and our part in what to do to help in the transformation of the system into a better one and our ideas in to innovation. It seems to me there would be greater benefits for all involved.
For software a kanban tool must be highly visible, with a policy to strictly limit work in progress and a policy to only accept work when there’s capacity. To be effective, it requires consensus on these policies from the people involved.
Kanban is a Lean way of saying, “I trust and respect you”.
After a few months working with a client, a WIP limit was introduced on story points at the latest planning meeting. When we started I said, “The good news is, you no longer need to track hours remaining. The better news is that you may never have to have this type of meeting again.” Here’s a nearly verbatim email from senior management, after planning.
We concluded the sprint planning today with a stack ranked backlog based on work folks did over the last couple of days (to get it prioritized). The sprint planning went well, all teams are “fully loaded” for the sprint except for Team-1. Here are my observations, anyone on this thread, please feel free to pitch in:
Team-1 was at ~(x) points, and the max per sprint is (y), so they could have taken more user stories. We went down the backlog and the next 6 or 7 required [special-skilled work only a couple people can do and they were] already maxed out (…) for this sprint. Further down the backlog were [feature groups for another team] related stories and since [those feature group] teams were max’ed out, we just stopped.
So, does this mean that Team-1, once done with their user stories, are going to start twiddling their thumbs? Maybe, but first, they HAVE to help other teams:
- with tasks
- with user stories
- help QA in testing to get the stories to the done state
- remove blockers from the blocker board (and we have identified new blockers that are slowing us down per the retrospectives)
- and basically help in any way shape or form move the stories on the board to the done state.
If all of the above is exhausted and there is really nothing else that Team-1 can do to help the current “in-flight” user stories across teams get to the done state, then, yes, they will be twiddling their thumbs and we would have identified a blocker that we need to address. Otherwise, we continue to push forward.
Do you think the new WIP constraint and attitude will help? Will there be an increase velocity and in quality of delivery, in your opinion? How about the effect on sustainable pace, or collaboration? Please comment below and I’ll provide my own opinions in following posts.
Available from Karl’s blog for download. The session went well, everybody returned for the second half from the first half. I really enjoyed the simulation at the end, although we ran out of time to fully go through it. If you happen to use it, would you contact us and let us know how it went?
As Karl Scotland noted, we will be presenting a session on Kanban, Flow and Cadence (KFC) at the Agile Conference this year. This will be Thursday 7 August from 8-10 and then 10:30 to noon in the Essex Ballroom as part of the Breaking Acts Stage.
This workshop explores three important Lean concepts – Kanban, Flow and Cadence (KFC) – which can be combined to generate a more pipeline-based approach to software development, as opposed to the more common timebox-based approaches of more traditional Agile methods. The presenters will describe their experiences implementing these ideas at Yahoo! and explain the concepts using examples, simulations and games. In addition, because this is a new and emerging way of working, there will be an opportunity for discussion between the participants about how the ideas might be applied in their own situations, in order to advance the art.