Increasingly popular, the Scrumban also called Agile Kanban is an agile methodology that allows you to benefit from the iterative, incremental and adaptive concepts of the Scrum. It takes advantage of the kanban flow concept. If this last sentence is not clear, do not panic, I will explain you all in this article dedicated to scrumban.
Scrumban origins
Scrumban was originally created in 2009 to propose a transition methodology of transition from scrum to kanban and lean. But now,
Today, scrumban has became a classic agile methodology that allows to help the scrum teams to overcome the problems. And its adoption since for some time is enough dazzling.
Iterative and incremental
The Scrumban benefits from the pillars of agile methods that marked great differences from traditional methods.
As shown the diagram below, when we imagined a product “A” in traditional method (V Cycle for example), we waited 6 months to see the product “A” to be delivered. However, the key users were not solicited during development and so they were rarely happy of final product delivered. It was often necessary to add 6 months of development to make the product “A +” ; it was thought when the product was presented for the first time (after the first 6 months) to the key users. But for that, it was necessary to have the chance to have the additional budget needed.
In Scrum (and other agile methods), we do short iterations to get feedback from key users at the end of each iteration; we are thus 6 months later with a product “A” that differs a little from the product imagined at launch. It really pleases users thank to feedbacks. This product will contain part of the initial scope, new developments not thought at the beginning of the project and undeveloped parts.
The agile does not allow to develop more but allows to really develop what our key users expect.
Scumban also adaptive!
The Scrumban also benefits from an essential pillar of agility: adaptation. If we can talk about scope adaptation as we saw in the previous point, we must also remember that the agile methods impose the notion of “continuous improvement”.
As the picture below shows, the team will constantly improve its framework and operation by stopping obsolete practices and testing new practices.
Scrumban enjoys scrum roles and scrum ceremonies
The Scrumban proposes classical iterations coming straight from the Scrum as presented in the drawing below to put these iterative, incremental and adaptive concepts in place.
I will write an article to present you the scrum iteration but here are the ceremonies :
Planning
In scrumban, we will prefer to name it “objective” because we are not going really plan the iteration. We will just define the desire goals during the iteration. The developers will not split the items in subtasks (we will see why later)
Product backlog refinement
The team will refine the backlog together.
Daily scrum
The developers will align together.
Sprint Review
The team will do the review of all finished work and why not a demonstration.
Retrospective
The team will work to improve their organisation, their framework and their pratices.
In scrumban no pushed flow but pulled flow like kanban!
Unlike a classic Scrum application, the Scrumban will make the pulled flow and not the pushed flow. To explain simply, the teams will not foresee anymore the work for tomorrow.
What’s this concept of pulled flow? The Product Owner will alimente the “todo” column of the board when the developers needs work; he will not prepare the work before the sprint and the team doesn’t define a sprint bakcklog.
So, the “Sprint Planning” change and become rather an “objective iteration” where the Product Owner will propose to the development team the objectives that he would like this team to reach at the end of the sprint. The concept of scope (items of the sprint) doesn’t exist anymore in scrumban.
The Product Owner will propose a new user-story (or new item) to the developers when they finish one. He will propose the work in real time. You will understand that the developers will split the user-stories (or other items) during the sprint.
Why do Scrumban ?
This methodology allows you to benefit from Scrum in contexts where you can not really predict work in the coming weeks. For example, we could talk about a support team, a team of Data Scientists …
More and more teams come to use Scrumban because they like to benefit from both methods (scrum and kanban). If you seem to have difficulties to stabilize a sprint or are interested in kanban indicators, I can advise you to test the Scrumban
Useful link: agile framing
2 Trackbacks / Pingbacks