What is ScrumBan

To understand what ScrumBan is, we first need to revisits what Scrum and Kanban are.

Scrum:

Scrum is based on six principles:

1: Empirical Process Control: (transparency, inspection, and adaptation). Every Scrum ceremony has its core based on these 3 Empirical Processes. In the sprint review we inspect the product that we are developing; in Retro, we examine the development process. In daily standup, we check our progress towards our sprint goal to make sure we are on track. We adapt where needed.
2 Self-organisation: The team needs to be able to self – organise. There should not be anyone telling them how they need to do the work. The team should be empowered.
3: Collaboration: The collaboration is the secret ingredient in scrum teams and to improve the collaboration within the Scrum team, it is recommended that ideal team size should be 7+/- 2 because this is the perfect size for most collaborate groups. To improve this collaboration, companies like Zappos, (the online retailer which got brought out by Amazon) expects its managers to spend 20% of their time in social activities with their team members.
4: Value-based Prioritization: Work on the highest value items first.
5: Time-boxing: sprint length is 1-4 weeks, plan for small time-boxes, and every Scrum ceremony is time-boxed as well. Example: daily standup – 15 mins.

6: Iterative Development: Build and release the product in smaller batches with highest value items first.

Kanban:

Principles:

1: Start with what you do now: no new processes or team structures. We have our current process for a reason and let start with them as they are.
2: Respect the current process, roles, responsibilities, and titles: you don’t have any new fancy role or titles like Scrum Master, Product Owner, Pigs and chickens
3: Agree to pursue incremental, evolutionary change as opportunities are discovered. Baby steps towards greatness.

Six Practices:

1: Visualise: make your process visible to the team and everyone
2: Limit WIP: limit the work in progress.
3: Manage flow.
4: Make policies explicit.
5: Develop feedback mechanisms at the workflow, inter-workflow, and organisational levels:
The Kanban has its origins from Toyota and in Toyota when there is a fault found in any car in the production line. The production line is stopped, and everyone works to fix the error there and then. This means that whoever caused the issue has become aware of it without any finger pointing. You might think that stopping the production line is a waste of time and must slow them down. However, this is not the case, as on average it takes Toyota 17 hours to manufacture a luxury car. On the other hand, BMW fixes fault at the end of the production line, and it takes BMW on average 57 hours to produce a car. That is not the only thing, on average there are only 34 defects found in every 100 vehicles Toyota makes whereas in BMW on average 78.7 defects are found per 100 cars.
6: Improve collaboratively using model-driven experiments.

Each methodology has some inherent weakness and difference.

• Scrum doesn’t prescribe specific ways to help measure or manage problems and dysfunctions before they manifest themselves –
• Scrum teams often become mini waterfall within the sprint.
• Doing all requirements, design and UX within a sprint is not feasible anymore. I know that nowadays the Scrum coaches recommend that designer work one sprint ahead of Dev, but this has some complexities as well.
• User stories have become large documents
• Kanban doesn’t have any planning
• Kanban allows multi-team ownership of the board whereas Scrum is for one team
• Scrum must have a matrix team with all the discipline within the team.
• Scrum has defined roles, and Kanban relies on existing organisational structure
• And the most prominent and strongest criticism on most scrum teams is that with short sprints they get so focused trying to cram work into a sprint that they don’t focus on finding innovative solutions to the problems they are handed.
What is ScrumBan
Scrumban is basically taking the parts of Kanban and Scrum that help your team become more successful and put them together to form a new process.

Issues before Scrumban implemented this team:

