Number one of the 6 General Practices in Kanban is to visualise – so when you start using Kanban, one of the first steps you invariably take is to visualise the workflow. All too often this is the first and last visualise step that teams take. What you need to do is:
Visualise the workflow iteratively
In other words, visualising the workflow should be an ongoing search for the best representation of the workflow you actually follow. Consider the initial version of the flow you come up with a first draft. Try it out, and then look to see how you can improve upon it. Some suggest things are easier if you use a physical board for early attempts and then move to an electronic version once things have settled down a bit. I disagree. I think if you’ll be using an electronic board in the medium to long term it’s far better to get used to changing that version and learning to adapt to its limitations.
For example, I was working with a team to take a Magento 1 module, extract the core functionality and use that to serve new Magento 1 and 2 versions of the module. At a retrospective the senior software engineer on the team, Rick Peacock, realised that the Production Ready column actually had a few additional steps within it that had not been visualised. They relatied to being ready to build a package for the module, getting customer approval and then being ready to deploy the package. We considered adding more columns to represent the additional steps, but rejected this as there were already 10 columns on the board, and Jira gets less usable the more columns you have beyond this number. Instead we decided to add 3 new swimlanes above the normal flow, using labels to move the tickets between them. These were Awaiting Package, Package Approval and Package Approved. With this change in place it became much easier to follow a ticket’s progress through the workflow.
Don’t stop improving the way the Kanban board represents the workflow, and equally importantly, don’t stop your visualisation efforts with just the workflow.
What if the workflow is represented well, but things aren’t getting all the way across the board? Are tickets getting cancelled for some reason before they’re finished? This might be where the Product Owner has a change of heart. Or a ticket has been blocked for so long it’s no longer relevant. If lost time becomes an issue for the team a good way to draw attention to it is to:
Visualise waste with a waste snake
I first heard about this idea when I was lucky enough to have an Inviqa agile coach working with the team on a billing project for an ISP. The concept is fairly straightforward and works best with a physical board. Instead of simply throwing away a cancelled ticket use it to start building a snake somewhere on the board. As the snake gets longer the extent of the waste becomes more apparent.
Another example in software development is to:
Visualise the branching strategy iteratively
For example, I worked with a team to build a product help portal for a global payment gateway company. There were a lot of firsts for the team. Some of the team hadn’t built a production site with Drupal 8 before. As a company we hadn’t built a Drupal 8 site with Acquia, nor had we used their new Pipelines product. We had also decided to use ContinuousPipe for our development and QA environments, which was new for the whole team. In a retrospective the Technical Team Leader suggested that it would help everyone understand the branching strategy if we had a simple diagram showing how it worked. He then worked with James Sheasby Thomas, the Quality Assurance Analyst (aka Tester) to build a first draft to share with the team. As soon as it was out things started to improve. It also became the basis for ongoing improvements to the branching strategy itself.
Retrospectives are a critical part of the ongoing improvement process. And the main benefit of a retro is to generate actions that can be implemented by the team ideally before the next retro. If these actions only live in the write up document of the retro it’s easy for them to hide away until the next retro happens. To avoid this:
Visualise retrospective actions and when they’re done
either by allocating part of the physical board to them away from the normal flow, or for an electronic board using an epic, label or component to easily filter them. Either way it should then be much easier to review their progress on an ongoing basis, for example at the daily standup. Keep the workflow for retro actions as simple as possible. Ready – Doing – Done is usually enough. If you find you’re running out of room for them all on a physical board or it takes too long to summarise progress at a standup these are indicators that you’re biting off more than you can chew. The team can then have a conversation to work out what to do about this. Seeing that retro actions have been completed at a standup is a great way to encourage the team to find the time to do more of the same.
These are all real life examples of visualisations that have helped teams I’ve worked with improve their workflow. I hope they help you too.