In February this year, Scrum.org published the Kanban Guide for Scrum Teams and announced a new course - Scrum with Kanban Course, aimed at Scrum practitioners who wish to improve their processes by introducing certain Kanban concepts and elements.
Through mad luck, we were able to set up a Q&A with none other than Dave West, CEO and Product Owner at Scrum.org (a huge thanks to Lindsay Velecina for making this possible) and get extraordinary insights into the ideas behind The Guide.
However, before we move on to the interview itself, allow us to share a few resources you might want to check beforehand in case this is the first time you are hearing about this idea and the Guide.
It all started with an article by Steve Porter - Scrum and Kanban stronger together from May 2017 (here). The article introduced the idea of building the bridge between Scrum and Kanban and the future collaboration with Daniel Vacanti, a 20-plus year software industry veteran who helped develop Kanban and managed the first project implementation of the method.
Later that year, Yuval Yeret, Mr Kanban Israel and head of AgileSparks USA, came on board to share the Kanban camp’s point of view in two articles - A Scrum primer for Kanban teams (here) and A Kanban primer for Scrum teams (here), further exploring the many similarities between Scrum and Kanban.
Mr Porter and Mr Vacanti also did a webcast (here) where they busted the most common myths surrounding Scrum and Kanban. In November, Mr Porter also investigated what Scrum gets wrong about Kanban and vice versa (here).
In February 2018, Scrum.org made available their Kanban guide for Scrum Teams, as well as introduced the Scrum with Kanban Course. Both Mr West and Mr Porter gave their comments on the course (here and here), with Mr Porter also giving an interview for Agile.FM (here). Mr Yeret also shared his comments in a blog post (here).
And now, join us for additional insights into the ideas behind this new concept and more. Enjoy!
Q: In your opinion, why did it take this long for something like this to happen? Was it a matter of priorities, two heavily polarized camps, or something else?
A: I have experienced many good ideas where I ask, ‘Why were we not doing this?’ When practicing Scrum, of course you look to add practices to help you improve. Because Scrum is based on transparency, it seems obvious that you would look to Kanban to help provide better ways to visualize work.
The bottom line is, it doesn’t matter why this took too long, but it does matter that we are doing it now. I am very excited about how we bridge these two worlds, while pursuing our mission to ‘improve the profession of software development/delivery.’
Q: Is it safe to say that Kanban’s mechanisms of gaining insight into and controlling the workflow are the most important addition to the Scrum framework here?
A: Visualizing work allows the team to work more effectively. When you start applying Kanban, not just a board, you start realizing that you need to think much more about some of the things that Scrum includes. For example, Definition of Done – should it include steps outside of your team? What should be the boundary of your work? You also need to consider the Sprint Goal and how by visualizing work in that context, you can gain better focus. Also, ensuring that ideas such as clearing the board, which are often very important for Scrum Teams, are thought about.
But remember, WE ARE NOT extending the Scrum framework. What we are doing is showing how teams can use Scrum with Kanban in their context. Scrum is NOT a methodology and we have always highlighted that you need to add practices to create a process for your context.
What we are showing in this work is how Kanban can be applied.
Q: What level of familiarity with Kanban will be required from the Product Owner and the Development Team? Is there a danger of slowing down the adoption and learning process of the already demanding Scrum framework?
A: Of course, any set of ideas can confuse. In fact, that was one of the motivations for this work. We saw too many teams using bad Scrum with bad Kanban. This work re-enforces what good Scrum looks like with good Kanban. Both approaches highlight the need to start simple. For example, you would not adopt cumulative flow metrics from day one, instead you would ease into empirical process, self-organization, transparency and all the great things of agile slowly.
Q: Will Scrum.org introduce formal certifications for Scrum Masters who finish the Scrum with Kanban course and when can we expect this? Also, will already certified Scrum Masters be provided with material other than the Guide to master this new concept?
A: The class and associated assessment (and certification if you pass) is stand-alone from our other classes. This allows people to get ‘good’ at Scrum and then add to their knowledge with Kanban. I do recommend that you start with Scrum, get the ideas working and then add Kanban next. In our first deliveries we invited some people who had been doing Scrum for a while and they all said – this will help them to improve their use of Scrum. It will ‘turbo charge’ their teams by increasing transparency.
I see the certification as another key way of validating that you can walk the walk. And yes, that means more content to support the class, guide and other materials. But we have to start somewhere.
Q: Is there a worry that adding new metrics (cycle times, throughput) will result in too much data to track for Scrum Teams?
A: Scrum is an empirical approach, which requires data to be effective; Data like cycle time, etc. But remember, teams don’t have to apply everything from day one, or even adopt Kanban if they feel it will not help. I would recommend, after you have been using Scrum for a while to think about adding Kanban. Run some experiments, see if the practices make sense. If they do, then keep them and if not, then think about using others. The fantastic thing about Scrum and Kanban is they both see the importance of reflection and change. A great team is always looking at itself and asking, ‘How can we get better?’. Scrum with Kanban provides ways to do That.
Q: The Guide mentions that work items (as introduced by Kanban) “may not correspond to Product Backlog Items or other parts of the Sprint Backlog or Scrum”. What are the other possibilities, other options for becoming work items?
A: If a Scrum Team decides to extend their definition of “Workflow” to encompass work that happens before work enters the Product Backlog (product discovery work, for example) or after a Scrum Team creates a potentially releasable increment (feature monitoring or validation work, for example), then those work items may not be performed by the Scrum Team. This work would not go into the Product Backlog or Sprint Backlog. There may be good reasons to visualize and track (e.g. metrics) that upstream/downstream work which is why they could choose to extend their DoW. However, Scrum Teams don’t need to start with this concept.
As teams use Scrum to stabilize and improve their core development processes, they realize in many cases that their constraints move elsewhere. Adding Kanban to Scrum helps teams focus on the flow both within the Sprint and beyond it, while helping teams bridge their Scrum with approaches like DevOps, Lean UX and Design Thinking.
Q: The Guide also states that the workflow might not begin or end at Sprint boundaries. Could this intentional misalignment produce confusion where the team loses sense of where the Sprint starts and ends and where the workflow does the same?
A: It could, but the reality is that Scrum Teams are delivering value in large complex organizations and with large complex products. Of course, we want to minimize this, and the great thing about applying the practices of Kanban is that you make it visible. How many times are there ‘unwritten’ things that happen to a PBI outside of the Sprint. How many times are assumptions being made about how this fits into a broader release cycle? The Scrum Team needs to see VERY CLEARLY where their boundary is in terms of the Sprint and the Definition of Done. By making this visible you can have very clear discussions about ownership, control and dependencies.
Scrum with Kanban DOES NOT change Scrum, it adds to it with a set of great practices that make work more visible.
Q: Can (should) Scrum Teams incorporate additional Kanban practices other than those outlined in the Guide, e.g. feedback cadences, Kanban charts and stats like Cumulative Flow Diagrams?
A: We started with a set of practices that we have seen being used effectively with Scrum. However, you are right, this is just the start. I would recommend that everyone always try to learn and add great ideas to their approach. In fact, Cumulative Flow is included in the class as a metric that can expose waste within the team (or outside as well).
Q: Steve Porter’s 2017 article on Scrum and Kanban being stronger together, as well as a number of subsequent articles, speak of bringing Scrum and Kanban together. This new guide and course are bringing Kanban closer to Scrum practitioners. Is there a plan for something going in the other direction (of course, considering this is a completely different beast altogether)?
A: There are no plans at the moment. We are seeing what happens with this material and if it helps teams improve how they are delivering value for their customers. If it adds value and we see other ways of helping our community, Scrum.org would be open to it. But like anything, we have to start small, learn, inspect and then adapt.
Q: Should we see this Kanban “annex” to Scrum as mostly just testing the water; an optional alternative to traditional Scrum; or as a direction in which Scrum will definitely develop in the future?
A: I wouldn’t call this an alternative to traditional Scrum. Scrum has always been a framework to which additional practices are applied to build your process. We have seen Scrum Teams do so by bringing XP practices to their Scrum Team or Test Driven Development practices, etc. What we are talking about here is adding some practices from Kanban to how the Scrum Team works, but without changing Scrum itself.
Who knows where this journey will end although I would not call this an annex to Scrum. As already discussed, practices are added to Scrum every day to help form the right process for your team. I do know that if we help one team deliver a product and value just a little bit better, then this will have been worthwhile. Scrum, Kanban, XP, Lean Startup, etc. - these are all ways of helping people manage complexity and deliver value. They should never be the end game.
I hope Scrum with Kanban, even if people don’t use Kanban, reminds them to continue to always look for new ideas and build bridges to other ideas to deliver more value to their customers and themselves.