National Geographic: How to Implement Agile Processes in a 127 Year Old Magazine Tradition

About this Publication

National Geographic’s Digital department was using processes that are traditionally more print focused. Through constant evangelizing, training, and using what we had, a group of us took NG Digital through an Agile transformation redefining roles, making new friends, and a lot of inspection and adaptation.


What do you get when you mix a magazine that is 127 years old, scrum training, a small team of designers, programmers, producers, photo editors, and a scrum master, and tell them to build mobile-first? You get a transformation. National Geographic’s digital designs were deeply rooted in the magazine, as were many of the processes, but it was time for a change. Here’s how we went through the transition from print-first to mobile-first, the ups and downs, and the continued learning of how to work together in a collaborative, transparent, and iterative way.

2.      Background

National Geographic Magazine’s first issue was in 1888. I joined the company in 2014. I was hired by Keith Jenkins, who at the time was the Executive Editor in charge of and its digital platforms and versions. The good news was that the digital staff is as deeply committed to quality journalism and storytelling as the magazine staff had always been. The not so good news? Digital was run using waterfall project management with a steep staff hierarchy.

I was brought into NG Digital with a list of goals: bridge the gap between digital content and digital technology, break down silos using Agile methods, and transition the editorial and design staff processes to Agile and Scrum.

I had just left NPR’s Digital Media division after six years as a Scrum Master and built almost half of their digital products over that period of time. I had spent the first 13 years of my career in print production departments and the last 20 years managing digital production departments and as a scrum master in digital so I felt I had enough experience to bridge the two.

3.      My Story

When I first joined National Geographic, June 2014, all I did was watch and listen. I didn’t have a staff, which was great, I talked to everyone. I knew a group of folks already at the Society from previous jobs and talked to them first, I listened and asked a lot of questions. And I talked a lot about Scrum and its culture and the mindset of Agile.

I was most closely aligned with the Web Producers. I had worked in and managed production departments my entire career and knew the pitfalls of being the last in the production line, in other words, where the buck stops. I talked to them a lot. We talked about how they felt, who they worked with, and how they worked

Design, Editorial, and the Photo Editors worked in the 17th Street building and Product, PMO, and Technology groups worked in the building across the courtyard. I made it my goal to have at least one meeting a day in the building across the courtyard.

I found out that the departments in the two buildings rarely talked to each other. Some staff who had worked there for years had never met their colleagues and communicated only by email.

Keith, whom I mentioned above, also came from NPR. Around June 2014 he implemented daily scrums for the different groups who reported to him. He setup a daily photo department scrum along with a combined daily scrum for the design and production departments who, as far as I could tell, did not talk to each other on a regular basis. I attended the design and the production scrums. I explained the three questions and the goals of a daily scrum, but folks were doubtful of why they should do this. They thought it was a waste of their time. We kept at it. Daily we answered the three questions and identified issues to discuss after the scrum.

At around that time a two-person team of programmers were officially formed to work with the Design, Editorial, Production, Photo departments, to build special online versions of some of the magazine features every month. They are called the ISP Team.

The building across the courtyard said they were running teams using Scrum. There were 15 Product Managers, with varying degrees of Scrum experience, who pitched projects, and worked with remote development teams running projects using Scrum and Kanban.

Between June and December we continued to Scrum and the ISP team started to work on the magazine features. We asked them to attend the Scrum. They sent one representative to the daily stand up. We kept at it. I continued to talk about Scrum and collaboration and communication. Sometime that summer I called my Scrum trainer, Jim York, who had trained the NPR staff, and set up two Scrum training sessions for the group at National Geographic. Each session could accommodate 30 people, which meant I could invite 60 people to the training.

I invited a cross section of staff to attend; all of Production, Design, UX, and the ISP team would attend. Some Photo Editors, a couple of Product Managers, a couple of Scrum Masters, a magazine interactive Designer, a Programmer, a digital maps Designer, and, at one session, a separate table which included several senior print staff; I thought I was making progress. In all, 56 staff attended the two sessions.

At around this time Keith was promoted to General Manager of Digital and I started managing the Web Producers. And we all moved onto the 4th floor in the building across the courtyard. The 4th floor had been transformed into an open workspace with cubes, meeting spaces, and big windows. It was great. The Technology, PMO, Product teams were on the 6th floor, but at least we were all in the same building.

