Let's take a look at the scrum methodology from a technical writer's perspective!
If I had to describe scrum in one sentence to someone who never worked in scrum, I would say something like: Scrum is a way to manage projects where a team works in short bursts (called sprints) to tackle tasks, review progress, and adjust as needed between these sprints. In a real-life conversation, my thoughts would most likely be more scattered (and might use a touch more profanity), but I think I'd come up with something similar.
This may seem like a simple concept, but as all teams are different, all teams adapt scrum differently.
My personal experience with scrum
I first encountered scrum almost nine years ago. At that point, it seemed like a catch-all solution. In my mind, I imagined a scrum team as a superhero team of sorts, people who can be deployed anywhere to solve any problem. The scrum trainer filled our heads with promises of grandeur, and I was hooked.
To be honest, we first started out using kanban, another agile methodology, with WIP (Work In Progress) limits to visualize our work for our project manager. Afterward, we rotated toward a mix of scrum and kanban. We jokingly called our kanban master “scrumban master” (sometimes “scumbag master,” all in good spirit though, as we really liked him, but we really found the term funny). We moved to scrum after using kanban and scrumban for a year or so.
We had 12 people in our scrum team (a lot more than the originally intended 5–6), and we had the following "rituals":
- Daily 30-minute stand-up meetings at 10.30 A.M: In these meetings, we shared our progress and informed our team members what we would be working on that day.
- Bi-weekly sprint plan meetings (1-2 hours): We had this meeting at the beginning of a sprint. A sprint lasted for 2 weeks. Here, we planned what we were going to work on during the 2-week sprint period.
- Bi-weekly sprint retrospective meetings (1-2 hours): This meeting closed our sprint. We gave some arbitrary points to rate our sprints from one to five stars, based on how much we achieved, how much we enjoyed the sprint, and how much we learned. We also discussed what went wrong and how we could avoid those issues in the future.
I never really questioned scrum at the time. It worked for me. I was progressing with my tasks quickly and relatively easily, and it gave me a sense of progress in my work. We had already been using scrum for about two years when I first started to look into it from an objective perspective.
After two years, we had about three regularly occurring meetings in addition to our scrum meetings. I won't go into too much detail, but that amounted to about three additional hours of meetings every week. So at that point, we had 2.5 hours of stand-up, 1.5 hours of sprint plan or sprint review, and the aforementioned three hours of additional meetings. So in total, we had seven hours of recurring meetings every week.
Now imagine that overhead, and try to look into it from the perspective of a project manager. We had about 70 technical writers on our project at the time (yes, I know it might sound insane, but it was a huge project). That's 490 hours, or let's just round it up to 500 hours of meetings every single week. Creating documentation for a new functionality takes about 100 hours of work, so you could create documentation for five new features in that time. You could also count it in FTEs (Full-Time Employee). If you chose to eliminate these meetings, that would amount to 12.5 additional people on your project. That's a huge number. If we focus only on scrum, eliminating the additional meetings and only counting the scrum meetings, that would still amount to 7 FTEs.
Now let me ask you the question I asked at the time: "Do we benefit from scrum enough to offset the work of 7 people?"
Is scrum worth it for technical writers?
Well, so far we’ve only mentioned the recurring meetings as time spent with scrum, and we haven't even touched the backlog. Some sort of backlog management will always have to be used, regardless of the chosen project management methodology. Sticking to one project management structure like scrum ensures that all people use the same methodology to manage their backlog.
This comes with a set of advantages. Perhaps the most important advantages are transparency and the ability to synchronize work between different teams.
However, like most things in life, it comes with its own disadvantages as well. Some people just do not take to the backlog-management software very well (be that Jira or Hansoft or any other tool). Using a rigid system to manage the work of all people at a company can sometimes feel like trying to fit every shape into a square hole.
Backlog management itself takes up a good chunk of worker productivity. Creating sprints, tasks, breaking up tasks into smaller chunks, preparing for agile ceremonies, moving tasks from to-do to ongoing, from ongoing to review, from review to done. It all takes time. Weekly, this can take as much as 2–4 hours.
Perhaps my biggest gripe with scrum is the concept of accountability. People (mostly managers) wrongfully assume that accountability somehow magically appears if a team starts using scrum. Based on my experience, good employees are accountable for their work regardless of the project management setup, while bad employees will always find ways to stave off accountability in any way they can and exploit the system. In some cases, scrum can work like any sort of bureaucratic system and smudge the lines of accountability. Who is accountable if a sprint fails? Is it the project manager who added a task late to the backlog? Is it the scrum master who misjudged the amount of work needed to be done for a release? Was it the technical writer who slacked off? The list of people and mistakes can go on ad nauseam.
Truly, the biggest question to ask is: which is more useful, productivity or readily available metrics (i.e., transparency)? To answer this question, it's not as simple as "if you use scrum you will lose productivity and receive metrics." Despite losing worker productivity, in this case technical writer productivity, you free up management productivity. If your business benefits from losing some technical writer productivity while gaining manager productivity, then scrum might be the right tool for your business. On the other hand, if you are struggling to meet deadlines, another project-management framework might be better for your technical writer team.
Unfortunately, I've found that while working as a contractor, showcasing the right metrics indicating that the team is working, however sloppy that work might be, is better than actually putting in more hours and producing better quality. This might sound appalling at first, but since the customer didn't have any real metrics to measure the quality of the work, the added transparency from scrum ensured smoother cooperation. All the customer cared about was that the work was always progressing well and that they could check the numbers themselves easily.
This is completely different when you are directly employed as a technical writer by the company creating the product. Using scrum there would just create an overhead that would be better spent creating improvements and measuring actually useful metrics, like Google Analytics and feedback from the customers (readers). If you need to have transparency for your directly employed workers, I think you either have micromanagement issues or you hired the wrong people. The existence of a board of directors and shareholders of a public company can, of course, heavily influence the decision here.
Why can scrum feel weird?
Technical writing is a support function accompanying product development, which can be hectic. Work items can be canceled, requirements can change, priorities can shift. As technical writers, it's our job to help development teams deliver a product on time with documentation that enables the end user to use the product without frustration. If the project-management system in use hinders this objective in any way, such as the inability to change sprint plans, we can safely say that the system is ill-equipped to ensure smooth cooperation.
Scrum was originally created for software developers. In software development, developers write code tied directly to sprint-defined features.
Technical writers work on many different features at once, usually even for different product areas. A single technical writer might be creating a specification for an antenna, an onboarding guide for entirely new customers, and a tutorial to set up a new feature in an existing telecommunication network. We also have to mention that technical writers rely on several other factors, including:
- Features to be stabilized
- UI elements to finalize
- Legal team to ensure compliance with different countries' legal requirements
- Developers and product managers to explore edge cases
These can all delay technical writing work far beyond a single sprint cycle.
Another important difference to highlight is that technical writers rarely work on the same document, the same feature, or, in extreme cases, even the same product. Learning what other team members are working on rarely provides any useful insight, and more often than not, it simply serves as a direct information stream to the scrum master rather than to the rest of the team. Setting up an asynchronous information-sharing channel could potentially cut out 25 minutes of meetings for each technical writer daily.
Some sort of planning is mandatory, but we must ask the question: is scrum the right methodology to perform said planning?
A world without scrum
It's important to remember that scrum is just one project management methodology among many others.
I don't think we ever called it anything, but one of my workplaces, where I was with another technical writer solely responsible for documentation, would most likely fit into the Lean framework. The workload would have required at least one additional technical writer, so we had to prioritize some tasks over others. We did this by analyzing customer feedback and acting on it. We sacrificed some transparency for more productivity and only focused on customer value.
Meeting-wise, we had one one-hour bi-weekly meeting, and that was it. Our manager didn't waste their time trying to figure out what we were doing every single day. He focused on only the most important tasks. We defined goals together for a quarter (3 months) and reviewed the progress every two weeks.
I'd like to highlight the work of our manager there. He did something that showcased the importance of a great manager. I'd only been on the project for six months at the time, and the senior colleague had to take a vacation for a month. My manager then reached out to all product managers, asked them to prepare the absolutely business-critical features for the month, defined stakeholders, goals, and points of contact. He then sent me every single work item neatly packaged into a pipeline. He also informed all departments that I would be working on my own for the month and urged people to leave me alone during this period with anything that might distract me from my work objectives. Using this method, I could go through the month without ever having to put in overtime. Now that is what a good manager and a good project-management framework look like. I always imagined how much work would have to have been down-prioritized simply because of the need to use scrum.
To agile or not to agile
I might come off as overly critical of scrum, but I want to re-emphasize that I'm not against it. What I'm against is using scrum as a one-size-fits-all solution and losing valuable business hours to an untouchable process treated like gospel.
Also, I'd like to remind everyone reading this post that the most important thing is to always ensure that your project-management methodology is tailored to the needs of the customer and to the teams using it.
If your customers are essentially the end users (readers), choose a methodology that benefits them. This could mean throwing agile out the window and focusing on delivering a product (documentation) of better quality.
If your customer is a big company looking for transparency, choose a methodology that ensures they get all the metrics to make informed business decisions and the ability to coordinate work between numerous teams.