No two products are the same. Then why do so many software teams hop on the kanban and scrum wagon? When done right, organizations report a number of positive benefits when they work under one—or a combination of—these development frameworks. When done wrong, a failed implementation inspires people to write impassioned blog posts about how and why these methodologies are the wrong way to build software.
Methodologies aren’t a silver bullet that’ll automatically solve all the dysfunctions, wasteful practices and flaws of a product development process. Why? For starters, there’s the compatibility issue. Certain methodologies work better in some organizations, while others don’t.
Leadership and management need to assess the cultural ecosystem the product exists in before making any massive internal process transformations. And yet, so many companies fail at laying those essential foundations.
One way to prepare for structural change in the product development and delivery process is by becoming aware of the common issues that can arise with implementing scrum, kanban or a hybrid that borrows elements from each.
By foreseeing the potential problems that may arise, an organization can assess if one of these methodologies is right for them. Being aware of—and planning for—possible pitfalls and issues also creates an environment where teams feel prepared to tackle whatever may come.
For product managers, and any product leaders guiding a software development team, here’s what you need to know about scrum, kanban and scrumban before settling for one methodology.
Why is kanban so popular?
Kanban is just one of many frameworks used for implementing agile and lean principles. The ideal outcome under kanban is to facilitate the communication of capacity and to encourage transparency of the work being done using a kanban board. When used right, kanban boards help teams improve flow, limit the work in progress and maximize efficiency.
There’s a lot of information (and misinformation) out there on what kanban is and isn’t. For starters, it’s not a strict methodology and it can be adjusted according to the specific requirements of a team. Kanban doesn’t prescribe roles and it doesn’t have time restrictions for the work in progress (unlike scrum).
When kanban is implemented the right way, the benefits include:
- The work becomes visible. It establishes an accurate visualization of the development workflow. This allows teams to see where the bottlenecks and delays live, which they can then fix.
- Better accountability and communication. It gives everyone an equal understanding of who’s working on what, and what the status of any given initiative is.
- Teams work within their capacity. The focus on limiting the work in progress using a pull system prevents teams from being overwhelmed with work
- Value is built and delivered much faster. This is done by improving the speed and efficiency of the workflow.
These also happen to be some of the things that motivate organizations to make the switch to kanban. Some of the other benefits reported by organizations that successfully implemented kanban include an increase in customer satisfaction, improvement of the quality of the software, shortened time to market and reduced overall cost of development.
Kanban has the potential to solve the workflow management headaches that product teams typically deal with. It can create a centralized work stream that combines the work from multiple departments and sources.
How to implement kanban successfully
Implementing kanban comes with a lot of challenges and pitfalls that organizations need to prepare for. In this section, we go over a couple of the worst offenders that hinder the process of successfully implementing kanban within a product team, as well as some proposed solutions.
Kanban challenge: Kanban isn’t a complete change management framework
Solution: Have an end-to-end implementation strategy and framework management plan (with metrics!)
For any development framework, there should always be a champion. A kanban champion doesn’t necessarily have to be the product manager, but it helps the methodology stick in the long-term when product managers are on the lookout for ways the process can be improved.
Product managers work in the trenches of product development—they work closely with every department that makes up the product team, and one of their goals is to improve the ideation-to-delivery process. When a product manager becomes a kanban educator or guide, it adds another level of accountability to the process.
Kanban isn’t a comprehensive or complete change management platform, so management has to fill in the blanks of what’s missing. Product managers can create a battle plan for the implementation and optimization of kanban practices by creating a strategy complete with a set of metrics designed to measure the success of the implementation of the process.
Kanban metrics for product teams
Delivery time metrics: Cycle time, lead time
Lead time: The time period between the appearance of a task in your workflow until its departure from the system. It’s the time it takes an idea to become a finished feature.
Cycle time: This metric measures the time it takes for a task to go through individual parts of the process like testing and development.
Use a lead and cycle time chart to visualize the progress of these metrics. This chart lets you step back and spot where the bottlenecks are, as well as how quickly and efficiently any given initiative makes it through the system.
Performance metrics: Throughput, work in progress
- Throughput is the number of initiatives, tasks, features, bugs and updates that are delivered and finished in a given period of time. It can be weeks, months, or quarters depending on the organization
- Work in progress is any work that’s being worked and hasn’t yet delivered any value to the users. Tracking this metric allows you to see how many initiatives are in progress and what the capacity of the team is
Use a cumulative flow diagram (CFD) to visualize all of these metrics. To get started, count and categorize the number of initiatives in each section of the board. Then, gather the data in a table. This information will be plotted in a diagram where the vertical axis represents the number of tasks, and the horizontal axis is the timeframe.
Kanban challenge: Kanban is dull and repetitive, so teams have a hard time staying motivated
Solution: Use ceremonies as you see fit, encourage team collaboration and participation
Kanban doesn’t prescribe much in terms of process. Because of how simple it is, it can be easy to fall into a cadence of repetition and boredom. Teams just go through the motions of moving cards on the kanban board every day, feeling the pressure to deliver quickly during each cycle.
There’s no reason why teams should be limited to the kanban basics. Just because kanban doesn’t prescribe any iterations, reviews, demonstrations and retrospectives, it doesn’t mean they shouldn’t exist. The cadence of these ceremonies doesn’t have to be strictly tied to the workflow of the kanban board. These practices can happen any time the team feels they are needed, as long as they happen meaningfully.
This leads to the idea of encouraging team collaboration and participation. Facilitating the communication channels and meetings for individual team members to discuss their process and workflow results in a few things. First, teams feel empowered to solve the problems that emerge from visualizing the work.
Second, kanban isn’t about management dictating an amount of work to be completed by a certain timeframe. It’s about stepping back and observing the current process, identifying where it can be improved, and allowing teams to “own” the process by generating their own solutions while keeping their eyes on the prize (the prize being organizational improvement).
Scrum, on the other hand, is a bit more prescriptive and heavy on the required elements needed to achieve results.
Why is scrum so popular?
Scrum is another agile development framework that promises an effective system for organizing work and delivering results. Ideally, and when done right, scrum can improve feedback loops and internal communication, create more efficient teamwork, and get the results to reach users more quickly.
Scrum is made up of a set of roles, artifacts and ceremonies that work together to create an environment within a product team where these ideal results can happen. The roles are the product owner, the development team and the scrum master. The artifacts are the product backlog, the spring backlog and increments. The ceremonies are sprint planning, sprint review and sprint retrospectives.
Part of the appeal of scrum goes beyond the potential improvements, but also the fact that anyone can implement it. Scrum doesn’t require any technical training or qualifications, only an understanding of those roles, artifacts and ceremonies and a good implementation strategy that includes an action plan for any potential pitfalls and challenges that may arise.
When done right, teams that implement scrum have the potential to achieve a few things:
- Faster speed to market. Scrum is a way to achieve the incremental delivery that the agile approach promises using regular small releases.
- Reduced risk. Delivering early prototypes within short iterations allows teams to “fail early” and learn lessons they can immediately apply to the development of the product before it’s shipped.
- Transparency and visibility. Scrum ceremonies allow teams to identify roadblocks, what’s working, what’s not working. They also facilitate an environment where teams work together to figure out solutions and ways to improve or remove the bottlenecks and delays.
- Higher user satisfaction. Scrum teams are committed to helping users. They do this by involving users early and often in the testing phase, and responding quickly to changes in the industry and modifying the backlog accordingly
How to implement scrum successfully
Because scrum is much more process-intensive than kanban, it’s important that product teams answer a few questions before implementing it:
- What are the outcomes that matter to our organization? What will success look like a quarter, six months, a year from now?
- Is the culture of the organization capable of evolving from siloed departments to collaborative, cross-functional teams? Is the company able to change?
- Is our main goal to bring more tangible value to the user?
- What are some implementation challenges we might come across, and how can we prepare for them?
As for that last question, here are some common challenges and pitfalls that arise when implementing scrum.
Scrum challenge: Resistance to change
Solution: Create a strategy that outlines the steps to achieve that change and execute it
Resistance to change can occur for reasons like lack of understanding in how scrum works and a refusal to change habits that have worked for a long time.
Addressing resistance to change comes in a set of sequential steps that create a roadmap to success:
- Communicate the reason for the change. If the goal is to increase user satisfaction, show how scrum will do that at your organization. Demonstrate how the proposed changes are connected to delivering this new and improved user value. If the goal is to improve the development process, gather the necessary evidence that shows a change is needed to improve performance
- Educate the team. Make sure everyone involved understands and agrees on the definitions of the artifacts, roles and ceremonies. Set the standards from the beginning and provide the training, tools and time for teams to get the hang of scrum
- Set a scrum vision. Describe what the ideal outcome under scrum will be and create relevant OKRs to implement it. This also involves communicating the vision wiki pages, one on ones and learning sessions (lunch and learns, ask me anythings)
- Make the team feel heard. Do this by incorporating their feedback into the process and addressing their concerns. When team members feel that they’re actively involved in the process changes, they’re more likely to be more invested and active in achieving the vision.
- Measure, document and celebrate the things that work. Like with the OKRs for the scrum vision, you should have metrics in place that tell you how you’re making progress internally. Highlight when and how these metrics moved in the right direction, and broadcast a collective understanding of why these efforts worked
Addressing all of those components also helps address other scrum pitfalls like lack of understanding of the methodology, a sense of lack of autonomy, misalignment on the goals and the why behind a change in process, lack of short-term wins, and poor documentation of the processes that are successful so that they can be replicated in the future.
The difference between scrum and kanban
For starters, let’s go over the similarities between these two agile methodologies:
- They’re both adaptable and flexible. They can be used in a wide variety of industries, types and sizes of companies.
- They both limit the work in progress for the same reason: to improve the flow of the work and increase user satisfaction. Kanban does this using WIP limits, and scrum does this by measuring velocity and number of tasks per sprint
- They both encourage visualization of the work, the internal goals, and the progress.
- They’re empirical, experimental processes that aim to better understand users and solve their problems
- They encourage teams to become self-sufficient and autonomous. Management isn’t dictating the tasks.
In terms of the differences, they can be boiled down to the fact that scrum is an all-round, end-to-end model for building a product and optimizing the way teams work. Kanban, on the other hand, doesn’t demand massive organizational changes, only small and incremental improvements to the current process in place.
When you see the aspects of scrum that are undefined, but which are defined in kanban, it’s easy to see how a marriage between these two agile methodologies makes sense. For example, there’s no “board” in scrum for visualizing the work, so it’s possible for teams to include a kanban board with progress columns.
These methodologies are flexible, and allow teams to choose how they’ll make it work for their individual use case. One way to do this is by using a method called scrumban.
Scrumban: a marriage between Scrum and Kanban
Scrumban is ideal for teams that like the structure that scrum provides, but who also like the flow of kanban and its focus on continuous improvement methods.
Scrumban practices
Because of the added flexibility that comes with using elements from both scrum and kanban, there are many different versions of what scrumban ideally looks like.
The elements of scrum and kanban that are kept in scrumban include:
- A scrumban board. In kanban, the board is usually split into “to do”, “work in progress” and “done”. In a scrumban board, more columns can be added to specify more phases in the development process. Usually, these extra columns go at the beginning at the To Do phase, to add visibility to into the user stories and the backlog
- Self-managing and self-organizing teams.
- Continuous workflow over iterations
- On-demand planning and daily meetings over sprint planning and retrospectives
- The metrics of scrumban are lead time and cycle time
Who should consider scrumban?
- Scrum teams who have a hard time completing the amount of work prescribed for a sprint. Kanban’s WIP limits allow teams to prioritize ruthlessly when it’s time to pick what initiatives to work on.
- User stories and priorities are always changing, which requires sprints to have some flexibility in the work to be done
- Organizations looking to step down from scrum and implement kanban instead. Scrumban originated as a transitional methodology for teams looking to break away from scrum.