Like most teams, we were doing 2 weeks sprints. We found that two weeks sprint kept the team focused but trying to get everything from a story on an indexed card to working code that is deployed in prod a challenge. We were also trying to make sure our site was completely user-friendly, and every decision was based on research and not our gut feeling.
Work stayed in progress for too long, and progress wasn’t visible:
The Scrum board usually only has three columns, to do, in progress and done. Items stay in the in-progress column a long time, and there wasn’t that much transparency to see what is happening. Scrum usually deals with this issue with team members holding each other accountable during the daily Scrum but as the team grow above 12+ people, trying to pick up hidden problems can get tricky.
There were a lot of work items blocked in the sprint and blocker not visible on the board
We were regularly missing our sprint goals. In most Scrum teams, not completing all the stories in the sprint is normal. However, this can lead to teams having low self-confidence and confidence of the stakeholder in the team getting shattered.
Having a regular flow of stories being designed and user tested before being developed.
Fitting in the full life cycle of the story within a sprint : (Refinement, design, user research, content creation, development, testing, and deployment to prod.) Some Agile/Scrum coaches suggest that Designers and UX people work one sprint ahead of rest of the team, which get slightly tricky in sprint planning because the team is now planning for two sprints. Also with the team working on two sprints, you get disconnection between the team.
New team members come into the team and old ones leave regularly; this has a significant impact on team dynamic and team collaboration.
Larger team size 12+
Having external people who were required to sign off certain items like legal
Keeping a constant follow of stories designed and User tested before moving into sprint

Solution:

Our solution was to keep all the Scrum ceremonies and principles then sprinkle some kanban Principles lightly on top. Our solution was still havely based on Scrum, but Scrumban is very flexible in this sense so that you can create your own unique flavour of Scrumban. We kept the product backlog and the product roadmap to guide us. We kept the retro, review and daily standup.
We made the sprint planning more ad-hoc in the sense that we did sprint planning only when we had less the three items left on the backlog.
Stories would come into ‘to do’ column, then they would be picked up by designers; each design would be user tested.
Three avatars for each team member, (Personal WIP limit for each team member)
Column WIP limit as well.
Physical board
The team was dedicated and cross-functional, and everyone was picking up everything to a certain degree. Designer and UX were doing testing – Developers and tester were doing UX. We wanted to make sure that everyone within the team had exposure and met the end users.
The personal WIP limit insured that no one was picking up multiple items and no one was trying to do multitasking. Generally, straight after the daily standup, the team picked up any testing tasks that were on the board.
The column WIP insured that there were no bottlenecks and everything flow through the smoothly. All stories with external dependencies were highlighted by different colour card and blockers highlighted on the board by having its own column on the board.
By having stories with the external dependency of a different colour made everyone aware that this item is at risk from delays (caused by the 3rd party). These stories need extra care and attention from everyone. We would give earlier dates for the external teams to come back to us then required so that delays they have on their side don’t have a major impact on the team.
We also used the space around the physical board to put up team agreement, policies, DoD, Retro points, etc.

Outcome:

The most significant advantage of this approach was that issues were highlighted well before they would have become a problem. The team had real-time progress visibility on every story in the pipeline. Bring in new team members was a lot smoother and team members on leave didn’t cause a significant impact because the team was cross-functional.
Over time we were able to experiment and refine our WIP limits.
We also were able to run experiments as we were not under too much pressure to do everything with the sprint.
Our sprint planning became shorter as we are bringing in stories more regularly.
The stories are following through more smoothly as both designer and Dev are working closely on the same board.
Everyone knows what is coming up in the next weeks and there is no surprise. Bug and Critical issues can be added to the to-do column at any point, no need to wait for the sprint planning. Generally, the PO can mention the issue at daily standup and bring in new items.
‘To do’ column had a WIP limit as we didn’t want the ‘to do’ column to snowball out of control.

Would Scrumban work for you?

The answer is not a straightforward yes or no. It depends on the firm and the team. Some work so close that this would hinder the collaboration between the team members other would appreciate this. Before jumping into this first check if your current process is working for your team and if it isn’t then what is the underlining cause. Sometime people will jump for something that is new and shining without fully understanding what it is and if it will fix your problems.

Points raised on Scrumban:

If you read the Agile forums, you will found so many negative comments about Scrumban and teams that are doing ScrumBan. Comments like that Scrumban is done by the teams that can not commit to either Kanban or Scrum. Firstly Scrumban has now evolved from its earlier days to become mythology in its own rights. Borrowing ideas from methodology to improve your own process is not a bad thing. Even those team that call themselves pure Scrum or Kanban teams will be borrowing items from Extreme Programming camp. To be in true sprite of Agile manifesto, you should follow whatever process that helps you deliver working software in small increments