Imagined in 2009 to help teams move smoothly from Scrum to Kanban, Scrumban has now become a fully-fledged framework. While it may present itself as a hybrid methodology, Scrumban is not simply the addition of Scrum and Kanban. What do we find in the two models? How to practice Scrumban? Learn about this methodology by following the advice of Coline, Scrum Master at Wemanity.
1. Scrumban, the perfect mix between Scrum and Kanban
The Scrum and Kanban frameworks both allow you to implement project management, but each have a very specific logic. Scrumban connects the two frameworks while retaining the advantages of each of them.
Scrum and Kanban, two different approaches…
Inspired by Lean, Kanban is an agile method that relies on strong visual management. It is a timing framework inherited from industry, and linked solely to the concept of pull flow. Production is therefore triggered by the order, which limits the amount of work in progress and makes it possible to deal with difficulties as they arise, in a logic of continuous improvement. Kanban is also known for its visual management dimension. In this mode of project management, the tasks are in fact displayed for all to see on a table, so that the team can follow the progress of the project in real time.
Conversely, Scrum works in high flow. The tasks to be accomplished are defined at the beginning, with timing made during the sprint. The framework is also distinguished by the existence of roles to distribute and events to program.
…That come together in Scrumban
Pull flow or push flow? In Scrumban, it is ultimately the logic of pull flow specific to Kanban that we find at the core of the methodology. The model, however, borrows many of the founding elements of Scrum for the rest. The team is therefore made up of a Scrum Master, a Product Owner and developers, all of whom have the same responsibilities as in a Scrum team. As in Scrum, the work is organised with proper timing, an iterative approach and short deadlines, but using a Kanban board.
Something that’s important to note, however: contrary to what you might think, Scrumban does not consist simply of practicing Scrum on the one hand, and in having a visual management tool on the other! ‘In Scrum, we can also do visual management’ specifies Coline. ‘In Scrumban, tasks get done as soon as they are feasible and embarked upon as the process moves along. Beyond the use of the Kanban board, the team therefore works differently, without everything being planned in advance for the entire duration of the sprint.’
The advantages of Scrum and Kanban in a single framework
The differences between Scrum and Kanban give them additional strengths. By practising Scrumban, a team therefore gives itself the opportunity to accumulate these strengths!
On the Kanban side, on-demand production enables costs to be optimised, and problems to be quickly detected and corrected. Visual management contributes to establishing a principle of transparency within the team. It facilitates communication and is used in particular to visualise bottlenecks. Overall, the methodology is recognised for improving workflow management and accelerating the resolution of production anomalies.
Regarding Scrum, it is the events that are interesting according to Coline: ‘Scrum is very structured, with unavoidable events punctuating the iteration, each with its own interest. The sprint review, for example, offers the possibility of collecting feedback and engaging in an introspection process, which is valuable. More generally, Scrum events make it possible to guarantee the three pillars of the framework, namely transparency, inspection and adaptation.’
Finally, the meeting of Scrum and Kanban has the advantage of combining the possibility of having a framework while maintaining a certain flexibility. In other words, to erase the rigidity and the race to the goal often criticised in the Scrum process.
2. The essentials to know before trying Scrumban
Scrumban adapts to the context of production and processing. However, certain fundamentals must be respected to practice Scrumban.
Building the team
If the roles are the same as in Scrum, the team must however fully understand the framework and integrate its particularities, in particular the implementation of a continuous flow of elements. This is particularly true for the Product Owner, who must adopt a different approach from the one he has in Scrum according to Coline: ‘The Product Owner is always responsible for prioritising the product backlog and all the tasks to be carried out during the iteration. However, there is no sprint goal. The team takes overall responsibility.’
In addition, it is better to practice Scrumban with an experienced team: ‘Most often, this involves offering Scrumban to a Scrum team wishing to switch to Kanban, knowing that it is rare to do Scrumban with a team that only knows Kanban. For the experience to be successful, it is in my opinion preferable that the team is comfortable with Scrum. The ideal is for the team to be capable of organising itself. Team members should not only be familiar with good Scrum practices, but also know how to take a step back from their work and that of others.’
Organising work
In Scrumban, there is no sprint backlog: the Product Owner distributes the tasks as they go. He thus waits until the developers have completed the work in progress before requesting them again, within the WIP (work in progress) limits previously defined with the team.
It is therefore a real-time prioritisation logic that prevails, as Coline explains: ‘We have a certain number of WIPs (‘Work In Progress’), which we cannot exceed. We maximise the ‘done’ (what has been completed) before being able to embark on new tasks. The work is thus made more fluid and the overloading is limited’
Visual management with a Kanban Board
To work in Scrumban, the team must have a table representing the workflow, with columns corresponding to the different stages of progress.
Concretely, it is a question of providing the columns ‘to do’, ‘in progress’ and ‘done’, by adding a ‘test’ column. The use of the table is then very simple. Each task is noted on a Kanban card, which takes the form of a Post-it® (paper or digital depending on the medium). The tasks are then moved from one column to another by the team members, until they are completed and positioned in the right column. The team is also free to create colour codes or categorise tasks by column according to their prioritisation, optionally adding numbers.
‘It is recommended, alongside the Kanban board, to create and use a cumulative flow diagram’ advises Coline . ‘Thanks to this graph, we can visualise the demands that are piling up.’ The board must also clearly show the WIP limits, i.e. the minimum and maximum amount of work allowed.
The ceremonies to plan
In Scrumban, there is no such thing as sprint planning. There is therefore no real sprint planning meeting as it exists in Scrum. Since the Product Owner sets a goal without presenting user stories to develop, the kickoff meeting is more like an ‘objective sprint’.
On the other hand, the team can work by adopting the other Scrum events:
- the daily, to maintain fluid communication;
- the sprint review, to present new features on the product and obtain feedback to prioritise and/or adjust elements already developed,
- the retrospective sprint, to take stock of the development cycle and identify areas for improvement.
Indicators to follow in Scrumban
Kanban indicators are used. You should therefore be interested in the Lead Time, that is to say the time elapsing between the entry of a task in the Kanban board to its classification in the ‘done’ column.
Cycle Time also deserves our attention: ‘It’s about looking at how long a task stays in a column. This is important for detecting time-consuming tasks and questioning the causes.’
Is Scrumban the right framework for your team?
While Scrumban has its strengths, it is not suitable in all contexts. ‘Some teams are testing the framework to switch to Kanban, but choose to keep Scrumban,’ comments Coline. ‘On the other hand, the model is not magic! It will not solve the difficulties encountered by a team in the use of Scrum for example. We must therefore use it because we want to benefit both from the strengths of Scrum or Kanban and because the project lends itself to it. Scrumban is therefore suitable for projects for which it is difficult to assess the workload upon start-up.’
Like any tool, Scrumban will only be of real utility if the operating mode it establishes meets your specific needs, even if it means adapting it so that your team finds its feet.
