Kanban may be a better fit than scrum when you support large numbers of engineers
Background
During the last STC meeting on agile, I was chatting with a fellow writer about whether agile fit his role at his work. He said that because he supports about 80 engineers, kanban was a better fit for him than scrum.
I wrote previously about kanban here and here. Both kanban and scrum are two different approaches to agile.
The main difference between kanban and scrum is that scrum organizes work into two week sprints, with points assigned to each item. The scrum team is expected to complete a specific number of points before the sprint ends.
With kanban, instead of organizing the work into sprints, you organize the work into three main buckets: to-do, in progress, and done. You limit the number of items in progress to just a few (for example, three). When you finish an item in-progress, you move another item from to-do bucket into the in-progress bucket.
Kanban doesn’t have two week sprints or velocity calculations or demos. It’s simply a means of limiting the number of items (limiting the “flow” through visual cards) so you can focus more clearly on completing items that need focus. It’s a way of avoiding the scatterbrained feeling of working on 5 tasks all at once and accomplishing nothing.
Kanban is a better fit for me because of my work environment and content publishing role. When I worked at 41st Parameter (a startup bought by Experian), I was tightly grouped into two engineering teams and attended their daily standups, sprint demos, retrospectives, and other scrum meetings.
At Amazon, I support a large number of engineers working in the Appstore group. I’m not sure how many engineers are actually in the Appstore group, but for my focus with Fire TV, there are more engineers than I can know and keep track of.
Some teams work on features that require documentation, while others don’t. For those that do, often the groups will generate the documentation on an internal wiki page, and I’ll convert the content into formal documentation and publish it on our Developer Portal.
In addition to this content publisher role, I am loosely integrated into one scrum team where I author original content from scratch. Although the team follows scrum, I’m finding that it’s better for me not to participate in all the scrum activities but instead to keep my ear to the project and pop in and out when there are features requiring documentation.
At large companies, or in scenarios where small numbers of tech writers support vast armies of engineers, it might not be practical for tech writers to integrate tightly into the scrum teams as other engineers do. If you have to support 5+ scrum teams, your week’s bandwidth will be consumed by meetings that have a low signal-to-noise ratio, and little value for the time expended.
Much of an engineering scrum team often gets caught up in engineering tasks that don’t actually impact the documentation, since the code doesn’t get exposed to users nor does it affect users in ways that would require documentation.
For example, a user may not care about the inner workings of Feature X – the user just needs to know how to configure Feature X. But engineers will spend 80% of their time building Feature X, and talking about bugs they found in testing Feature X, and the best libraries and approaches for integrating Feature X, and so on. The writer needs only to come in at the end to describe Feature X and explain how to configure it. Would it really be efficient to attend meetings where engineers discuss at length how to build and test and deploy and troubleshoot Feature X?
If you’re not regularly involved in an engineering scrum, you need another way to stay abreast of what’s going on, so you won’t miss those times when something does actually come up that requires documentation. I’ve found it’s helpful to establish contact points with key players who have their pulse on important features to document. The key players should understand what various engineering teams are working on, when the release dates are, and who you should contact to get more information. Regular meetings with these key players around documentation priorities and needs can replace the need to attend countless scrums.
One of the key benefits of agile is that it gives you deadlines to [try to] finish your work. Your goal is to complete the task before the sprint closes. While deadlines are generally a good thing, this two-week sprint model has some problems:
- You either finish your task early and have idle time (rarely the case).
- You don’t finish your task and then feel bad for not completing your target.
Most teams over-estimate the amount of work they can complete during the sprint, not properly factoring in the overhead of corporate email, meetings, and other interactions. As a result, usually teams over-allocate the work and then feel bad about themselves when they don’t meet their goals. Project managers get upset and try to “unblock” what might be causing the slow-downs. During these time crunches, engineers then don’t have time to review documentation because they’re heads-down trying to meet their over-estimated sprint goals.
Kanban doesn’t impose deadlines. Theoretically you could spend an eternity working on one task that always remains in progress and never moves to done. But the reality is that you work on items with a regular cadence, and finish them when you finish them. You don’t feel the let-down when your sprint ends and you haven’t finished all your tasks, because you don’t have sprints. Instead, you just keep cranking away at those tasks in the to-do bucket.
I’m not a kanban expert, and I have plenty of room to improve my role. JIRA has the ability to configure kanban boards instead of scrum boards, which I think might really be a better fit for documentation.
My role has certainly shifted from the tech writer who writes everything to the tech writer who publishes everything (and writes original content only for some products). I like the hybrid role, as it gives me exposure to a large number of technologies. And I feel that playing the content curator/publisher role allows me to scale. Still, it’s an interesting new dimension to my work. With this role, it seems that kanban is a better fit for me than scrum.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.