In an engineering team you’ll likely work on some more complex variation of the todo - in progress - done process. You’ll probably have a physical board and some representation on Trello or Jira.
There’s a few reasons why you might want to take a deeper look into how your team works and how you progress work through your board:
- One of Kanban’s foundational principles to “understand where you are today so you can safely make small evolutionary changes”. This means you and your team mates must fully understand and have a shared grasp of how work flows. When is something ready to pick up? How do you know when something is ready to test? Where in the process is something deployed to production? Everyone should share the same answers.
- Visualising accurately the status of our work. We have a board to visualise where work is up to and to make it clear to other team mates when they can help move it forward. We need to ensure the workflow that we represent on a board is accurate. If it doesn’t reflect truly how the team works, every time a piece of work moves through it there will be points of friction and confusion. The board should support the way a team works, not drive it.
- It’s a great way to get aligned as a team, share different perspectives and needs between different team members. It also provides a safe place for newer people to clear up any questions they have about the way the team works.
How can you take a deeper look? To understand in detail how you and your team works, you need to map out the activities and the steps a piece of work takes when working on a task. You can do this with a Workflow Mapping Workshop.
How does it work? The goal of the Workflow Mapping Workshop is to give space for everyone in the team to brainstorm the process they personally take with a piece of work, and then group these activities with the rest of the team to create a shared understanding of the workflow.
First, it’s important to define the scope of the workflow to explore. In your team you might, for example, have different types of tickets (bugs, stories, tech tasks etc.) or different release procedures for different codebases you use. It’s a good idea to choose either a troublesome flow (maybe your team always struggles with bug tickets needing rework) or start with your happy path for your first workshop (like an average story ticket, with the assumption that everything goes smoothly on it ie. no code review fails). You could pick a real ticket from your backlog to help make imagining the workflow a bit easier.
If you already have some idea about problems or confusing areas of your workflow, prepare these in advance and make sure to raise them in the appropriate part of the exercise below. Once you start to build a picture of your workflow they will become easier to discuss.
An important thing to keep in mind is that you are trying to map how you work, not how your current board works. Remind people throughout the exercise to write the steps that a piece of work takes, rather than how it moves through your board. A tip is to avoid mentioning the board when writing stickies. Instead of writing something like “Move ticket to
Needs Code Review column” instead write “Create a pull request”, “Assign my teammates for an approval” etc.
Here are some steps to follow:
- Give everyone a stack of sticky notes and explain to write each activity they take when picking up a new ticket to work on.
- Once each individual has a map of their individual process, start from the beginning and go round in a circle sticking their first sticky on the board.
- Start to order and group stickies by similar actions.
- Here you should be left with a general workflow containing everyone’s individual activities.
- Throughout this exercise, there might be disagreement or questions might become clear when different people have differing steps. Write these up as question stickies in a different colour and stick them next to the corresponding steps.
At the end you will be left with two outputs:
- An ordered list of activities that your team takes to complete a piece of work.
- A list of questions which explain the areas of the workflow that people disagree on or are not sure about how it works.
To complete the goals set out at the start of this post, these are some next steps you should follow:
- To understand “how you work today” you should work as a team to answer the questions and aim in the end to have a clear understanding between everyone on how the workflow looks.
- To make sure your work is visualised accurately, ensure your board reflects the steps that your team came up with - there will probably be differences!
- In the end, your board should be self documenting of the workflow the team came up with, in that it should help explain to any new members how work should flow. A write up of the stickies you ordered might be useful as onboarding documentation though.
Now we have a clearer workflow, it is safe for us to make changes. Instead of first having to agree on how it works today in these discussions, small changes can be suggested based on the questions and points of confusion raised in the workshop. We can now also make sure that our board accurately reflects the true flow of work. Instead of Jira getting in the way and adding more confusion, it can become a frictionless tool that instead supports us progressing and visualising work, as it should.