Scrum
What is Scrum?
Scrum is a project methodology for agile. In general, agile embraces shorter iterations of development and continuous integration for releases. Scrum was developed by Jeff Sutherland and J.J. Sutherland, described in their book Scrum: The Art of Doing Twice the Work in Half the Time (which I reviewed here). The basic principle of Scrum is to regularly demo what you’ve created to stakeholders to make sure you’re on track with what they both want and need. The regular demo allows you to course correct early on rather than plodding ahead in isolation from the customer for two years, only to find, after the big product reveal at the end, that you built the wrong features and experience.
Scrum has specific practices such as these:
- Daily standups
- Sprint planning
- Sprints
- Sprint demos
- Sprint retrospectives
Tech writers usually plug into various Scrum teams, but documentation groups can also manage documentation using their documentation Scrums as well. For more details, see Following Scrum with documentation projects.
One of the most popular recordings on my site is an STC Silicon Valley panel discussion on agile: How can technical writers thrive in agile environments? I also wrote a two-part series on documentation Scrums (see part 1 and part 2), another post on How to apply Scrum to your life’s projects, a post on Kanban (which is another methodology for agile), and more.
Why I embraced Scrum
Scrum appealed to me for several reasons. First, if your engineers follow Scrum, then understanding the mechanics, methods, and techniques of Scrum allows you to more easily plug into their rhythms and workflows. For example, you’ll know that sprint demos are important events where you can quickly see demonstrations of features that might need documentation. By looking at the Scrum boards (Rapidboards in JIRA), you can see what work is slotted for the current sprints, allowing you to better plan doc efforts. And so on.
But I also tried using Scrum to manage documentation as well. Scrum isn’t limited only to software development projects but instead can be used as a framework for executing on projects of any type (e.g., weddings, college applications, re-landscaping your yard). Scrum shows you how to break larger projects into small parts, prioritize and plan the work over specific periods of time, and constantly evaluate the outcome of your efforts.
Just as people are often into productivity approaches (e.g., Getting Things Done, the 4-hour work week, Steven Covey, and so on), I was into Scrum for much the same reasons. Additionally, Scrum seemed like a perfect fit for a project methodology because the better I understood it, the better I could work with engineering teams who were also using it.
Why didn’t I abandon Scrum?
I didn’t abandon Scrum, but I watered it down a bit and became much less stringent about applying its mechanics. First of all, not all engineering teams I worked with used Scrum. Some use modified forms of it, or Kanban, or other approaches entirely. If the engineering teams you support aren’t using Scrum, then chances are you won’t use it to manage documentation either.
But even in companies that use Scrum, it’s hard for tech writers to plug into Scrum teams for several reasons, which I elaborated on in Tech docs and Agile: Problems with integrating tech writers into engineering Scrums (Part 1). Briefly, here are some reasons:
-
Tech writers are allocated to too many teams, which then dilutes your bandwidth if you attempt to attend all the Scrum team’s meetings. For example, if you support 3 teams, you have 3 standups, 3 sprint planning meetings, 3 sprint demos, 3 retrospectives, and more (in addition to whatever other meetings your company has). Your productivity gets sucked up by attending endless meetings where the signal-to-noise ratio of relevancy to docs is low.
-
Documentation tasks and team members aren’t often treated the same way. Documentation isn’t usually given points, and if they are, those points aren’t factored into the sprint’s threshold of total possible points. It gets complicated to account for shared resources like tech docs in Scrum. There’s no clear fit for it, and Sutherland is frustratingly silent about how to integrate shared resources in the Scrum methodology. In my experience, tech writers and their tasks seem to be treated outside the Scrum team’s cadence and flow.
-
Scrum teams are often co-located together and rely on conversations and meetings to make decisions more so than any kind of internal documentation. Unless you’re co-located with the engineering teams, you often miss out. For example, the engineering team might hold their morning standup in a conference room that doesn’t have a microphone and isn’t connected to any video conference. But co-locating with engineering teams is nearly impossible when you’re supporting multiple teams and rotating your focus based on different release timelines.
Those are some challenges in integrating with engineering Scrum teams. But what about managing my own docs through Scrum? I also ran into obstacles:
-
Tech writers often work in separate silos, with one writer focusing on docs for project A, another focusing on docs for project B, and so on. There’s no need for daily standups to coordinate work because documentation doesn’t need to be written collaboratively. It seems to work best when a writer has full autonomy and responsibility over an entire project, as that writer can make more holistic judgements and decisions. There’s really no concept of “pair programming” in tech writing.
-
The basic Scrum framework is just common sense anyway. Break large projects down into smaller tasks, prioritize those tasks in regular iterations, and report on your progress each month. This isn’t rocket science. It’s just how you tackle projects. Maybe I’ve internalized the workflow so that it seems like common sense, but it just does. Who doesn’t have a prioritized to-do list that they tackle, with some general timelines for the tasks? A lot of the hallmarks of scrum (the daily standups, for example, or the retrospectives) are baked into general ways of working. In the mornings, I think about what I’m going to do that day. After I finish something, I reflect on how it went.
Even so, I still recommend a Scrum-based approach for managing docs. See my Managing large documentation projects and Managing small documentation requests in my API course. Many of the principles are the same. For the software demos, I recommend sending documentation reports to stakeholders.
Current status
Some form of agile development remains popular, but few teams (in the recent companies I’ve worked for) follow Scrum’s practices strictly. It seems that more and more, project teams adopt their own Scrum variants and workflows, and tech writers operate on the peripheries of these teams.
Tech writing teams themselves generally follow Kanban to manage doc work, but not in a strict sense either. In a general sense, Kanban is just a prioritized to-do list. When you cross off the top item, you unlock the next item down on the list, and so on. Waterfall methodology isn’t returning, but there are plenty of software engineers who think Scrum turns great developers into average developers by injecting too much supervision and reporting, or by focusing too much on closing bugs for the sake of reporting in standups. Others say agile gives users too much authority to direct the project’s direction. Users can be unreliable and short-sighted — if all products were developed based on what users said they wanted, we would only have faster horseless carriages, not cars, says Henry Ford. Truly disruptive innovations (as opposed to smaller, sustaining innovations) usually catch users by surprise rather than fulfilling their requests.
Without any compelling methodology to replace Scrum, it seems that some form of it will remain dominant in software shops for many years to come. Much of the workflow is now baked into issue tracking systems like JIRA. Overall, Scrum isn’t a bad methodology to adopt, and you need some structured approach to tackling projects and managing documentation work. The trick is sticking with Scrum.
Takeaway
Partially allocated resources like tech writers should understand the mechanics of scrum to better plug in with engineering teams, but they shouldn’t expect to participate as full-fledged members of these same engineering scrum teams.
Next post
Continue to the next post in this series: Marcom and techcomm.
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.