Today I’m proud to host a guest post by another AgileSparks coach – Yael Rabinovitz. Yael has been working with several clients on Scrum implementations and has recently started using the Kanban Method (I wonder who gave her that crazy idea…) and is sharing her thoughts about the first steps into both approaches. Without further ado, here’s Yael:
Is starting with Kanban really easier than with Scrum?
Kanban is often described as a way to achieve evolutionary change in an organization, creating less fear and resistance than more “revolutionary” approaches such as Scrum. Kanban indeed respects current processes. For example, in its first steps it does not impose role and responsibility changes, but encourages continuous small incremental and evolutionary improvements to your current system. But is it really an easier way to launch a change process? Always? The last few Agile implementations I was involved with that used Kanban as a starting point made me contemplate this topic. Here are some of my thoughts.
Implementing Kanban seems to be simple technically. Just visualize your current process, build the Kanban board and describe your process as a pull system. Kanban does not prescribe specific practices, but the team is expected to apply lean thinking tools such as limit the WIP, focus on flow, optimize the whole, stop the line and fix (focus on quality), find bottlenecks, protect the team from external interruptions, etc. This requires high maturity from the team. Unfortunately, in many cases, teams find themselves struggling at the starting point, especially when attempting to apply the “limit the WIP” step. This can be extremely difficult and requires good collaboration and shared responsibility between the development team
and the PO in order to allow balancing demand and
throughput. When this collaboration is not mature, teams tend to get stuck and find it hard to move forward, which leads to frustration and increases resistance to the change.
Shape the path – Script the way
Scrum’s prescriptive nature is more suitable for such immature teams as it “scripts the way” (from “Switch” by Chip Heath & Dan Heath) and provides best practices and definitions of the processes to be followed (daily standup, planning, demo, retrospective, clear definition of the PO/team responsibilities). Scrum provides a practical framework that makes the mindset shift easier, as teams can rely on the framework in this “SHU” phase (“Shu-Ha=Ri see: http://alistair.cockburn.us/Shu+Ha+Ri). The clear definition of the PO role vis-a-vis the team provides the needed collaboration and WIP is limited implicitly by defining the sprint’s backlog, which I believe teams find more natural to grasp.
Small work units
Another point to consider is the need to break features into small pieces or user stories. This is a huge challenge that teams usually struggle with from day 1 in both Kanban and Scrum. This is fundamental to improving the flow in the system, thus reducing cycle time in Kanban, and creates the building blocks of the product backlog and sprint backlog in Scrum. I find that Scrum guides you more safely and clearly in this task than Kanban, as the framework and practices for creating stories are explicitly built into the Scrum process. Questions like: who is the owner of the stories? When should the stories be ready? What is a good story? Who approves the results and when? The team has built–in answers when it uses Scrum as a starting point.
The energy for change
It is also very important to consider the “energy” that the organization needs to have in order to change. Agile practically requires the organization to “reinvent” itself and, in many cases, the beginning of the process is an excellent opportunity to do just that. At that time, the right levels of energy exist, with the “buzz” created by training and management’s attention, as well as the willingness and courage to make a dramatic move. Scrum suits this “let’s make a revolution” mindset much more than Kanban, which requires stamina, patience and long term thinking. Most teams don’t have the time and patience for ongoing improvement cycles – they want results now. They are willing to risk, speculate and go along with revolutionary ideas rather than patiently wait for evolution.
Early success
Being able to achieve small wins early in the process provides a lot of “back wind” to the process. Scrum’s sweeping nature allows identifying these small wins quicker, thus injecting positive energy into the process at a much needed stage. The adoption of cross functional teams and creation of a rhythm in the organization, with demos and retrospectives quickly gives a sense of progress. It is important to pick low hanging fruits and produce results quickly.
I found that in many cases, if a momentum for revolution exists both in management and teams, Scrum’s constraints are much better for keeping the teams focused and accountable. Once you reach a point where you have a backlog with well defined stories and you are mature enough to go to the next leap, it is time to implement Kanban in order to optimize the whole and focus on the flow of value across the system, improving your cycle time from start to end.
So, should we start with Kanban or Scrum?
The only right answer is: it depends. It depends on the organization’s state, the scale of necessary changes, the desired outcomes and the problems and pains that triggered the Agile initiative.
What I attempt to do in this post is challenge the widespread myth that Kanban is always the easiest way to start. I have found that, when management is on board with the right mindset, starting with Scrum can be safer and easier. The Retrospectives in Scrum provide the evolutionary mechanism Kanban advocates that allow the organization to continue and make small incremental changes and continuously improve beneficial aspects and weed out harmful attributes
Start with Kanban or Scrum but, since you are interested in this journey, it is important to start! Begin, keeping in mind why you started and what you are trying to achieve .We don’t want to waste our time with too much upfront planning anyway, after we begin the journey, the steps we should take to move forward will unfold.
“The Road goes ever on and on
Down from the door where it began.
Now far ahead the Road has gone,
And I must follow, if I can,
Pursuing it with eager feet,
Until it joins some larger way
Where many paths and errands meet.
And whither then? I cannot say.“…
Hobbits walking song, “The Fellowship of the Rings”,J.R.R Tolkien
My thoughts about this:
Regarding the hardship of limiting WIP – I agree limiting WIP is hard. It is certainly not “start where you are”. It is the major step towards “evolutionary improvement”.
While being hard, I believe that there’s immense value in having a very focused pain. You know why you want to Limit WIP, you knew it was going to be difficult, you can have a focused discussion about it, raise the obstacles, set a plan, and decide about the schedule/steps for limiting WIP in a way that makes sense.
If you look at Scrum – yes of course you can start without limiting WIP and enforcing the sprints. But then you don’t get a lot of value. You spend effort setting up the right teams (you don’t necessarily have to do that with Kanban – although in Yael’s description seems like the change to Teams is easy and transparent) and then if you don’t really adopt Pull and enforce the Sprint as a container, you are not getting the benefit of Scrum. If you are, it is the same hardship, but it is hiding without a lot of other changes that are happening. Teams will have lots of discussions about other things in their retrospectives before they reach the point where they deal with the fact they are not using the Sprint as a container.
So Scrum might be easier to start with, but to get to real Scrum that provides the real value of Scrum you need go thru a similar pain.
Having said that, there are many scrum AND kanban implementations out there that don’t really Limit WIP or respect the sprint container and therefore get mediocre change/improvement pace. That is a shame and something we need to work on.
Regarding small work units – note that Scrum doesn’t include any guidance about User Stories. It talks about PBIs – Product Backlog Items. People associate the User Stories practices with Scrum, but the same can be applied with Kanban. But again, lets consider the amount of focus organizations spend on having the right definition of stories, whether it is their current biggest obstacle or not. And beyond that I haven’t found much guidance in Scrum for how to make sure those stories arrive ready for the sprint. Actually one of the typical usages of Kanban are to make sure that the end to end flow from idea to done is managed, not just within the sprint.
Regarding energies – I agree that in some cases it makes lots of sense to start with a big bang. It really depends on the context. But a cautionary note is that in many cases the “wish” for a big bang is more of “lets get this over with” while the organization is not really ready for what a big bang really means…
I wholeheartedly agree it is all about starting the journey and getting into an Inspect and Adapt / Emergence mode as early as possible. Beyond the Retrospectives, the key element in Scrum that will drive this inspect and adapt is the pain of the Sprint Container. If the container isn’t sealed, the improvement will not be directed necessarily towards agility.
My main takeaway is that we need to focus on guidance how to make the early stages as easy and streamlined as possible, with a main focus on Limiting the WIP and how to structure the discussions and interactions around the early experiences with this change in the way organizations do their work.
And that in some cases it will be easier with Scrum, some cases with Kanban. Some cases a mix will be best. No easy recipe… Complexity rules!
Thanks Yael, good one 🙂
Excellent post from Yael, and great complementary comment from Yuval.
I want to relate to Yael’s small but important comment on management being on board:
Management buy-in and commitment makes almost all the difference. Yes, it is possible to start without management being supportive. Not so much when management is opposing agile transition (but if your faith in agile is strong, this is also possible).
So, in such cases, when it comes to Scrum vs. Kanban, for the reasons that Yael has provided, probably Scrum is a better starting point. The framework that Scrum prescribes makes it easier for you to assess whether “Yes, we are doing Scrum”, or “We are doing Scrum-But…” or “It is a process, alas Scrum it is not”.
With Kanban, in my view, it is less trivial to distinguish between the process and the organizational defences that so often stand in the way.
When management is committed to the transition, it is probably easier to make an educated decision based on what the organization requires.
Great post, thanks!
Ilan, While I totally agree management buy-in and commitment are crucial, I’m not sure I agree Scrum has an edge here.
Yes you can see if you’re doing Scrum-but or not, but I think Scrum-but is necessarily a problem. There are Scrum-buts that are a problem that communicates management opposition/lack of support/engagement and there are Scrum-buts that are more of a Scrum-and kind of approach that reflects engaged management trying to inspect and adapt towards a better Process/Context fit. The problem is that it is hard to know which is which, so people in the Scrum community see all Scrum-but as a problem.
With Kanban, the rules are even simpler. If you’re visualizing, limiting WIP in a way that generates pain from time to time, raising obstacles to flow, dealing with them, and improving the flow on an ongoing basis – also known as Learning and Adapting your process, then it means you are on the right track. There is less “fat” of process around this core property than with Scrum. My experience is that it is much easier to get managers to understand the concepts as well as measure whether they are on board or not with this approach. I will be happy to share experiences if you have other cases where you tried Kanban and saw a problem of discerning whether management were aboard or not.
one last note – Ilan and readers interested in this question – suggest you look at “Innovation Accounting” model from Lean Startup as a way to know whether you are making progress in your change. If you are continuously improving on your key actionable metrics it means you are on track. If you are not and the metrics stall then it means you need to further tune your improvement engine (e.g. by considering how to engage management to spend more time dealing with impediments, spend less time micro managing etc) or consider a pivot to a different style of change at this point.
Which to start with depends on many factors like you pointed out. Sometimes there are hard organizational boundaries to cross and Kanban is easier to ease into a change. Moving a company with strong functional silos to a Scrum model can be much more difficult so from my experience it depends on the type of work being done, attitude of the managers of the functional groups, executive support, how the people on the teams feel about the change, existing political currents and more.
It’s a matter of reading the system and figuring out which approach is best for their context, Scrum can be easier to start with in some cases, so can XP, so can Kanban.