DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
11 Monitoring and Observability Tools for 2023
Learn more
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. What Scrum Gets Wrong About Kanban and Vice Versa

What Scrum Gets Wrong About Kanban and Vice Versa

Myths about both Scrum and Kanban have led many to believe they have to choose between the two. By dispelling these myths, I hope we can move on to greater collaboration.

Steve Porter user avatar by
Steve Porter
·
Dec. 15, 17 · Opinion
Like (2)
Save
Tweet
Share
8.30K Views

Join the DZone community and get the full member experience.

Join For Free

From the two previous posts in this series, A Scrum Primer for Kanban Teams and A Kanban Primer for Scrum Teams, you can see that Kanban and Scrum are very compatible. If that's the case, why do so many people say that one is better than the other?

My hypothesis is that the disconnect comes from the many myths that persist about the two approaches. If we examine and debunk these myths once and for all, perhaps it will finally allow people to embrace their compatibility.

MYTH: Scrum Is Revolutionary; Kanban Is Evolutionary

No doubt that introducing the Scrum framework into an environment is likely to shake things up considerably. I've heard some suggest that introducing Kanban just encourages existing behaviors (i.e., that it reinforces Waterfall). Not true. As Daniel Vacanti explained to me, "The concept of limiting work in progress is revolutionary in most organizations." As soon as an organization starts visualizing its work, limiting work in progress, and actively managing flow, it disrupts the existing order. It has a similar disruptive effect as the concept of potentially releasable product increments every month (or less) in organizations that start using Scrum.

MYTH: Scrum Is for____ and Kanban Is for____ (or Kanban Is All About Manufacturing)

Although Kanban derived many of its lean concepts from the manufacturing sector, they apply equally as well to complex knowledge work. There is nothing inherent in the five Kanban practices that make it incompatible. Visualizing work, limiting work in progress (WIP), actively managing flow, improving collaboratively, and making policies explicit inevitably enhance a team's ability to solve complex problems.

MYTH: Kanban Doesn't Encourage Teamwork

Many Scrum practitioners see Kanban's visualized workflow with columns that represent specialized skills as a sign that it encourages working in silos using handoffs. What they are missing is Kanban's key practice of actively managing flow. No doubt, if done incorrectly, you can have a Kanban process that focuses on individuals completing their tasks and handing them off to the next cog in the machine. However, if you're truly managing your flow, you will see where the bottlenecks are. The way to alleviate those bottlenecks is to manage the flow of work across the entire value stream. Who manages that flow? It is the people closest to the work---the people in the value stream (AKA a team). Combine actively managing flow with the practice of improving collaboratively, and you naturally end up with cross-functional, self-organizing teams of people working together to deliver value.

Yuval Yeret adds that Kanban teams should avoid naming their columns based on the team structure or role. Instead, they should focus on the activity/action/work that's being performed. This along with WIP limits encourages individuals to swarm to complete the activity.

MYTH: Scrum's Sprint Planning Event Is a Time Waste

Teams that embrace Kanban often decide to ditch Scrum's Sprint Planning meeting and instead replace it with just-in-time feature planning. They'll ask, "What's the point of planning out all of the work for the next two weeks?" What these teams are missing is that the intent of the Sprint Planning meeting isn't to create a detailed Sprint plan, but to instead come together as a team to decide what goal to achieve and to come up with a plan to complete that goal. The details of that plan need not include an exhaustive list of work, and it does not need to consume all of your capacity. You're expected to leave room for uncertainty.

MYTH: Sprints Constrain Flow

This idea usually stems from two misunderstandings about Scrum. The first is that you can only release to production at the end of the Sprint. This myth became so entrenched that it was addressed in the latest Scrum Guide by explicitly pointing out that Scrum is routinely used in environments where products and enhancements are released many times per day.

The second misunderstanding is that a Development Team can only work on items specified in Sprint Planning. Nothing in the Scrum Guide stops a team from embarking on new work mid-Sprint as long as it meets two conditions. The first is that the work doesn't endanger the Sprint Goal. The Development Team is still committed to its delivery. The second is that the team will have a potentially releasable product Increment for the Sprint Review. This means that either the new work will be "Done" by the end of the Sprint or that working on it won't restrict the team from having a potentially releasable Increment at the end of that Sprint.

Ready to Move On?

Throughout this series examining how the practices of Scrum and Kanban can complement each other, we've made the case that using the two together has the potential to achieve better results for teams. Outdated misunderstandings and persistent myths about both Scrum and Kanban have led many practitioners to believe they have to choose between the two. By dispelling the misconceptions, I'm hopeful we can move on to greater collaboration.

Ta.
Steve Porter

scrum Kanban (development) Sprint (software development) Flow (web browser)

Published at DZone with permission of Steve Porter, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • 10 Easy Steps To Start Using Git and GitHub
  • Little's Law and Lots of Kubernetes
  • Using GPT-3 in Our Applications
  • How To Build an Effective CI/CD Pipeline

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: