Kanban is not a solution for team dysfunction
It is a very common misconception in the Tech World, that Kanban is somehow “easier” than Scrum. A lot of people believe that a move to Kanban will make somehow remove all the difficulties and problems that are usually associated with Scrum. I’m here to tell you that is definitely not the case; Kanban is for high velocity teams that have been able to build a culture of delivery and can focus on the things that matter most without prompting or ongoing direct management.
What is work?
Scrum is regularly maligned and criticised because a lot of people think it “doesn’t work”. I’m here to tell you that in most cases (not all), it isn’t working because the team is trying to cheat. It’s because they think that following a process will result in good outcomes, but never define the outcome. The primary deliverables of any work management process is something along the lines of:
- A description of what should be done.
- What does the final deliverable look like.
- How long will it take.
- Who will do the work.
- What is the current status of the work.
If you can answer all of these questions, then a piece of work has been defined well initially and throughout its lifecycle.
Okay, but where does Scrum come into it?
Quite simply, Scrum has been built to enable teams to effectively create their work processes to deliver work. In fact, you can see this in some common “fields” for a card:
- User Story: A description of what should be done.
- Acceptance Criteria: What does the final deliverable look like.
- Estimation: How long will it take.
- Assignment: Who will do the work.
- Updates: What is the current status of the work.
These are all defined in some very common rituals that teams participating in Scrum usually have:
- Backlog Management: An initial card is generally created by a Product Manager based on incoming work flows. This should be a very high level description of the feature.
- Refinement: The PM will take the card to refinement where she will work with the team to identify an appropriate User Story and Acceptance Criteria for the card.
- Planning: Prior to this meeting, the Delivery Lead will have worked with Team Members to understand the amount of capacity each person has for the next iteration. The PM will have worked with Senior Leadership to understand the strategic pressures on the team and has prepared a draft iteration plan in concert with the DL. The team uses planning to Estimate the work as a group. If there is too much work, the team will discuss the priority of each card to decrease or increase the work to manageable amounts; otherwise the iteration will go forward as planned.
- Stand Up: Prior to Stand Up, each team member should provide an Update on their assigned card. During Stand Up, team members will discuss any completed work or blockers. If they have completed a ticket, they will Assign themselves a new piece of work.
Makes sense, but why is it not working for my team?
I’ll keep this simple. During an iteration, an in-process card should
look like this:
However, what they usually look like is:
A lot of the discussion that happens in meetings is generally not
recorded and gets lost. This means that when someone is sick, stops
working on something, or something else happens, no one is able to
understand where work is at. Fundamentally, you have all the bureaucracy
without the paperwork which renders the process void as you lose all the
value from it. The reason people put up with Transport Departments is
that they keep good records, even if it may be painful to deal with.
People wouldn’t put up with it if they didn’t keep records. What point
would all that bureaucracy be if they had no record of your license or
registration and have no standard for a roadworthy vehicle? This is
fundamentally why teams break down when it comes to scrum: they do 95%
of the work, but then don’t do the last 5% of the work that is valuable
and impactful. It’s like eating a coconut except once you get rid of the
shell you decide it is too much effort and throw away the edible bit.
Okay, but why can’t I use Kanban?
Quite simply, Kanban requires all of the processes from Scrum except the team does them all without prompts or meetings. Instead of planning, the PM ensures the backlog is prioritised. What about refinement? Well, the team naturally prunes and manages the backlog, taking a few minutes each day rather than a meeting once an iteration. The list goes on, but there are a tonne of cultural things that high velocity teams using Kanban do that can’t be skipped.
That’s not to say you can’t use Kanban, but don’t expect it to fix your problems. You’re still going to have cards with no context and have no idea what anyone is working on or why. The only difference is you have WIP limits that are regularly exceeded and no end date to the “current” iteration. It also requires a culture within the team that holds everyone to a high standard. If the standard isn’t maintained, Kanban will quickly fall apart.
Well, if I can’t use Kanban to solve my problems what should I do?
Make sure your cards have all the information that someone would need to work on that piece of work with no external information. I’m not suggesting you write War & Peace in updates, but as long as the card has enough context about what needs to be done and a link to a Pull Request someone has been working on, then a competent developer should be able to figure it out.
Once your team is in the habit of managing cards effectively you will start to notice that your team rituals move much faster. You spend less time in meetings and more time delivering. When this gets good enough, you will probably naturally convert to Kanban because the meetings are no longer necessary. It’s really that easy.
