Many teams start out with Scrum and over the years they remove stuff – and add WIP limits – and come closer and closer to Kanban.
Many teams start out with Kanban and over the time add things like Sprints and Retrospectives and come closer and closer to Scrum.
This is all fine and a sign that teams are adapting their way of working to their needs.
But teams that are starting out – what should they begin with?
One way of looking at it might be to say that if it is difficult (or wasteful) with:
- Dedicated resources – more or less full-time
- Work in Sprints that are more or less predictable
- Cross-functional teams
- Self-organizing teams
… then Kanban might be a better choice because it will be difficult for Scrum to work properly.
However, while this could be somewhat helpful, I don’t think it is the right way of thinking. You first need to ask yourself WHY these things are difficult.
For example:
WHY is it difficult to get dedicated resources on the team? Are people being spread out too thinly? Do we have too many things going on at the same time that are seriously hampering our flow? Are people too specialized and hence need to be on multiple teams? What is the true cost of task switching? Etc, etc. Similar questions concerning cross-functional teams.
WHY is it hard to work in sprints that are more or less predictable (remember that it is perfectly fine to allocate e.g. 25 % of the time in the sprint to urgent bug fixes and support – at least if you ask me)? Is it because the Product Owner changes his/her mind all the time? Could it be a better option to have a dedicated support team? Is it because we release too many bugs into production. Etc, etc.
WHY is it hard to get a self-organizing team? Is it because they have become so used to someone always telling them what to do that they have stopped thinking for themselves? Or because they have gotten punished when they have experimented and made a mistake? Etc etc.
I do recommend that you consider questions like this before making a choice between Scrum and Kanban.
But I believe there is a more fundamental question that should guide us in the choice with how we start-up. What you really need to consider is this:
- Is our main need improved communication or
- Is our main need improved flow
When your main need is communication you can benefit tremendously from all the additional team practices that are part of Scrum.
When your main need is flow the additional Scrum practices might be a waste of time.
But what if you are on a super-urgent project and it is extremely important to get things out really fast?
Then you need to ask yourself if you really will deliver the right things, in the right way, at the right level of quality if you communicate less (less built in team communication in Kanban than in Scrum).
Bare in mind that the root courses of troubled projects are almost always related to communication and cooperation. If you read reports on failed IT-projects you will see the same things over and over again. When I coach and train teams and we talk about reasons for challenges and failures I hear the same things over and over and over again. Things like for example:
- The requirements were poorly understood
- The stakeholders expectations were not aligned with each other or with reality
- Scope changes were poorly handled
- We had unrealistic plans (and we knew it)
- The plans were poorly communicated
- … and the list goes on
Now, you can make the choice even easier by saying “let’s use Scrum for projects and Kanban for maintenance”. You probably wouldn’t get too far from the mark with this simplistic approach. But what is a project really in this day and time? What is maintenance? Where do we draw the line? And couldn’t it be the case that to some maintenance teams Scrum would be a great fit. And to some projects Kanban would be perfect?
I think so.
That’s why I stick with:
Communication / Flow
Scrum / Kanban
As a starting point. Not black and white. Not cut in stone.
And remember that Inspect and Adapt and Continuous Improvement are equally fundamental to both methods!
