By Sarah Baca | Senior Member
When you look at the basic descriptions of a Scrum master and a technical communicator or writer, you might not see much in common between the two. On the surface, it seems as if technical communicators simply write down what they are told by a subject matter expert (SME) and Scrum masters ensure the team is following the Scrum framework and processes.
However, most of us who have worked as writers know that the technical communicator role is much more than writing down what we are told and making some pretty tables. In the same way, being a Scrum master goes much deeper than making sure a team is following a process. In my role as Scrum master, I have been able to use skills that I gained as a technical communicator, increasing my value to the Scrum teams.
Communication
I used to be a writer on a team with members in development, quality assurance, user experience, and product management. While we were creating software, team members had their own perspectives of the team's goals. We defined as much as we could from the beginning, but there was always more to discover. I worked with everyone on the team to try to determine what our use cases were and how the software should look when it was done. The funny thing was, I don't think my real contribution as a technical writer was the words that I wrote. My main value to the team was what happened when I asked a question and someone would say "Oh wow. I didn't think of it that way." Then off she would go to write a new test or modify the code she had just written. By constantly communicating with everyone on the team about the impact of our decisions on our users, I shifted the team to focus on a bigger picture—a mindset that benefited our users the most.
As Scrum master, I use the same skill set but I get to do it on a broader scale. I'm involved more in the everyday processes, so I can refocus the whole team on our users and the bigger picture more often. Because I'm no longer responsible for writing user documentation, I have more time to help facilitate team communication. I do still use my documentation skills—I just document processes instead of writing documentation for users. I still find that when I get an idea in black-and-white and in front of people's eyeballs, they still have the "Wow, I didn't think of that" moment. But now it's about a process that affects the whole team or even the whole company. Frequently, everyone thinks they are doing things the same way. After I challenge them, they discover they all understood it in a slightly different way. Also, by documenting processes, our team helps those who come after us know how we do things. Clarifying the processes for everyone means we don't have to waste time figuring out how to get things done; we can just get to work.
Connection
As human beings, we all crave connection. One of the traits that makes good technical communicators great is their ability to connect with SMEs on a level that goes deeper than asking the obvious questions. Great technical communicators know they have to connect on a human level so they can learn what questions to ask and move beyond superficial information. When I was a technical communicator, I found I couldn't get the information I really wanted until I had formed a meaningful connection with my colleague.
Once I was on a team documenting a product that was completely new to me. I was having a hard time learning why our user would use the product. We ended up locking ourselves in a room (this is called "team swarm" in the Scrum terminology). While I was talking to the developers about what we were building, we started using the white board and writing out what we were trying to do. Becoming immersed in the problem with the developers, I was able to connect with them as an equal member of the team. They were able to write software with a higher quality and I was able to write documentation that really helped the users of our new product.
Now, as a Scrum master, I facilitate the same connection between all the members of the team. I ask them questions to clarify what they are saying and help them make sure everyone understands. I ask managers to take a step back and allow the team to solve their own problems. I facilitate retrospectives that encourage the team to reflect on what they did during the last sprint and work together to improve. Retrospectives especially are highly valuable. They force the team to pause, assess what is working and what is not working, and improve. Constant improvement creates better software, happier customers, and more profit for the company.
Just as I did when I was a writer, I help teams identify patterns—what common themes are we finding in our problem solving? How can we think outside the box? How can we apply what we know about X to Y? This analysis is also part of what I did when I was a writer.
When we use the Agile Scrum framework, we are operating in a completely new way compared to traditional forms of business. We're shifting from a command-and-control environment to an environment where we have a team of people communicating with each other to find solutions, failing quickly, and getting stronger. This environment is perfect for a technical communicator who is constantly looking for patterns and trying to improve the clarity of communication. By improving team dynamics, I'm empowering my teams to have better communication and more transparency. I'm not only increasing productivity and making people happier in their jobs, I'm also helping create a higher quality product.
Work Management
Another important skill I developed as a technical communicator was to manage multiple projects at a time. Working on multiple teams meant I frequently had content deliverables due at different times, with varying complexity and audiences. I also had to manage the content itself from a large conceptual idea and then narrow it into granular instruction.
The Agile Scrum framework breaks down work in a similar manner. As a Scrum master, I help the team break down large units of work—such as a large feature—into units small enough to execute. Dividing work into smaller tasks is similar to writing good documentation—you make sure you have a standard format, make sure everyone is on the same page, and write it down. You facilitate communication so everyone knows what their teammates are saying and nothing is assumed. Writing down information and using a standard format makes it easier for the team to understand in the same way that it makes it easier for users to understand. The same principles apply for the team. By creating a template and making it clear to everyone what we are building, we build a better product. By breaking the work into right-sized chunks, everyone can pick up a piece, instead of spinning their wheels trying to figure out what to do next. Without breaking the work into manageable chunks, the team is paralyzed.
Authenticity
One of the most personal lessons I learned as a technical communicator was to be authentic. If I wasn't genuinely expressing my frustration, confusion, or excitement, it cheated everyone around me. If I needed help, they couldn't help me if I didn't tell them what was going on and I couldn't do the best job possible without their help. When I first started as a technical communicator, I would pretend to understand what people were saying around me even if I didn't understand. I quickly learned that this practice kept the documentation from being as clear as it could be. Unfortunately, it was really hard for me to admit when I didn't understand what someone was talking about.
One day I came up with an idea to help me feel more comfortable admitting that I didn't know something. My husband is a brilliant engineer, who also happens to be patient and kind. I went into the office and pretended that whichever genius I was interviewing from my team was just like my husband, and I took down the protective layer so I could "keep it real." I didn't pretend to understand if I didn't. Sometimes I even said to them, "Pretend I'm a fifth grader and explain it again." I quickly learned that they were usually happy to explain things to me in a way I could understand. Frequently, it helped them understand the topic better as well.
Brene Brown writes in The Gifts of Imperfection, "Owning our story and loving ourselves through that process is one of the bravest things we'll ever do." For me, this is true—being honest about yourself is painful. Brown writes that the brain perceives rejection in the same area as it registers physical pain. To our brain, being rejected feels like getting stuck with a hot poker. The tricky thing is that if we don't risk rejection, we never grow and we never form the connections that are vital for our survival. I learned that I can't pretend to understand what is going on if I really don't. It doesn't matter if there's a C-level executive in the room or how stupid I look. What matters is that I am true to myself and being honest with those around me. I've known some very talented technical communicators who were so afraid to look stupid that they never dropped their shields and it kept them from succeeding. It's sad because they were never able to reach their full potential, and it was all because of fear.
I use this same skill (being okay with looking stupid) as a Scrum master. I know if I don't understand or if I have a question, someone else is going to have the same question. The person might be a VP who doesn't understand the business case or it might be a team member who doesn't quite understand the product. But if I can be brave enough to show my ignorance, and to allow someone else to have the answers, it can really benefit the team.
Change
I know the move from technical communicator to Scrum master is not for everyone. Becoming a Scrum master has allowed me to use my favorite parts of being a technical communicator and spread those skills to benefit more people. Now that I'm a Scrum master, I can really see myself growing and helping those around me grow. That's the best feeling in the world!
Sarah Baca is the Scrum coach and Scrum master at Pentaho Corporation, a BI/DI software company. She has her degree in technical communication from the University of Central Florida and lives in Orlando, FL, with her husband and three boys. She enjoys being involved in the community so she can teach and learn from others. She is a former vice president and treasurer of the STC Orlando Central Florida Chapter and currently acts as co-leader of Agile Orlando. You can contact her on Twitter at sjbaca3.
