Scrum to Kanban: Finding Your Workflow

If you are considering breaking the barriers of Scrum and moving to a continuous flow model I applaud you. I do like Scrum but it has overheads. Overheads that teams, who have begun to own and mature their ways of working, likely no longer need.

For those teams, and people helping those teams, one of the common stumbling blocks is creating the team level workflow, or process states.

The vast majority of the teams I encounter who are using Scrum have very simple storyboards, or workflows. Many are minor variations of To Do -> Doing -> Done. Some might resemble a more traditional SDLC, mapping a mini-waterfall process within the Sprint.

For a team moving to Kanban this simplicity won’t help you to discover the constraints within your system. It will not help you uncover hidden queues or other areas where work is sitting at rest, adding delays.

In other words, your Lean metrics won’t be telling you much beyond being able to measure them. You won’t be able to laser target improvement experiments with such broad workflow states (columns).

Your workflow should include all the major activities that transform work to Done. It should expose queues and help you measure them. It should help you discover improvement opportunities to deliver a smooth, more predictable flow of value.

3 Methods

Over time I’ve come to rely on 3 techniques to help teams define their initial workflow. As a bonus you will likely also discover some policies for the workflow states. Polices are also known as exit criteria. They are things that must be true for a work item to leave that state. Think of them as mini Definitions of Done per state.

You can combine these methods or use them independently.

Map Your Morning

Most often I use this technique when teaching Story Mapping but it works for this equally well. Most useful for new teams that don’t already have the information used in the other methods.

Think about a normal morning, what things do you do to prepare to go to work? Map out the major activities you do to transform yourself from waking up to be ready to work. Make notes where you think you might encounter a delay, have a question or may have to wait.

Here is a portion of my morning routine as an example with a note indicating where I could encounter a queue. I like to use Mural when defining a workflow but there are many tools that work. A whiteboard, painters tape and whiteboard markers works great too!

Use this same method of walking a prospective work item through the necessary states that will transform it. Take the perspective of the work item – what transformation actions will it encounter?

Examine the Tasks

Many Scrum teams break down their Product Backlog Items (PBIs) into small, one day or less tasks. While I’m not a proponent of using tasks I would not discourage teams from using them if they find them useful. Though I would encourage the team to experiment with dropping them.

Tasks often describe transformative efforts. Such as “Analysis” or “Add regression tests”. These are potential workflow states or policy items.

Work through the tasks of recently completed PBIs. Ask questions such as “are these process steps?” and “do these identify when something completed?” The former are candidates for workflow states, the latter for policy items on particular states.

For new teams, or teams that are not using tasks, examine PBIs that are in your backlog. Or simulate a few PBIs if you do not yet have a backlog.

Discuss the process steps that you expect will be necessary. How we know when a PBI can move (ideally pulled) from state to state. Walk several items through the workflow you are discovering, adjusting as necessary.

Keep asking “and then what?” and “what needs to true before this item can move to the next step?” Walk items through the process from start to completion.

Deconstruct the DoD

All Scrum teams should have a Definition of Done that they have refined over time. The DoD is the list of things which must be true for every PBI to be considered done. They are not specific to an individual PBI as Acceptance Criteria are. This list applies to all work items.

Read through the DoD as a team. Discuss which items describe tranformative activities they performed on the work items. What specific skill steps are happening? What artifacts did the team create or update as part of the process?

Pro Tip: An item in the DoD might not become a workflow state. But it will probably become an element of a policy on a workflow state.

As you work through the list you will likely discover items that could be either a state or a policy. Talk about if the item is really more a discreet activity (state) or a validation that something occurred (policy).

Some organizations will require things that could be a validation, or policy item, to be a separate activity, or process state. A very common one is “QE Testing”. While testing could be a validation policy on the “Development” state some organizations require testing to be performed by a separate group. So you might need to model it as such with “QE Testing” as a separate process state.

This is more art than science so practice. You’ll get the feel of it pretty quickly.

Involve the Team

Regardless of the technique, or techniques, you use, it’s important that the entire team participate. They are they experts in what they do and how they do it. They need to define how best to transform a new work item to completion.

There may be management required process steps, approvals or artifacts but management should leave the defintion of how to best perform those actions to the team.

For existing teams: map what you do today. Do not try to optimize or define a workflow that you hope the team can someday evolve to and use. One of the core practices of Kanban is “start where you are”. Don’t attempt to impose process change during this exercise. Enough other things will be changing, don’t force additional change on the team.

The initial workflow you create in a workshop such as this is not final. As the team begins to work in a continuous flow manner they will learn things.

They will discover where their workflow is clunky. They will uncover hidden queues that they need to visualize and measure. The team will learn to use data driven experimentation when making adjustments to the workflow going forward.

This is a lot of work. Don’t try to map the entire process in a single conversation or workshop. Take a day or two between sessions to get comfortable with the mapping. Questions will likely arise as people think of different things outside the mapping sessions.

Invest the time in mapping out the workflow over several working sessions, the results will be better.

Until next time!

Total
0
Shares
Leave a Reply

Your email address will not be published. Required fields are marked *

Prev
Scrum Masters: Tired of Status Report Standups? Stop Doing This One Thing

Scrum Masters: Tired of Status Report Standups? Stop Doing This One Thing

Reviewing the taskboard at Standup reinforces the practice of working as

Next
Stop Using a Blocked State (Column)

Stop Using a Blocked State (Column)

By moving the work item to a different state you are lowering the WIP in its

You May Also Like
Total
0
Share