(Presented as Part 2 in the Scrum Alone is Not Enough series.)
Do you know what projects your Team is working on?
Do you know what the Teams around you are working on? Does everyone in your organization know?
In almost every organization that I visit, the answer is a resounding no. Scrum may have been implemented at the Team level but nothing is being done beyond that. Is there any dark work being done? Is it a high priority?
Without a clear picture, individual Teams and Team members don’t know what the overall priorities are, so they won’t know if a favour that someone asks for is in scope and valuable, or an expensive distraction. As a result, a lot of lower priority work is completed and causes unintentional damage to the project.
Kanban – (a tool to understand and improve flow) to help understand the flow of work at both the Team and organization level. Without a good understanding of flow of work through the organization, we might make a change that is a local improvement but harms the whole
Kanban has three core rules: visualize your work, limit your work in progress, and measure and improve.
1. Visualize your work
Our first goal is to find a way of visualizing your work in a structure that your Team and your peers will understand immediately.
Create Your Initial Kanban Wall
Gather enough of your peers and build a consensus overview of your work. Write down all of the steps in your world of work: from the moment an idea comes up, until it can be deployed. You can do this with the formality of value stream map or you can just write down an ordered list of the steps. Since we’re creating a portfolio view, the minutia of what happens inside a single development Team is probably just going to be a distraction.
For the Teams at the “World’s Smallest Online Bookstore”, the list of steps looks like this: Idea -> Idea Accepted -> Product Backlog -> Sprint Backlog -> Done -> Online Help Done -> Deployed -> Translated
Turned into a Kanban wall for two Teams, it might look like this:
Track the Work
Once the board structure is complete, work with each Team to find out the current state of their work. To keep it simple and high level, consider tracking chunks of work that are ~1 week in size per Team (if you’re doing Story Point estimation, imagine that these items are around a 13, 20, or larger in size). This way everyone can see a high level without getting lost in the minutia of a specific User Story. To identify which Team is working on a given item, either use swimlanes as above, or a separate coloured card/post-it note. Once a week, walk the wall from beginning to end with the Teams and update with the current state of work.
When we get more sophisticated, it often helps to track roughly how many days each work chunk stays in each state.
Now that we’re tracking the flow of work, it will quickly become apparent that there are places in our system where work either piles up or becomes blocked. We need to understand where the work is getting blocked and what is blocking it.
Are our challenges caused by a lack of people able to help at one stage (e.g. Technical Writers for Online Help)? Or issues outside our current span of control (e.g. deployments by a manual security audit by our webhosts)?
Visualizing this can be as simple as putting a tick mark on an item for every day/week it’s stuck, or creating a separate “waiting for” column in all places where these blockages occur. Either way, our goal is to understand where the blockages occur and work with our peers to resolve them.
At the World’s Smallest Online Bookstore it’s apparent that…
… we have a lot of work that is getting blocked at the stage of online help. Before we focus on improving the development Teams’ performance (i.e. their ability to build features) in the short term, it would be best if we addressed the systemic issues that are stopping previously completed features from being deployed.
This leads us nicely to the second rule of Kanban: Limit Your Work in Progress. In the next post in this series, we’ll discuss how blockages can be quickly identified and strategies implemented to overcome them, without anyone waiting around unproductive or, just as bad, overwhelmed and stressed out.
Images by Agile Pain Relief Consulting. Elements of first image designed by Freepik.
 Dark work is work done on the side privately without being visible to the rest of the Team or company. Sometimes it happens because a developer wants to make something perfect before sharing it. More often, it happens because someone stops by a developer’s desk and says the magic words, “Can you do me a small favour? It won’t take much of your time.”