A few weeks ago I was in Boston to visit the Scrum.org offices and learn to teach the Professional Scrum with Kanban (PSK) training class co-taught by Steve Porter and Daniel Vacanti. This is a new Professional Scrum training course created by Ken Schwaber, Scrum.org, the Professional Scrum Trainer Community and Daniel Vacanti who helped to develop the Kanban Method for knowledge work. The new class was just announced by Ken & Scrum.org and includes a Kanban Guide for Scrum Teams that describes Kanban within the context of the Scrum Framework.
Now you can not only learn Scrum from those that created and maintain it, but you can add Kanban from those that developed it as well. This new class show how to take the core practices of Kanban and implement them within the context of Professional Scrum without changing Scrum. I have already posted on how you can flow work across the Sprint boundary and that was a direct learning from me attending this class.
This is a 2 day class that also has an assessment that will earn you a PSK certification. I’ll be teaching this class in combination with Chris McDermott, founder of Lean Agile Scotland, to bring some much needed Kanban team experience to the class. While I have significant experience with Scrum teams, I have only worked with a few Kanban teams.
The Kanban community and the Scrum community have been working towards the same end for some time. Since the mission of Scrum.org is to improve the profession of software delivery then anything that we can do to make that a reality is within scope.
Scrum is more than 20 years old and has been trawling some baggage with it. Since the creation of the Scrum Guide Ken & Jeff have been working to remove much of that baggage from the definitive and agreed definition of Scrum and they have done a fantastic job. You will not find a mention of User Stories, Story Points, or Velocity in the Guide. They are not required to create an empirical control system.
I am not saying that they are bad, just that they are merely complimentary practices that you can choose to use or not. And let’s be super clear, if you have an amateur team then you should be starting with User Stories, Story Points, or Velocity, they are good practices. For more advanced teams that are already delivering working software on a regular cadence you might want to change those practices out for ones that focus more on flow, and you might also choose to use User Stories.
You can read the Kanban Guide for Scrum Teams which is an extension to the Scrum Framework. The Scrum Framework is closed for modification and open for extension which is reflected in this new guide. The new Kanban extension adds the following practices:
- Visualisation of the workflow
- Limiting WIP
- Active management of items in progress
- Inspecting and adapting workflow
In order to adapt your workflow to maximise the flow of value to your customers we also need to add the following metrics:
- Cycle Time
- Work Item Age
This is an implementation of Kanban within the context of Scrum and as such has a definition that might differ from other Kanban implementations. Have a read of the guide and see if it appeals to you. For me the ideas of limiting WIP are ones that I have always encouraged teams to do and velocity always seamed like a broken metric.
Working with Daniel Vacanti has opened my eyes to throughput and how it can replace velocity and help answer many of the questions that I have been asking for some time. His training and this class made so much sense that I don’t know why we have not yet adopted these practices in mainstream Scrum. I think that is time for a change.
If you are interested in the same revelations that I had you can read the Guide, and if you like what you see then attend a Professional Scrum with Kanban (PSK) training class with Chris McDermott and I.
Did you find this article helpful?