What’s Kanban?
It isn’t a question you’d expect to hear from a team adopting work in progress limits and just in time tasking while only committing to small user stories.
One of my favorite aspects of being a ScrumMaster and Agile Coach is witnessing a team evolve by inspecting and adapting over time. Granted it isn’t a ride for the faint of heart, but it can be an extremely fascinating experience. This is especially true when the team feels empowered enough to mold themselves into a highly functioning unit.
From my experience, this becomes most apparent during iteration retrospectives.
Retrospective #39 Notes
- Team decided tasking entire two week iteration in one day was burning them out.
- Unable to focus for long periods of time & felt as though it was delaying coding efforts.
- Tasks became obsolete half way through the iteration because of what we’ve learned by digging into the code.
- Decided to break tasking down into two sessions per iteration.
Retrospective #40 Notes
- Team still feels confined by the 2 tasking sessions.
- Seems as though we’re spending too much time tasking at once & still have obsolete tasks.
- We decided to task in smaller bunches, 2-3 stories at a time as needed throughout the iteration.
Retrospective #41 Notes
- Tasking as we go is working much better, yet it does result in more interruptions.
- Team wants to adopt work in progress limits for stories.
- Limits will help us prioritize, ensure stories are in good shape before moving on.
- We decided to set our work in progress limit to 3 open stories at a time.
Retrospective #42 Notes
- Keeping our WIP of 3 open stories.
- Tasking as we go interruptions are less of an issue now.
- Medium & large stories are killing our flow.
- Only commit to small & extra small stories to help with flow.
- We decided to decompose anything above a medium down into smaller chunks.
Could you be witnessing a team inspect & adapt itself into Kanban?
Since this team is still running two week iterations, and keeping a good bit of the Scrum ceremony I’m not entirely sure. It seems to be more of a Scrum / Kanban mix for now (Scrumban?), and I don’t see them discarding the rest of the Scrum ceremony anytime soon.
It should continue to be an interesting ride, that is for certain!
Loading ...
#1 by Dennis Stevens on June 1, 2010 - 10:30 am
David,
I think this is awesome. Keep doing what makes sense – draw from what others are learning to handle challenges. I believe that there are many teams that have taken this same path. The coupling of Ready Queue replenishment to your iteration cadence was artificial and led to challenges for the team. Are there other cadences that might be good candidates for decoupling? In some cases it makes sense to do releases when releases make sense, rather than at the iteration boundary. If the Scrum Ceremonies make sense and work for your team – keep doing them.
Dennis Stevens
#2 by David J Bland on June 1, 2010 - 12:30 pm
Dennis,
I'm somewhat puzzled since some Kanban experts view Scrum Ceremony as waste. From my experience, Scrum can feel heavy for teams that work solely on Keep the Lights On tasks, or are very small in size.
This team doesn't fall into either of these categories.
They obviously feel as though they benefit from aspects of Scrum. One could argue Scrum teams apply WIP limits when tackling tasks (ie swarming).
As they mature, I imagine they'll try to decouple other aspects as well… and I find it fascinating.
-David
#3 by Dennis Stevens on June 1, 2010 - 2:43 pm
Right. In a team doing KTLO the ceremonies around iterations are very likely waste. A new team starting a new project probably needs iterations and the ceremonies surrounding them.
I wrote about this recently – when does the iteration become a cost http://www.dennisstevens.com/2010/05/03/iterati.... It will vary per team, based on the maturity of the surrounding organization and the type of work they are doing. I believe a team can typically move beyond iterations after the first release. Your processes are clear, we aren't learning dramatically new things about the product or our team, we can probably decouple everything except operations reviews from a time-box. Marko Taiple says as soon as you have moved beyond chaos http://huitale.blogspot.com/2010/05/commenting-.... The important thing is to understand your “system” and move toward what works best for a given team in a given circumstance – not be locked into some preconceived set of practices and ceremonies.
Dennis
#4 by Stephen Reed on June 5, 2010 - 2:39 am
You could take a look at http://www.infoq.com/minibooks/kanban-scrum-min... which very much describes using both Kanban and Scrum ceremonies within an agile development team as totally acceptable and even encouraged. I think these guys put it well “Kanban and Scrum – making the most of both” plus with their great illustrations, flexible, real, and practical guidance this is now my favourite guide on becoming agile within any development environment.
#5 by David J Bland on June 7, 2010 - 3:17 pm
Stephen,
Yes I think that is a good compare / contrast document, however in speaking to other people they tend to only use kanban or scrumban for maintenance teams.
I'll go back and re-read it again.
I also feel as though their XP/Scrum diagram with the XP core & Scrum container would not set well with early XP adopters
#6 by David J Bland on June 7, 2010 - 7:17 pm
Stephen,
Yes I think that is a good compare / contrast document, however in speaking to other people they tend to only use kanban or scrumban for maintenance teams.
I'll go back and re-read it again.
I also feel as though their XP/Scrum diagram with the XP core & Scrum container would not set well with early XP adopters