Agile For Non-Dev Teams (Part 2)
Yes we Kanban.
After five months using Scrum to organize the workflow of a non-dev team producing news articles, we had shown demonstrable improvements in many areas. However, the system still had one clear deficiency: since news articles are constantly being published, the throughput of the team producing them must be constant as well. Producing articles in batches via Sprints therefore did not suit. This deficiency manifested in two ways:
- Articles went out of date while sitting waiting to be published.
- Writers were left idle at the end of a sprint, waiting for the next sprint to begin. The ability to measure velocity of a team (Scrum’s key metric to demonstrate improvement) is compromised when articles can be finished before the end of a sprint, not leaving enough time to write another complete article. (For development teams, extra unexpected capacity at the end of a sprint can be filled up by minor bug fixing).
So we turned to the most obvious system for ensuring constant throughput: Kanban. Kanban was developed in the mid 20th century at Toyota. I find thinking about it in terms of a car production line is particularly helpful: A product moves through different stages on the production line, and between different people at each stage. Since each person/stage only has capacity for so much meaningful work in progress there is a constant movement of deliverables and eventually finished products.
After five months of regular weekly reviews doing Scrum, our optimum production line had revealed itself: To Do, In Progress, Buddy Check, Sub-editor Review, Editor Review, Stakeholder Approval, Publish. This clarity, combined with a wealth of information on how much we could manage at one time, and how long these tasks took, we were able to meaningfully transition to a Kanban board very quickly.
Additional benefits of Kanban
We switched to Kanban to counter a specific deficiency with Scrum, but it brought with it additional benefits that we did not foresee.
- Visibility. We were able to react even quicker to the changing priorities associated with news reporting. Even a red alert shift in priorities could not derail us too significantly, as we could quickly visualize and sort the priorities of in progress items to re-assign resources.
- Backlog column & On Hold status. On a Scrum board, the Backlog is not visible, only the current WIP. On a Kanban board everything is visible, with work not in progress (whether not yet begun, or on hold) stored in a “Backlog” column on the left most side. This extra visibility meant that no writer could be unsure of what lay down the pipeline/roadmap. Equally, any On Hold tasks did not clutter up our board — ensuring constant clarity of communication through visibility.
- Constant Planning — Traditional Kanban does not include a weekly review/planning meeting (although you can of course hold an ad hoc meeting if tasks are running low or if there is a specific issue to discuss). Kanban is designed to provide continuous improvement (Kaizen) rather than incremental, which results in constant planning and review. Since the weekly planning meetings had proved so useful in improvement and harmony I debated their removal for a few days. Ultimately I decided that these planning meetings were a victim of their own success: with each weekly meeting our opportunity for improvement became smaller and smaller, until significant improvements became difficult to come by. Busy product owners stopped attending planning meetings and discussions on ways to improve waned. An hour off the floor for an entire team is at least 7 total person-hours lost, and so the weekly meeting was jettisoned.
Capacities were also an unexpected benefit for our team, but in a non-traditional way. In Kanban, a maximum capacity for each workflow stage is used to limit work-in-progress in order to prevent efficiencies lost due to multitasking and to be able to identify bottlenecks in the system. The maximum capacities we set weren’t extravagant, but they never became an issue.
More important to us was an arbritrary minimum capacity we set ourselves for each column, which became just as important as the maximum capacity . At a glance we could see which stages were underworked and required new input. It soon became impossible for us to run out of articles to publish, because we could predict any droughts many days in advance.
The minimum capacity rule held not only for columns that the team could work on directly (“In Progress, Buddy Check, Sub-Editor Review”) but also for columns later in the workflow (“Editor Review, Stakeholder Approval, Ready to publish). By setting ourselves a target to have a minimum of five articles spread through these three columns, we could be sure there would no longer be last minute panic drives for new content when we were perceived to be running dry.
What didn’t work?
The push/pull distinction that is often cited as a key difference between Scrum and Kanban (Scrum being a push system, and Kanban being a pull system) was not applicable to our team. Likewise Kanban’s removal of prescribed roles. This was because we never had key roles defined in Scrum. I often acted as Product Owner, in the absence of key stakeholders at planning meetings (too busy, or too skeptical to attend). I was de facto Scrum Master also, acting as a classic servant-leader to this team creating, assigning and unblocking tasks. When we transitioned I had hoped that extra autonomy would see team members “pulling” cards (tasks) from the To Do column for themselves as they finished old ones, but more often than not these would need to be assigned during the daily planning call.
It’s possible that my perceived micromanagement of the system meant that the team gave up on finding their own tasks, perhaps they simply weren’t motivated to do so. I like to think that people need and want leaders to make decisions for them.
The self-prescribed 5 articles in approvals minimum had a knock-on effect of rendering moot Kanban’s focus on cycle time as a KPI. However, given the range of complexity of our articles, looking at cycle time as an indication of our success/improvement was never a realistic possibility. We simply knew that if we always had 5 articles in approvals, we were doing a great job.
What did we keep from Scrum?
I always liked the daily call because it meant that nothing could be blocked, without public discussion, for any longer than 24 hours. Public discussion engaged the team with figuring out how this thing could be unblocked, or if not to be able to put it back in the To Do, or On Hold status/column. The board was kept clear of clutter, and To Do lists were not clogged with un-actionable tasks.
We kept the daily call, but turned it from a “what did you work on, what are you working on now, what are your blockers” format to a quick run through every item in the stack. We went from having one large planning meeting to 5 smaller ones each week. The daily call served not only to remove blockers, and promote collaboration but also to remove idle time by spreading the load.
By retaining the daily calls from Scrum, and not taking on cycle time and the pull system of Kanban, our new system could more accuurately be described as a Kanban-Scrum hybrid — a form of Scrumban. I was told by a more senior producer in the early stages of implementing Scrum to stick to the rules for the first little while, and then mould the system to your own needs which is exactly what happened.
Had we started out immediately with Kanban, I don’t believe that we would have reached the system that we did, which the team still uses to this day. The regimented refinement of Scrum allowed for critical analysis and understanding of our process, and for us to find a method best suited for it.