PEARL XVI : Scrumban is a combination between Scrum and Kanban methodologies for increased applicability and versatility tool for software production and support focused companies.
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.
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.
Scrumban combines the best features of both methods. It compounds the prescriptive nature of Scrum and the process improvement of Kanban, allowing teams to become Agile and to continually improve their process. Scrumban is becoming especially popular in services industries, where project development and maintenance goes together.
Scrumban is a process for evolving a Scrum instance to be more Lean oriented, supplemented with core Kanban practices such as: visualization, work-in-process limits, work flow management, and making policies explicit. The basic Scrumban implementation principles include:
- Start with all the ceremonies, artifacts and roles you use now.
- Agree to pursue improvement towards a more effective process.
- Respect current roles, responsibilities and job titles.
Scrum-ban is a software production model based on Scrum and Kanban. Scrum-ban is especially suited for maintenance projects or (system) projects with frequent and unexpected work items or programming errors. In such cases the time-limited sprints of the Scrum model are of no appreciable use, but Scrum’s daily meetings and other practices can be applied, depending on the team and the situation at hand. Visualization of the work stages and limitations for simultaneous unfinished work and defects are familiar from the Kanban model. Using these methods, the team’s workflow is directed in a way that allows for minimum completion time for each work item or programming error, and on the other hand ensures each team member is constantly employed.
To illustrate each stage of work, teams working in the same space often use post-it notes or a large whiteboard. In the case of decentralized teams, stage-illustration software such as Assembla, ScrumWorks, TargetProcess, Rational Team Concert, Eylean board, OnTime, Kanban Tool or JIRA in combination with Jira Agile can be used to visualize each team’s product backlog items, defects and tasks divided into separate phases.
In their simplest, the tasks are categorized into the work stages:
- Unstarted
- Ongoing
- Completed
If desired, though, the teams can add more stages of work (such as “defined”, “designed”, “tested” or “delivered”). These additional phases can be of assistance if a certain part of the work becomes a bottleneck and the limiting values of the unfinished work cannot be raised. A more specific task division also makes it possible for employees to specialize in a certain phase of work.
There are no set limiting values for unfinished work. Instead, each team has to define them individually by trial and error; a value too small results in workers standing idle for lack of work, whereas values too high tend to accumulate large amounts of unfinished work, which in turn hinders completion times. A rule of thumb worth bearing in mind is that no team member should have more than two simultaneous selected tasks, and that on the other hand not all team members should have two tasks simultaneously.
The major differences between Scrum and Kanban are derived from the fact that, in Scrum, work is divided into sprints that last a certain amount of time, whereas in Kanban the workflow is continuous. This is visible in work stage tables, which in Scrum are emptied after each sprint. In Kanban all tasks are marked on the same table. Scrum focuses on teams with multifaceted know-how, whereas Kanban makes specialized, functional teams possible.
In Kanban, Workitems deemed high priority and needed as soon as possible have a way of being addressed ahead of current work. Periodic reviews of process, tools, team performance, and
WIP limits to find improvements and eliminate inefficiencies or waste.
When to use Scrumban?
Are you considering implementing Scrumban in your team or business? You should take it into account if you are doing one of these:
- Projects maintenance,
- Event-driven work (support, hardening),
- Problematic projects management (projects with unexpected user stories and bugs),
- New product development (work preceding sprint development or following sprint development),
- Continuous management improvement.
Scrumban board gives an easy view of process workflow. It informs about the number of items the team is currently working on as well as already finished ones. It influences the improvement of accountability, responsibility, communication and performance results.
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.
Key Scrumban Terms
• Work Backlog – Equivalent to Scrum’s Product Backlog with minor differences for how Workitems are tracked.
• Workitem– The individual descriptions of functionality needed by the business that either define enhancements or defects.
• Workline – The series of stages in the software development process that pull work from the Work Backlog and produce shippable business value.
• Stages – The common and discrete steps required to deliver software within an organization.
The Weekly Timeblock (WTB)
The Weekly Timeblock is a reoccurring meeting used for multiple purposes. It should be set up in the middle of the week (Wednesday are best) so as to avoid holidays and vacation days that typically occur at the beginning and end of each workweek.
Two to four hours is recommended and set to occur in the afternoon so any preparation work can be completed ahead of time. The team will use the time they need and leave the rest. Having a projector, screen, and ample whiteboard space will be conducive for any technical discussions and problem solving.
The first use of the Weekly Timeblock is for demonstrating any completed work. This is the time where Developers can show the Product Owner what was completed and get Acceptance. Completed work can be demonstrated outside of the meeting anytime but it is good for the team to have every one witness the conclusion of work.
Once Workitems have been demonstrated, the team should reflect on how their development process is going, any tools they use, and review the data on how Workitems are flowing through the Workline. They should have frank discussions about any new innovation that should be reinforced or impediments to be overcome. Clear action items and their owners should be identified along with a target resolution date.
After the review of recent activity, the team should have a preview of upcoming Workitems the Product Owner is preparing. The Developers should seek to understand the intent of each item, asking questions and getting clarity so everyone is familiar with what’s needed. The Developers should also provide feedback on Workitem scope, structure, and the optimal execution order so the Product Owner can make any needed adjustments to content and priority.
Standup meetings. The Daily Standup meeting is a concept borrowed from Scrum and serves the same purpose; to coordinate activities and identify impediments. A daily reoccurring meeting should be set up for 30 minutes where the first half is focused on the team members updating everyone on what they did since the last meeting, what they intend to do before the next meeting, and any impediments that are blocking, or threaten to block progress on their work. The second half is for any impromptu discussions necessary to address questions or plan activities. The meeting should be held near the Board so discussions focus around work in progress and updates can be made publically. Ideally the meeting should occur early in the day, just after everyone has had a chance to get to work, reorient themselves, and think about what they’ll focus on.
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.
The Work Backlog under Scrumban is basically the same as with Scrum. It is a collection of User Stories and Acceptance Criteria written and maintained by the Product Owner. These individual Workitems describe the business value desired.
To keep the collection organized, additional information is associated with each item:
• ID–A unique identifier (e.g. B#042) for easy searches and reference.
• Project –A label to group a set of work items together according to a theme or purpose.
• Title –A concise, action-oriented description of the business value desired.
• User Story –A formulaic description of who will benefit from the item, what exactly is wanted, and why it is wanted. The User Story provides the context behind the request and enables the Developers to understand the goal, and not just take orders.
• Acceptance Criteria –A list of the specific conditions required for the Workitem to be considered complete.
• Status –An indicator of the readiness of the Workitem, when it is being worked on, and the final disposition.
When the progress of a Work item through the Workline is blocked
As a team is working on items, it will be fairly common that progress from one stage to another is blocked. These blockages can be internalto the team where the work was more challenging than expected. Whatever the cause the team should “swarm” to help wherever possible to remove the blockage. All team members can assist to one degree or another, even crossing the traditional role boundaries of Coders & Testers to help test, code, prepare environments, research or write documentation.
When a blocking issue is external to the team, such as when a required server hasn’t yet been delivered or subject matter experts are needed for questions, the Scrum Master should attempt to resolve it. The rest of the team can be engaged as needed to help with external issues.
If a Workitem is blocked completely with no resolution in sight, it should be pulled from the Workline and its status changed from ‘In Progress’ to ‘New’ or ‘Draft’ depending on what is needed before the team can pull it back into the Workline again.
Workitem needs to be completed as soon as possible
There are two ways to address this need. First, the Product Owner should be continually maintaining the order of the Work Backlog such that the items the business considers the most valuable are at or near the top. It is these top items that the team reviews and makes ‘Ready’ through discussions and feedback and are pulled into the Workline as capacity opens up.
If there a more urgent need for a work item to be completed than what the standard process provides, the item’s priority can be changed to expedited and be fast-tracked through to completion.
Defects in Scrumban
Defects are a natural part of any software development effort and dealing with them is straightforward. When defects associated with current Workitems are found they should be addressed before the item is considered complete and ready for demonstration.
Assuming the defect was found during the Testing stage and it is relatively minor, then the item can stay within the Testing stage as the Coder works closely with the Testing to diagnose the issue and provide updated code.
If the diagnosing and fixing effort is much larger however, such as requiring more than a day to complete, then the Workitem should move back to the Coding stage even if the WIP limits are exceeded. The priority for the Coder should be to address the defect and get the Workline flowing again in the right direction.
Sometimes defects are found in areas of the code not currently part of a Workitem in progress. These should be brought to the attention of the Product Owner who can create a new Workitem representing the defect and prioritize it accordingly in the Work Backlog.
Estimation
The statistics kept on how long Workitems take to transit the Workline should be enough to estimate how long any particular item will take to be completed. For example, if the average number of days is four, then any new item pulled into the Workline is likely to take four days. By the same logic, if there was a set of Workitems that comprised a release, then the time to complete the entire set is four times the number of items in the set
This estimation technique works well when the scopes of the Workitems are somewhat consistent. When they are not, some rough estimates of size, combined with the transit time for those specific sizes can produce a more accurate estimate although it will take longer to gather enough data to be confident with the results.Be mindful that any additional time spent by the team should be worth the effort and if not, abandoned for the simple statistics Kanban provides.
Pearls of Wisdom 