The team I now managed, the Web Producers, had been through a variety of changes and managers over the years and it took its toll. There was a legacy process in place; the Web Producers had been, at one time, a service department to the organization. They were no longer, but most of the work produced still went through them. Most of the tools and processes in place were set up requiring the Web Producer to touch the content one way or another.

I sat in a cube along side them and we talked about Scrum. I talked to them about Scrum values: commitment, focus, openness, respect, and courage. I talked about the power of respect constantly. Every week, every day. Everything we did was an opportunity to talk about communication, collaboration, transparency, priorities, and respect. We talked about what it means to be a product owner, how to own the business vision, owning a backlog, prioritizing the work; and the scrum skills of shepherding a team of people toward the vision, inspecting and adapting the process at regular intervals; and how we can all work together in a respectful way. Agile and Scrum was new to them.

I should mention, at the end of 2014, the PMO assigned Matt, a terrific Scrum Master, to this fledgling group. I could not have transformed this group without him. Matt, and Bethany, who is the digital editorial design director, and I talked daily about how this was going to work. Bethany had worked at NG for years; I talked to her endlessly about Scrum, had sent her to the training, and Matt and I encouraged her to use Scrum on upcoming projects.

Meanwhile I had been talking to the Web Producers about servant leadership and respect. The ownership of the work rests within the team and is prioritized in the backlog and not from a clipboard with a predetermined timeframe. At the same time, the Technology group on the 6th floor asked if we could assign a Producer to all projects, not just the production of the work, but as a checkpoint for deployment for the technical work produced on the 4th floor. Something good was happening, something was changing.

No one other than Matt, the one Scrum Master, had been assigned to us from the PMO, he was by default assigned to everything we were going to build using Scrum on the 4th floor. It was time to change the role of the Web Producers, it was time to expand their role and contribution to the Agile transformation. It was time for them to become Product Owners.

It’s now January 2015 and I’ve talked about Scrum and Agile culture to everyone I could, including management and staff, for the six months since I arrived. They had gone through Scrum training, and with me as their coach, and Matt the Scrum Master, we built the first magazine feature of 2015 with the ISP team using the scrum framework. The story was Healing Soldiers.

This was the first project using a cross-functional team working together within the Scrum framework. Janey, a Web Producer, was picked for the new role of Product Owner and Bethany art directed it, but chose Kevin, a magazine tablet designer, to design it. They, along with the ISP team, the Photo Editor, me as coach, Bethany who led the design, and Matt adapting the Scrum framework, started our first Scrum cycle.

Janey, along with the team, documented the project need, goals, and defined measures of success. Matt recommended that the sprints last one week. We created the backlog, scrummed daily, held a sprint review every week, and ran through a couple of retrospectives.

The project ran exceptionally well online and on mobile. Page views and social shares were extraordinarily high for this project and it ended up to be one of our most popular stories from the first half of 2015.

Some groups took longer to accept the transition of the Producers playing a leadership role. The print Design team struggled handing off ownership of a print story to the Producers which was required in this new process if it was going to get built out by the ISP Team.

Bethany, and several other managers, suggested she and I go around to all of the departments on the 4th floor and run through the Scrum process with those whose time and assets we would probably use one day if we built their stories using Scrum. I created a one-hour Scrum presentation where I introduced the basic concepts and vocabulary so that our colleagues were familiar with the terms and process when we went knocking at their doors.

Bethany had worked for the magazine and knew everyone well. She and I went from department to department of magazine staff explaining how Scrum works. I walked everyone through the Scrum process  and she drew corollaries for them as a way to bridge the two approaches. Some of the staff were excited by it and others considered it quite foreign. I think most thought it wasn’t pertinent to their work on a day to day basis.

We continued building our ISP projects. In February we built Trajan’s column. April we built Detroit. Now the ISP team is working on a grant funded project that is digital only and not associated with the magazine. Later this year, we’re going into production with a variety of projects at once, and we’re setting up a Scrum of Scrums to coordinate resources, manage potential conflicts, and collaborate on shared technical needs.

One of the Web Producers, Chis, has been assigned to two projects; one is an official 6th floor scrum team and the other is a project, also using magazine and daily content components, waiting in the wings. The 6th floor is required to use Jira, a Scrum and Kanban ticket management system, and typically writes well formed stories to drive their sprints. Chris has now been exposed to the process and has embraced it, and has cards at his desk on which stories are written. He wrote stories for the project that is waiting in the wings and says he’s learned a lot and has “got it.”

