Technical Writers in the Scaled Agile Framework (SAFe)

Stephen Hawking once said, “Intelligence is the ability to adapt to change.” Constant change, quick decisions, and regular exchange about current tasks are key elements in agile project management. In the 2017 Pulse of the Profession report from the Project Management Institute (PMI), they concluded that “(…) 71 percent of organizations report using agile approaches for their projects sometimes, often, or always”.

In this increasingly agile-working world, the Scaled Agile Framework (abbreviated as SAFe) helps large enterprises establish agile processes on a company-wide scale. First introduced in 2007, SAFe offers comprehensive guidelines, workflow patterns, and consistent terminology. The framework is designed to encourage collaboration and alignment across a large number of scrum teams.

This is the complete SAFe agile portfolio as of SAFe 4.5:

The SAFe framework considers at least three levels in an organization: the Team level, the Program level, and the Portfolio Level. To find out more about SAFe, how it is implemented and how its components work together, visit the SAFe website.

In recent years, many companies have started implementing SAFe, including Cisco, Philips, the NHS, Intel, and Sony (Scaled Agile Case Studies, 2018). However, any technical writer looking at the portfolio will quickly notice that the portfolio does not mention technical documentation or technical writers – as technical writers, how can we integrate ourselves in this new process?

In one of my SAFe trainings, I asked our trainer exactly this question.

He said that, most probably, SAFe would consider technical writers a Shared Service. According to SAFe, “Shared Services represent the specialty roles, people, and services that are necessary for the success of an Agile Release Train (ART) or Solution Train but that cannot be dedicated full-time.” Shared Services are not part of the scrum teams (called Agile Teams in SAFe), but can support multiple Agile Teams with their skills, as well as other teams on the Program or Portfolio level.

Our technical writing team discussed this solution but concluded that it this approach did not fit our profile one hundred percent. Typical shared functions are only required for one to five features. An example would be the assistance from the User Experience team, which is only required for front-end features.

In contrast, you need technical documentation for almost every feature. The profession includes more than just the writing process, for example the creation of illustrations or multimedia content.
Additionally, although it is a legally required part of the product, engineers might not always understand which features need end-user documentation and which do not. Therefore, it is important for technical writers to be involved from the very start.

Our team tried two different approaches:

1. Acting as an Agile Team
2. Acting as a Shared Service

Acting as an Agile Team

The first approach, acting as a separate scrum team that only consisted of technical writers, helped us immensely in being an active part in the PI Plannings. Since we were a separate Agile Team, we had to present our PI objectives and our goals in the PI Planning. This led to an automatic involvement in the decision-making process, and our Scrum Master was part of the Scrum of Scrum meetings. The presentations during the PI Planning increased our visibility to the management and other Agile Teams.

As an additional factor, the predefined SAFe processes helped to align our own team better. During the PI Planning, we would get a better idea of the upcoming features and could plan for their documentation as required. We also allocated time to internal tasks that were documentation-specific, for example clean-ups. It gave us a forum to discuss improvement ideas for our documentation.

However, we still faced some issues: we now had a lot of planning overhead (for example tracking every task down to the hour every day), we kept running into reporting issues, and it was not the proposed SAFe solution.

Acting as a Shared Service

The second approach, acting as a Shared Service, had its benefits as well: we had less planning overhead since we did not have to plan our activities as meticulously. Instead of planning our own user stories during the PI Planning, we had more time to attend the other teams’ planning sessions.

Although this was the proposed SAFe solution, this approach made our presence during the PI Plannings less “official”. We still communicated with the scrum teams to see which features required documentation, but the Agile Teams themselves had less insight into our planned tasks and often had to ask if we had planned in “their” features.

Integrating Technical Writers into the Scaled Agile Framework

Ultimately, we found there is no one-fits-all solution. My recommendation would be to try out different approaches and see which one works best for your team. Consider these two factors beforehand:

• Your goal: Ask yourself what the issue is with the way things are run now. What is the change you want to see? Our issue was that we did not always have up-to-date information about the features R&D was working on, so we had to make sure we received the necessary input. This worked out best when we were acting as an Agile Team. Your team might have other pressing issues, for example late updates to “done” features, missing updates from the scrum masters, or a general uncertainty about the new processes.
• Your team size: We noticed that for teams with more than two writers, it made sense to act as an Agile Team and have our goals aligned. But after our team became smaller and consisted of only two writers, we had a higher workload and less time for the planning, so acting as a Shared Service team worked best.

Depending on the company, every technical documentation team works differently and scrum teams apply SAFe in different depths. Make sure to inform yourselves well about the SAFe processes and the Scaled Agile Framework to understand where your team can fit into the portfolio.

… and what about you?

Let us know about your experiences as a technical writer when working in agile or SAFe projects – how does your team work together? Have you tried different approaches to get more involved?

Leave us a message – underneath this blog post, on Facebook, LinkedIn or Twitter!