A Scrum Master's Journey to Kanban

I'm a Scrum Master, in fact, I'm fairly sure that if you sliced off my arm you'd see Scrum written through me like a stick of rock at the seaside. So why did I volunteer to write an article for a Kanban Blog? In an attempt to answer, I'm going to start by telling you why Scrum is awesome.

For anyone who has read The Scrum Guide (or worked in a Scrum Team) you'll know that "Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems." One of the key structures of Scrum is two cycles of goal setting and an empiric inspection and adaption cycle for each. At a day to day level we work to ensure we hit a Sprint Goal which will deliver real incremental value to the business. Around that, we have a Product Goal which represents a future version of our product we are working towards. These two structures provide focus and help us verify that we are moving in the right direction.

To understand why I'm talking about Kanban we need to look at what Scrum doesn't do. Scrum doesn't build software, it doesn't define a best practice for programmers or testers, and it certainly doesn't make any guarantees about what will be delivered by particular dates. In fact - to quote the Scrum Guide again "The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory." In other words, Scrum is never intended to be all things to all people and anyone relying entirely on the framework will find themselves seriously underarmed in some situations.

One of those situations is when a business requires forecasts on when work will be done. Or when a team is looking for guidance on how to deliver work more predictably or efficiently. This is not a failing of Scrum, it's simply one of those incomplete areas agile practitioners should look at other frameworks and tools. Scrum keeps us on track, Kanban helps us predict when we'll get there.

In the past Story Points have been (and still are) used by teams across the globe despite not being part of the Scrum framework. Many teams and Scrum Masters (including myself) have come to realise that there are far more powerful and reliable techniques out there which can do a far better job of forecasting when work will be completed than Planning Poker. But I'm writing on a Kanban Blog, I don't feel I need to make that argument here!

My own revelation came when I'd completed my PSM-III exam with scrum.org, a friend suggested that I looked at their Professional Scrum with Kanban resources which were created alongside the ProKanban Community. I was immediately hooked and the limitations of my own knowledge became very visible. Instead of seeing two competing frameworks, I began to see two groups investing their time and energies into different specialties of delivering great software. I joined the Slack group, I read Dan Vacanti's books, and slowly began to improve my skills and knowledge by putting the techniques of WIP management and forecasting to good use.

If you're looking for a framework which will keep you close to your stakeholders and ensure that you meet customers' expectations then Scrum is undeniably one of the most powerful methods out there. If you're looking to answer questions about when your work will be delivered based on real historical data and for ways to define and manage your workflow then you can't do better than Kanban. If you're working in a team which values delivering the right thing as efficiently as possible and with good forecasts then perhaps you should be looking at both?

Of course, there are still some hiccups. These frameworks were created by different groups of people and while they both align on agile intent there are some areas where you need to put effort in to make them work together. Defining a Sprint Goal using Kanban techniques is an interesting one, as is eroding the long held belief that Story Points are worth the shiny glossy paper they're printed on. But this is the same with any new technology or process adoption. Surely we shouldn't be scared of taking tools and integrating them into our product or process? Personally, I'm running forecasts of my projects using both the teams' SP estimates and Monte Carlo simulations so that I can look back with the benefit of hindsight to see which gives more accurate forecasts.

I've even started using Kanban techniques with my own projects - Maria has been waiting patiently until this blog post reached the top of my TODO column and you really don't want to get me started on the level of detail I forecast the completion of my warhammer armies!

As a fully certified Scrum Geek my view is that we should empower our teams to use the appropriate tools which suit them best. This includes frameworks and processes - we shouldn't be afraid to learn and adapt. If you don't believe the other frameworks provide value then I'd suggest spending some time looking at those techniques because there could be something there you are missing out on. So get over to the Scrum pages or the Kanban community as needed and find out what you don't know. Meanwhile, I intend to sit firmly with a foot in both camps listening to some very smart people in each!

Author - Adam Griffiths