Agile teams face many challenges, and the demands on those teams can change throughout a product's lifecycle. Often the demands of a new Scrum team creating a new product are very different from one that is adding features and supporting production issues for a mature product. If you find that you are constantly tweaking your current approach to support these new demands, changing to a Scrumban development framework may be the answer.
Last year one of our Scrum teams was working on a mature product line and was facing a number challenges that resulted in process workarounds (or process "smells"). I successfully transitioned the team to Scrumban and this resolved the problems the team was facing.
In Part 1 of this blog entry I'll give a quick primer on Scrumban. This is needed to understand how making the transition could be beneficial. In Part 2 I'll discuss five common Scrum "smells" and how Scrumban resolves them. To understand Scrumban, you should have a good grasp of Scrum and Kanban. For more information regarding Kanban and Scrumban, please refer to the links at the end of this post.
The Basics of Scrumban
Scrumban is a hybrid approach that combines the practices, and mindset, from Scrum and Kanban. It is similar to Scrum in many ways, but borrows a lot of cultural nuance from Kanban. Because it is a hybrid, teams in industry have chosen to implement Scrumban differently based on the team's experience, organizational structure and culture. It is often used for mature product lines that are susceptible to interrupts.
Kanban adheres to the following key tenets: visualizing workflow, limiting work in process (WIP), and measuring productivity. Scrumban also follows those tenets.
Often in Scrum, you will have a Story with sub-tasks representing the work to be done (very common if you are using Jira). Using Scrumban you would have a Story that progresses through various stages (or phases) or work. The Stories that the team is working on and who is working on what aspect of that Story, are always visible in each stage.
Scrumban removes the practice of limiting WIP by time (i.e. velocity and Sprint boundary) and replaces it by limiting WIP for each stage. The real benefit of this is that team composition issues become clear and swarming occurs naturally. Additionally, this allows teams to take on varying size stories without having to adjust for Sprint boundaries and unplanned, or frequent, changes in team composition (e.g. someone is unexpectedly out sick for a week in the middle of the current Sprint).
Scrumban, like Kanban, measures productivity using Cycle and Lead Time metrics. Cycle Time is the time from when someone starts working on a Story until the work is completed. Lead Time is the total time a Story is on the Scrumban board (often it starts when a Story is put on a Ready stage until it is off the board or shipped).
Finally, Scrumban is based on having a continuous flow of work. Once the pumps have been primed (initially you will have to "push" stories into the various phases), then Scrumban follows a "pull approach" for completing work.
In Part 2, we'll continue the discussion with a look at five common Scrum "smells" and how Scrumban addresses them.
References
For a decent Scrumban overview, I'd recommend Paul Gambill's, Scrumban: A different way to be Agile, as a good beginner's article.
For Kanban, I like these two simple, and short, explanations: http://kanbanblog.com/explained/ and http://www.everydaykanban.com/what-is-kanban/
