Sunday, February 19, 2017

If you talk about "Moving from Scrum to Kanban" you have misunderstood at least one of them!

Scrum is defined by a specific set of roles, events, artifacts and rules that can make up a software development process when the specifics for your given context are resolved and defined.

Kanban on the other hand, provides mechanisms for controlling your work and improving the way you work together with a set of principles and practices like visualization, limiting work in progress, managing flow making policies explicit and a couple more.

Kanban does not provide counterparts to the things Scrum provides – rather, it is a complementary approach to any product development approach.

You can easily build a Kanban system for any given Scrum implementation - most of the time you just have to model four or five states, identify one to three capacities and define the cadence for the input queue and the output queue. A very simple approach here is to define the

  • Stations as "Backlog", "Selected", "Implementation", "Review" and "in production" (and make them visible)
  • (bracket) capacity of "Selected" through "Review" := throughput of last iteration
  • input cadence := output cadence := iteration size
  • iteration size := your sprint size

Of course the real power of the Kanban approach only begins after this stage, when you start to improve the way you work together collaboratively. But that would be another post...

Most of the time the processes inspired by the Kanban approach end up with a much more flow-based solution than typical scrum processes, and that is what a lot of people seem to mean when they talk about their evolution.

But please don't talk about "moving from Scrum to Kanban" – that would be like saying "I don't use a car anymore, I now use a GPS" – and you wouldn't say that, would you?

till next time
  Michael Mahlberg

Sunday, February 05, 2017

We don't need a “process” we have working agreements...

“Yeah, well, I had to work around the process to get this stuff done for the customer.”
Doesn't that sound familiar? And more often than not people on the same team nod in agreement and work on like nothing happened. And soon somebody else says “Yeah, well, I had to work around the process ...”

But how about “Yeah, well, I had to violate what I agreed to upon how we work together to get the stuff done for the customer?”
In my experience people tend to be more easily annoyed or even upset by this latter violation of trust. But even more importantly the likelihood that people will re-negotiate their working agreements is also significantly higher.

That's why I try to convince my clients not to talk about “the process” but rather about working agreements.

Enter Scrum and Kanban

Now this is where approaches like Scrum, XP, FDD, SDSM or Kanban, to name a few, can hugely differ. Take Kanban and Scrum for example.
While Scrum is a Process Framework with very strict roles (at least for the Product Owner and the Scrum Master) Kanban is an approach for process control and process improvement. In many Scrum implementations I have seen, people have to “work around” things from the book. When –to name an example– was the last time you saw a person acting as Product Owner really having the final say on priorities?

Kanban on the other hand explicitly requires that we “Make process policies explicit” (4th General Practice of Kanban) – I like to restate that as “make our working agreements explicit.”

And once we start negotiating these agreements we actually start to “Improve collaboratively, [and] evolve experimentally,” as the 6th General Practice of Kanban describes.

I suggest dropping the chase for the perfect process in favor of finding the best working agreements (aka process policies) for the current situation.

till next time
  Michael Mahlberg

P.S.: The "General Practices" used to be called "Core Properties", but since the Kanban Condensed Guide, "General Practices" seems to be canonical.