In that that session, someone asked the question, "can we apply Scrum and Kanban on the same project?"
Before I provide my opinion, I wanted to check with folks out there -- what do you think? Do chime in with your comments.
blog
Suggest a topic
Subscribe to the RSS feed
Other Great Blogs & Sites
10 comments:
Since Kanban is a change management system you can apply it to anything. So the answer is yes! :)
Of course, after you use it, many of the beliefs that are part of Kanban are typically not part of Scrum (e.g., explicit policies, inclusion of management, visibility inside the team's process - not just what goes in and comes out). So in the end, Kanban will transform Scrum.
Applying WIP limits came out of an iteration retrospective with my current team.
For example:
Iteration #123 = 12 user stories
Open Story WIP = 3
So we only have 3 open stories at any given time.
This helps us in several ways, but most importantly it gives us focus.
David
Thanks for sharing your experience. Adding WIP limits to stories within a Sprint seems like a very practical and immediate thing to do.
Hi Alan
Some might argue that Scrum is a change management system too! I like your reference to explicit policies, management inclusion, etc. What are some of the things Scrum can bring to Kanban?
Sanjiv
I'm with Alan. Kanban can sit on top of anything. I'd say Scrumban is essentially putting Kanban practices on top of an iterative timebox.
Ask the question, "what value does it add?" You could argue that SCRUM already has kanban incorporated in it.
In the general sense, kanban is the signal that tells you it is time to produce a certain volume of an item. You define the volume according to the takt rate for the overall value stream. Do you know what the true demand is on your value stream for features or projects?
A SCRUM team gets the signal to produce stuff when a sprint begins. The volume of stuff is defined by the velocity of the team and the items-to-produce come from the top of the backlog. This is a kanban signal.
Kanban in the software world seems to me to identify a desire to signal the production of ever smaller units of work (not a bad thing); why wait till the beginning of a sprint. You could have ever smaller sprints and get something very similar.
I think the concept of software kanban is a reflection of the fact that customer demand is very intangible, so why set a takt rate (sprint duration). After all, there seems to be an insatiable appetite for more software regardless of what our capacity to build that software might be.
However you approach the problem it is critical to understand why and where certain techniques work and apply them at the right time and place. SCRUM solves many other software development problems beyond when to schedule work.
Siddharta, Alan
Agreed - combining Kanban with Scrum yields a further WIP limits within an iterative timebox. What types of situations do you think might benefit from that the most? High variability, uncertainty, etc?
Sanjiv
Russ
Upper case Kanban, as applied to software development considers not only the visual signal for pull, but also the WIP limits. So, yes, if we combine Scrum and Kanban, it would seem we're going for ever-smaller batches.
Sanjiv
Also to add on, I think the biggest use for Kanban will not be in limiting small tasks within an iteration, but to look at a bigger value stream.
In a typical Scrum project, there are huge delays in going from idea to backlog (pre-scrum), and more delays in going from a "potentially releasable" software to actual release (post-scrum).
Kanban can be overlaid on top of Scrum to manage flow from end to end. Thats where the big gains will be.
Post a Comment