For the past 10 years, project management for software development has been moving away from waterfall-style to an Agile approach. Scrum is one commonly used process to implement this, and it comes with its benefits and drawbacks. As a project manager, I look for ways to improve our processes. Recently, on some client projects I’ve been using a process called Scrumban.
But first, what is Scrum?
Scrum is an iterative and prescriptive process for building software using the Agile methodology. A development team plans and commits to completing a certain amount of work in a certain time period called a sprint. At the end of the sprint, the team reviews the work with a product owner. They then hold a retrospective to analyze their processes during the sprint, and determine what can be improved next time.
Scrum can be an effective 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 touch points 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.
One of the primary motivations for moving a team to Scrum is to get away from the often restrictive and inefficient processes of the waterfall model. In this model, there is frequently too much time spent on planning and designing before any work begins. After that, teams find themselves unable to respond to change later in the project as the developing and testing proceeds. All of this is why waterfall is a sub-optimal process for software development.
But look at the makeup of a typical Scrum sprint:
- Team plans the work that will be worked on over the next sprint.
- During planning, teams try to design as many 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.
What does this mean? Scrum is a series of miniature waterfall projects wrapped up into iterations called “Sprints.” This is a push-based system, where another solution would be to use a pull-based one. Enter Scrumban.
What is Scrumban?
Scrumban is a pull-based system, where the team no longer plans out the work that is committed to during the planning meeting, and instead continually 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, not Sprints. With Scrum, the amount of work that is ongoing is limited by the Sprint time commitment. But in Scrumban, with no specific time 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 meetings. These should take place as often as they are 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 meetings. 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 meetings. 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—the group moves through each column and briefly discusses 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 the number of stories and multiply by mean cycle time.
Summary
Scrumban can give teams the power to adapt and change to stakeholder and production needs, without feeling overburdened by their project methodology. It is designed to remove metrics that encourage undesired outcomes. It can restore working time to the team, and avoids unnecessary meetings. And most importantly, it can limit 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.
What processes have you found to increase efficiency with Agile? Let us know in the comments.
Paul Gambill is project manager at Deloitte Digital. He also maintains his own personal blog, where you can find more of his thoughts on project management and productivity.