Still, what I’ve noticed, is that some folks continue to cling to “command and control” management and that the concept of servant leadership is not yet internalized. Even my colleagues who are writing well-formed stories, prioritizing work, and sticking to the sprints still “run” the project, tell the team what to do, and occasionally take over without knowing it’s what they’re doing.

Language is very important when moving a team through a transition. It’s essential to use the correct language, take the effort to define and redefine the language, and break down the jargon. Many of the buzzwords used at NGS, were just that, buzzwords and misrepresented the real intention of the concept. Examples are mobile, big web, and digital native along with many others. I stopped using those terms, and others, and instead spent the time using the definition instead of the term and often suggested alternatives when others used them.

One of the most overused and ill-defined terms is mobile. It’s no longer clear what the term mobile means. Laptops and watches, and every size in-between, are mobile. One of my colleagues suggested using the term small screen when referring to a phone. Since then I am better able to describe the size of the screen. This has made a considerable difference, now we refer to the size of the item, small screen, tablet, desktop, when considering a project or an implementation. Even though we have 21-inch monitors, the largest size we should design and test on, in my opinion, is a 15-inch laptop.

4.      What We Learned

It’s now been a full year since I joined the staff of National Geographic. I’ve run retrospectives through a variety of departments, past projects and teams, and the projects mentioned above. Many have since happened without me.

In many of the retrospectives I heard the same thing: unclear role definition, who’s in charge, unclear expectations, how to work together, the impact of MVP, and the impact of the definition of done. I think role definition and definition of done were expressed the most often as problematic for the teams. Done means something different in print; staying late until the work is done, until the print product is perfect. Done, in Scrum, takes on a whole other meaning.

During a sprint using Scrum, the team makes the best decision they can with the information they have at the time. In print, one also iterates, similar to Scrum, but iterates with the entire project up until the last moment. All parts of a project, large and small, are open to changes at any time. When Matt, the incredible Scrum Master, implemented our Agile processes, he imposed the final deadline two weeks before it was scheduled to go online. We intentionally did not work until the very last minute. We encouraged team members to slice the work up into sizable chunks, pulled from a project backlog, working on the highest priority items first. These were new concepts for my colleagues.

Changes invariably arose after the project was built and the final changes were made, I believe a leftover behavior from print, though it also was a symptom of how the Scrum process was still not clearly communicated. The ISP team had already moved on to the next project and Matt and Bethany attempted to explain to our colleagues that anything they changed at the last minute would impact how much the ISP team could get done on their next project. We’re not going to work until the last minute, we’re going to make decisions the best we can, it will be good enough and not perfect. We will not get to everything. Again and again I found myself saying, what are the fewest components needed to tell the most compelling story.

It sometimes fell on deaf ears. These were big conceptual changes we were attempting to make to a 127 year old magazine tradition. It took months of learning that we need to work collaborative with our colleagues in print when we’re expected to use print assets in digital; that we work together toward a shared vision; that we work collaboratively; and not to get too emotionally involved in our assets because the goal of iteration is to sometimes let go and keep going. That Done means Done. Wow is that one hard.

Of course we’re still learning. We’ve garnered so much enthusiasm that Matt negotiates almost daily which projects the ISP team will work on and how much time they will have to work on these projects. The concept of done is now even more important. How to identify and embrace the reality of when and how a project fails and that it’s not considered a failure, but a way to limit waste and indicative of the time to pivot. We’ve implemented Scrum of Scrums for one of our projects. We’re verging on incorporating Lean concepts, such as Build Measure Learn and lightweight testing within the sprint, as a way to inform future sprints.

5.      Acknowledgements

First of all, I want to thank all of the NGS staff to whom I talked about Agile, and Scrum, and their patience when I got on my Agile soapbox. I still get on my soapbox, but I’m no longer alone in the transformation.

There are a couple of people I would like to thank. First and foremost it’s Keith Jenkins. Who knew? I’m guessing you did and truly, truly appreciate you for it. Then there are my two fearless colleagues who bravely went toward the Agile flame when I lit the torch. Matt was already doing it, but Bethany was a warrior forging ahead into a dark forest. I could absolutely not have done this without the two of you. Then there’s the group of Web Producers to whom I pitched the idea and dragged willingly or not into Agile. You guys made this all worth it. Finally, my shepherd. We both wish I was better at deadlines. Thanks for all of your help, Tim.

About the Author

No bio currently available.