This article is the fourth in a series of “Kanban and Scrum – Stronger Together”.
Inspired by Steve Porter’s efforts to bring process practitioners closer together and educate Scrum practitioners, I’m writing a shadow series of posts that will follow the Kanban and Scrum – Stronger Together series and continue my own efforts to clear up misconceptions between practitioners of these methods.
In the most recent post in Steve Porter’s series, Yuval Yuret presents Scrum in a manner that is intended to educate Kanban teams.
Disclaimer
First off, I have to say that I’m not 100% certain how I feel about Yuval’s blog post. It feels like a forced comparison of apples and oranges. But in critically reading it, it forces me to think about why I feel that way. And as always, these are all just my opinions. No harm in sharing them, right?
TL;DR
In case you haven’t read Yuval’s post, basically, it presents a map of values and practices in Scrum to Kanban language, and encourages Kanban teams to approach Scrum from a practices point of view. It also encourages everyone to review/adopt the values (in Scrum language) that can help software development teams succeed in building software. You should go read it now. 😀
Values
As I wrote in 2013, Scrum and Kanban both share a use of values to encourage users of the methods to behave a certain way. The explicit inclusion of the Scrum Values is a relatively recent (2016 Scrum Guide) addition, but the Agile Manifesto is definitely a value system and Scrum fully supports those values.
The Kanban Method also has principles that have been included since its formation. The presentation of these principles have been refined and one addition was made for clarity. And recently, a significant amount of work has been made to further evolve our understanding of the principles and turn them into a description of more concrete values. Andy Carmichael and David J Anderson have created a free Essential Kanban Condensed eBook that lays out the value system for the Kanban Method on Page 3, and Mike Burrows has written a fantastic book Kanban from the Inside that discusses the values of Kanban in great detail.
I think it is great that Yuval is including the values mappings in his primer, but I think that some of the mappings he has created reinforce my apples and oranges feelings. He doesn’t compare the current state of the art in Kanban values and maps some kanban practices to Scrum values.
I would encourage you to quickly read the values section (3 minutes) of the Essential Kanban Condensed eBook starting on Page 3 and judge for yourself how the values comparison feels to you.
And, as hard as this is to say because I think the values are important, the Scrum guide seems to specify an intent as opposed to a way to think. Values shouldn’t be expressed as goals like they are in the Scrum Guide. And maybe that isn’t how Scrum is taught. I haven’t been to a modern PSM class.
Roles
I’m glad that Yuval presents the Scrum roles. The Kanban Method neither advocates nor condemns any of these roles. It really has no opinion. The Kanban community has discovered that there are specialists who are good at fulfilling useful services when optimizing virtual kanban systems and participating in Kanban implementations. A Service Request Manager is focused on the needs and expectations of the customer. This is comparable to a Product Owner. A Service Delivery Manager is focused on kanban system performance. A Kanban Coach is focused on organizational adoption.
To be clear, the Kanban Method has no opinion about roles. It guides people to respect everything until you’ve gained the emotional maturity as an organization to change. The Kanban community has discovered, in practice, that there are roles and responsibilities that should be encouraged to appear and supported as organizations progress down the Kanban path.
Events
This is probably the set of things that, regardless of the name, Scrum and Kanban teams will have the most in common. Kanban teams are fully capable of doing everything that Scrum teams do, described as some sort of feedback meetings that happen on a cadence. People on software development teams, regardless of Scrum or Kanban, will goal set, seek feedback, deliver increments of product, and reflect on how they work. If you are a team that is not performing this practices in some form, you should look at either Scrum or Kanban.
One of the things that are spiritually very different about the Scrum events (as described in the Scrum Guide) and the Kanban feedback meetings is usually that the Scrum events are focusing on what people do during the meeting. Kanban feedback guidance focuses on the work that needs to be done.
An example of this is the description of the daily stand-up. In the Scrum guide, this is the following description of the daily scrum:
During the meeting, the Development Team members explain:
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
In the Kanban community, we have The Kanban Meeting, a daily ‘stand-up’ style meeting whose focus is work items. You can find a brief description of this meeting on page 25 of Essential Kanban Condensed. And Yuval also makes this point in his mapping. Kanban teams typically focus on the flow of work instead of the people doing the work. They work the board right to left focusing on flow problems.
I will state that being prescriptive of what people should do is not necessarily a bad thing. That is one of the things that Kanban has suffered within that people want prescriptive guidance and in the past, the Kanban community didn’t an authoritative source of concrete practices. That has changed dramatically in the last couple years with many initiatives within the Kanban community providing kanban practitioners with examples of concrete practices that could be used prescriptively. Essential Kanban Condensed provides specific examples. Enterprise Services Planning or ESP as it is commonly referred to as in the Kanban community is full of specific activities that large organizations adopting Kanban at scale will benefit from implementing and understanding.
Artifacts
Generally speaking, Yuval hits this point right on the head. Software development teams, striving to be agile, using Scrum or Kanban, will generally need/produce the same things. They need PBIs/User Stories/Work Items to describe demand. They will produce Features/Functions/Components that are cohesive. They will ship increments of software on a cadence or on demand.
Yuval suggested that Kanban teams limit the size of a product backlog, which may be true in some cases, but this guidance is not from The Kanban Method. Nowadays, Kanban teams may have an Upstream Kanban System that is full of work items that are being refined, analyzed, discarded, or finally passed on to the development team as a User Story/PBI that needs to be delivered. Smaller teams can do this within their own kanban system.
Slide 13 in Patrick Steyaert’s LKCE2016 presentation shows a good example of the guidance practicing Kanban teams are sharing in the community.
Conclusions
I think Yuval’s options in his conclusion are all viable experiments to try! Kanban teams should never be afraid to take practices from anywhere that they see them. Arguably, kanban actively promotes the constant experimentation of practices to see if they improve the delivery capability of an organization or team.
My Final Thoughts
While I may disagree with some of the details as outlined in this post, I agree with the spirit of what Yuval is suggesting in his article. Kanban teams need to be open-minded when looking for practices that may enhance the way that they work. They should not be afraid to look at Scrum as a source of those activities. And I sincerely hope that everyone came away more educated about Scrum AND Kanban having read these articles.
By this point in the series, I hope that I’ve encouraged you to learn more about Kanban. And the best place to learn more is a certified training class from a LeanKanban.com Accredited Kanban Trainer. You can find more about the recommended first class, Kanban System Design, here.
Read the previous blog posts by Dave on Scrum and Kanban –
