How I visualize Kanban and Scrum
Last time I shared my journey to realizing the importance of breaking down complex concepts. By utilizing Spongebob I harnessed the power of a familiar illustration with the setup of an application. And so far it has worked. I challenged myself to approach Scrum and Kanban in a similar manner. Instead of drawing arrows, geometric shapes, and other objects reminiscent of a flowchart or a visual goto or continue statement, I came up with two visuals to better explain Scrum/Kanban.
How I explain it:
I used a track and field event to visualize Scrum. For one sprint my coworker randomly chose “100 meter dash” for our sprint name for obvious reasons, which led to this illustration. Specifically shown is the 100 meter race, the number of lanes is based on the number of stories that go in the sprint. The Scrum Master is the referee to make sure Scrum standards are followed and is there to answer questions. Before the race starts there is sprint planning to determine how to set the track up. The length of the sprint is the length of the race. The product owner is the head coach, there to make sure everything goes well and has a high level overview. This might hold truer in longer races such as a marathon, but current progress during the sprint/race can be snapshotted in a standup (e.g. how is the pace of participant, are they falling behind, what do they need to do to ensure a successful finish). The development team consists of assistant coaches who are closer to the stories running the race. At the end of the race the finish line is the retrospective. Product backlog can be defined as extra runners that cannot fit in the limitations of the current track and need to wait until it is their heat before they run.
Why I like it:
Scrum centers around the sprint, as its ceremonies work around and through the sprint. Beginning from that understanding it was easy to branch out to fill out the other roles. At the end of the day we want stories to “run” as fast as possible through the development track, because once they finish stakeholders receive value.
What I don’t particularly like:
As with all illustrations, some suggestions/roles seem like a stretch within this model. I imagine it would be harder to have listeners wrap their head around the fact that stories actually enter the race, not the development team. I did not have a clear way to explain the product backlog, except for extra runners that have to wait their turn. Although stakeholders are not officially defined in Scrum, one knows that at an event there are people that are tuned in to the progress of the event.
When I think of Kanban, I think of flow. Visualize your workflow, and limit work in progress. We want to get tasks moving through the process as seamlessly as possible, and remove bottlenecks as soon as we identify them. Hence why I chose an artery to visualize how Kanban should work. Blood vessels are the tasks going through the flow. The size of the artery is determined by the size of your team, and from there you can determine how much a team can handle at any given time (my personal rule for WIP limits: Number of people on the team + 1 or 2 tasks). While blood vessels don’t exactly cause clots bad health on the team can lead to buildups in certain parts of the process (impediments, absence of key individuals, not having a great testing strategy). Build in such an area restricts blood flow, which can easily be identified by columns in your process that have reached their WIP limits. The backlog that lives inline with the process represents the other blood vessels that have yet to flow through. Cycle time is identified by the length of time it takes a blood vessel to go from one side of the artery to the next.
Why I like it:
In Kanban the less work in the pipeline the easier it is for work to flow through. We all know multitasking is a farce (it is really fast context switching which does lower your productivity) so only focusing on a few tasks at a time ensures proper flow. Seeing as the health of a project can be determined by cycle time, it made sense for me to use an artery to explain the importance of preserving flow.
What I don’t particularly like:
Since there are fewer artifacts to explain in Kanban, it made the illustration easier to develop. That being said, a better visual would show blood vessels (work) as a good thing (when it is flowing) and a bad thing (the cause of bottlenecks). Right now it appears the clots are external to work but in reality the work itself can be the cause of bottlenecks.
I recognize that these are imperfect illustrations of such deep and thoughtful concepts. However, I wanted to find one visual that would cause the topic to click immediately. The danger with illustrations is making the content fit the illustration, thus leading to potential misrepresentation. I’m sure in about a year or so I will identify a better way to visualize Scrum and Kanban but for now this is what I will refer to when I am asked to explain these frameworks.