(If you’re in Seattle, I teach a monthly introductory class on Agile project management that covers Scrumban in detail. You can see the latest upcoming class schedule here: https://generalassemb.ly/instructors/paul-gambill/6046)
Scrumban
Why your teams should move away from Scrum, and how to do it.
What is Scrum?
Scrum is an iterative and prescriptive process for building software in the Agile methodology. A development team will plan and commit to completing a certain amount of work in a timeboxed sprint. At the end of the sprint, the team will review the work with a Product Owner, and then hold a retrospective to analyze their processes during the sprint, and determine what can be improved next time.
Scrum Positives
Scrum can be a fantastic tool for introducing teams to Agile. Its more rigid structure provides a framework of understanding that is far easier to grasp than the loose nature of Kanban might be for teams used to rigidly planned waterfall-style projects.
The daily standup, planning, review, and retrospective meetings are excellent touchpoints for periodic checking in with the work that is happening and reviewing with stakeholders. The retrospective itself is the crown jewel of the Scrum framework, and is what enables teams to focus on continuous improvement, or Kaizen.
The Scrum Master role is unique to the Scrum framework. This person does not participate in the development, and holds a full-time job of working for the team. If any impediments appear and slow down the team from getting their work done, it is the job of the Scrum Master to remove the blocking issues.
Disadvantages of Scrum
One of the primary motivations for moving a team to Scrum is to get away from the restrictive and inefficient processes of the waterfall model. By spending too much time on planning and designing before any work begins, and then being unable to respond to change later in the project as the developing and testing proceeds, waterfall is a sub-optimal process.
But look at the makeup of a typical Scrum sprint:
- Team plans the the work that will be worked on over the next sprint.
- During planning, teams try to design as much of the features as possible, so that they can more accurately estimate what they can complete during the Sprint.
- During the Sprint, the team develops and then tests their user stories.
- At the end of the Sprint, the Product Owner reviews the work completed, and decides which of the stories are shippable and ready for production.
Scrum is just a series of miniature waterfall projects wrapped up into iterations called “Sprints”.
Because of this planning and commitment process, there is an inability within the framework to work with production systems, where teams need to respond to live issues right at that moment. Doing so would interfere with the Sprint commitment and negatively affect the team’s overall velocity.
A final negative point is that oftentimes a Scrum team is dependent on outside teams or vendors in order to deliver their work. This occurs most often when an outside team is responsible for web services, and the Scrum team is responsible for using those services. How is a Scrum team to commit to a story in its Sprint if there is no guarantee that they will even be able to begin it that Sprint? The alternative is to wait for all services and outside work to be delivered before planning and committing to work, but this is often not feasible due to schedule deadlines.
What is Scrumban?
Scrumban is a pull-based system, as opposed to the push nature of Scrum. The team no longer plans out the work that is committed to during the planning meeting, and instead grooms the backlog. The same Scrum meetings (planning, review, and retrospective) can and should still take place, but the cadence of them can be more context-driven. The real key to moving to Scrumban, though, is ensuring that work in progress (WIP) is still limited.
Work In Progress Limits
With Scrum, the amount of work that is ongoing is limited by the Sprint commitment itself. But in Scrumban, with no ongoing commitment, the team must limit itself through the use of WIP limits on columns within their task board. The goal is always to move tickets in a flow from left to right on the board. If too many issues are in progress, the team is at risk of not finishing anything to high quality standards. Instead, there should be a maximum number of tickets allowed per column. If the number of tickets in that column ever exceeds the maximum, the entire team should swarm onto that column and help move tickets on. This should happen no matter what functional role a team member fills.
Planning Meeting
Should take place as often as is needed. When the team is unable to regularly pull stories off the top of the backlog at their normal pace, a planning meeting is necessary.
Review Meeting
Reviewing work with clients and customers is the only way that development teams can get the feedback necessary to properly adapt what they are working on. Clients tend to prefer that these are held at a regular cadence.
Retrospective Meeting
These can vary when held, but a general rule of thumb is to hold a retrospective after every review. This is the most useful part of the Agile process, and should be given the proper place for that.
Standup Meetings
Standup meetings in the Scrum world follow a simple pattern. The team takes 15 minutes and each person says, a) what he/she did yesterday, b) what he/she is working on today, and c) what is blocking any of that work.
In practice, this boils down to redundant statuses that recount information available on the team’s task board.
For Scrumban, a more effective method is to refocus on the flow of tickets on the board. That same pattern of yesterday/today/blocked can be transferred to the tickets themselves. Move through each column and briefly discuss each ticket and what is necessary to move that ticket rightward on the board. This provides far more context to the team, and informs everyone of any major architectural or design decisions.
Metrics
Metrics can certainly be useful, but they are often abused by managers and business stakeholders who want to unnaturally simplify a complex process into a one-dimensional number. Velocity, the amount of story points a Scrum team completes in a single Sprint, is such a metric that incentivizes lower quality at the end of a Sprint as a team scrambles to finish every last story they committed to. When the number fluctuates, as is common with a newer team, the stakeholders begin to question the outputs of the team, and even the effectiveness of Agile itself.
Instead of velocity, a useful Scrumban metric is cycle time. This is the length of time a ticket takes to complete, measured from when it is first began. Over time, a statistical analysis of all tickets in the project can yield a mean cycle time and standard deviation. This can be a useful planning tool at a macro level, as it is trivial to add up number of stories and divide by mean cycle time.
Summary
Scrumban gives teams the power to adapt and change to stakeholder and production needs, without feeling overburdened by their project methodology. It removes metrics that encourage undesired outcomes. It restores working time to the team, and avoids unnecessary meetings. And most importantly, it limits the team’s work in progress so that they can finish what they start to a high standard. Scrumban can remove overhead stress for the development team, increase efficiency, and increase the overall satisfaction for the customer.
Have you tried Scrumban with your teams? What was your experience? Share your thoughts with me at @paulgambill or here in the comments.
If you liked this article, won’t you please Recommend it below?
