Episode three of Red Hat’s original podcast series, Command Line Heroes, looks at the origins of the agile software movement—how it began at a ski resort in Utah, how it was then quickly adopted by developers around the globe who needed a new approach for creating software and how it is now being applied to other modes of work outside of technology. Darrell K. Rigby, a partner at Bain & Company, talks about this latter phenomenon, describing how agile principles and practices have been adopted by people, teams and industries far beyond the world of software.
As it happens, in the spring of 2016, Red Hat’s global Content team (part of the company’s Marketing Communications team) decided to adopt an agile approach to its work. Nick Heling—a writer on the Content team—had some experience in this area. He stepped in to help guide the process in its initial stages.
We sat down with Nick to discuss how adapting an approach for developing software to marketing worked and how it’s going a year later.
What the heck is “scrum?”
Q: Let’s start with your background at Red Hat. Where did you start and how did you end up in marketing?
NICK: I’m a writer, content strategist and agile coach for Red Hat’s Marketing department—Marketing Communications, specifically. But I started out at Red Hat in the IT department. I was hired to write knowledge base articles and to create videos.
Q: When did you first learn about agile?
NICK: I’d never really had any experience with it until I worked in Red Hat’s IT department. I saw that there was a job title called “scrum master.” And I thought that was the weirdest thing. Scrum master? What the heck is that? So I Googled it. And I saw it’s about rugby, and I couldn’t figure out why my company wanted rugby coaches.
But after a bit more searching, I realized scrum is a way to develop software. It’s a way of organizing your work into a manageable process and for collaborating with a team.
I was working on a project where we were asking a team in IT to make some enhancements to a tool for us. We sent them a list of our requirements and they said, “We work a little differently now. We’re doing this thing called scrum. Can you submit the requirements in this different form? In the context of our user, can you help us think this through?”
We said yes and started working on it. In order to help me do a better job, I sought out scrum master training. I received that here, at Red Hat. There, I figured out what scrum was really about and brought that back to my team. It really helped us in our project. I’ve been using those methods ever since because I really believe in them. I’ve seen them work and I think it’s a smart way for a team of highly skilled people to collaborate.
“What would you do differently?”
Q: So you made the transition to the Marketing team. How did you initially think about applying agile methodologies to marketing process?
NICK: During my interview for this position on the Content team, the director of Red Hat’s Digital Marketing team outlined how things are done for redhat.com, how content was created and she asked me what would I would change. I told her, “I would do scrum.”
I told her that I believed that writing code and writing marketing copy is fundamentally the same. When a programmer is writing code, there’s something that he or she wants to do with that code. If the code works, if it’s successful, you compile it and it does the thing that you wanted it to do. The same goes with marketing copy.
Q: How did the rollout and the implementation of scrum for the global Content team start and how did you proselytize it for the rest of the teams?
NICK: Honestly, at the very beginning, I was terrified. So, I read a lot of books. I read as many as I could get my hands on. I started talking to people, talking to experts. I found a lot of experts in-house, because that’s one of the things we do—we collect experts. Then we started out small because big things always start small. You have to start somewhere. We got two people to run a pilot team.
Q: What was the immediate response from people who were participating and those who were watching?
NICK: The first response was skepticism. People would say to me, “This is for developing software. This method is not for writing. It doesn’t understand me or any of my needs.” I took that critique seriously because very few people, if anyone, were actually doing this for writing.
I thought long and hard about those concerns, and I decided that agile applies to any way of working. You, of course, need to tweak it to your own personal needs and your team’s needs. But that’s the whole point of being agile anyway—you can adapt to change; you can respond rapidly to change. And if you’re not adapting then you’re not being agile, in my opinion. You might be doing scrum, but you might not be agile.
From code to copy
Q: We’re now a year into this experiment. How has it gone?
NICK: After that first pilot team, we started two more teams, and then a couple more teams, until eventually everyone was doing it on my immediate team. That was, at the time, maybe a dozen or more people.
The people who were collaborating with us daily or working closely with us—our project managers, and then some designers, filmmakers, and UX—they wanted to continue working with us, so they ultimately came along for the ride. They’ve been really good sports about it. And we’ve been collaborating fairly closely in this manner.
Scrum helped us see where we were losing efficiency, where things slowed down. We saw that one of the biggest barriers to our efficiency was handing work off from team to team. It slows things down because you have to stop, hand off the work, explain the context and bring the new person up to speed on everything related to the project. Then you have to clearly define what you’re asking from them and put that into whatever to-do list they’ve got. Then you wait for them to finish it and send it back. That way of working is inherently slower. It just has to be.
Q: What happened to the skepticism?
NICK: Oh, the skepticism really faded away. Several people told me they never want to work in any other way. They say that agile is just better. It’s more humane. It’s faster.
“Do the right work. Do the work right.”
Q: What advice would you give other non-software teams about using agile methodologies?
NICK: Often writing is seen as a solitary pursuit. Many times that’s how writers like to get their work done. But collaborative writing is also alive and well, and scrum is a great methodology for collaborative writing, which I personally prefer. Yes, I know there are times I have to sit alone, but sometimes I’m not sure I’ve had an idea until I’ve said it out loud to someone else. So it’s good to have other writers to work with.
Scrum adoption needs to be a two-way street. Managers have to believe in this way of working and advocate for it. Otherwise, the team can’t successfully adopt it. If the team has started a grassroots initiative to become agile or to do scrum, or maybe work in kanban, that will only go so far. Without the endorsement of their managers, they won’t be able to sustain it. Simultaneously, if becoming agile is a mandate from the top, it will not succeed unless the people who are doing the work buy into it. They have to believe in this way of working.
Many of the managers I’ve spoken to are curious to hear about how increased efficiency led to cost savings or helped us ensure we’re doing the right work. You know, it’s important to do the work right, but if you’re not doing the right work, then there’s no point in doing it—you can make a cathedral, but if no one wants this cathedral then it’s no good.
That’s what scrum helps you do. It helps you do the right work, do the work right and do it as fast as you can.