We talk a lot these days about how important it is for media organizations to be agile in the face of a rapidly shifting media landscape. And when I came to NPR in February 2010, I thought I knew what that meant.
I’d read the Agile Manifesto and its 12 corollary principles. I’d used 37signals products like Basecamp and Campfire, and I dug the company’s book, “Getting Real.” To me, “agility” was the enemy of formality. It meant doing away with processes and meetings, embracing the casual and chaotic.
But what I’ve found working in NPR’s Digital Media department has been a surprisingly rigorous, disciplined approach to product development. Not only have we not done away with meetings, we actually have regularly scheduled meetings to discuss the meetings. And it works. Agile development, along with a flexible approach to serving content, is what allowed us to launch an iPad app and a tablet-optimized HTML5 site the day the iPad was released, for example.
When I hear the word “agile,” I often hear two things being conflated:
- the adjective — the general idea of being more nimble, lean and iterative, and
- the noun — a concrete set of methodologies for how to structure product development.
Everyone agrees on #1. But I rarely hear us talk about #2. Yet I think Agile (the noun) has done wonders to create a highly productive, innovative work environment here at NPR. And I think these methodologies could be usefully applied to many aspects of our work, including journalism.
Let me come clean about something up front: this post is not a humblebrag. It’s a straight-up brag. I both work at NPR and genuinely admire how digital product development happens here. I think our implementation of an Agile methodology is solid, and I’d recommend it to other teams and organizations. Heck, I’d recommend it to other teams and departments within NPR. But because I’m about to give a shameless plug for a part of my company, I’m going to share some of my shame first.
How I used to develop products
In 2005, I started working at the Minneapolis Star Tribune as a deputy Web editor. My first big job was to build an arts-and-entertainment website, working with a wonderful designer, a few excellent developers and a small crew of editorial and business staff who were developing a printed weekly tabloid alongside the site.
Before I arrived in Minneapolis, the Strib had conducted plentiful research on target audiences and their needs, and sketched out the beginnings of a requirements document for the site. Our task was to flesh out those requirements, deliver a compelling vision of what we could create, and then execute it.
That’s exactly what we did. I assembled a swirling mass of ideas into an ambitious, cutting-edge website concept, which I presented to our executive stakeholders. Once we got the thumbs-up, I worked with our product team to turn the concept into a detailed set of functional requirements — a long list of features that could be placed on a Gantt chart and completed one by one. After more than six months of design and development work — including plenty of delays and time underestimates — we’d completed enough features to feel comfortable launching. We previewed the site with the stakeholders, and then released it to the public, “in beta,” as one did in the mid-2000s.
In many ways, Vita.mn was a success. It celebrated its fifth anniversary in 2011. But if I knew then what I know today, I’d never run a project the way I ran that one. The moment actual users started getting their hands on the site, they instantly exposed critical flaws. Some of these flaws took a lot of precious time to correct, and some couldn’t be corrected at all.
I had unwittingly employed a product development methodology folks call “waterfall” development, and I had independently discovered some of its biggest pitfalls.
How Agile works
We call the type of development I describe above “waterfall” because the phases of the project all cascade in one top-to-bottom direction: from drawing up requirements to designing the product, all the way down to launching and maintaining it. (Think about the way a Gantt chart flows down from one step to the next.) Visualizations of Agile processes, on the other hand, almost always depict a cycle; a continuous loop.
If we’d developed Vita.mn with the four main tenets of Agile in mind, we’d value “working software over completed documentation.” That means we’d take the time we spent on producing a lengthy requirements document and we’d use it to build the skeleton of the site instead.
We’d try to get a bare-bones version of the product into the hands of a prospective user as soon as possible, to start gathering feedback on how we could improve it. This likely would have identified the flaws that didn’t reveal themselves till launch. We’d value “individuals and interactions over processes and tools,” which means we’d figure out what we needed to do each day by talking with one another, rather than picking the next item on the to-do list.
But beyond those principles, which are broad enough to keep us in agile-the-adjective territory, there are more specific product development frameworks with names of their own. NPR uses a framework called “Scrum.”
While I’m proselytizing for Agile, I may as well just encourage you to think about it like a religion. “Agile” and “waterfall” are different flavors of product development, just as Buddhism and Christianity are different religions. Within Agile as in Christianity, there are different denominations — such as Lutheran, Baptist and Methodist — that reflect different interpretations of shared texts. Scrum is one of those denominations, and it’s the one we use at NPR.
How NPR uses Scrum
To get a better perspective on our product development process, I spoke to three of my colleagues who’ve had pivotal roles in engineering and executing that process — Constance Miller (senior project manager), Sarah Lumbard (our senior director of product strategy and operations), and Patrick Cooper (senior product manager for NPR.org).
I think the Wikipedia page for Scrum describes our implementation of it pretty well, and includes a few more details about how it works. But there’s also a lot of potentially intimidating Scrum-speak, so I’ll sketch it out for you.
The calendar
Our whole product development division — which encompasses design, user experience and software development — splits the calendar into a series of two-week blocks, or “sprint cycles.”
Each project we undertake is allotted a certain number of cycles and a unique mix of staff members (usually representing the skills of design, user experience and software development) to form the product team. At the end of each cycle, groups of stakeholders convene to review the work the team has completed. Once a project is done, the members of the team disperse to begin new projects.
Each cycle includes a number of meetings that typically happen at a consistent time and place in the cycle. There is, of course, the daily scrum meeting from which the process gets its name, held to a tightly choreographed 15-minute maximum. During the daily scrum, everyone on the team answers exactly three questions: 1) What did you do yesterday? 2) What are you working on today? 3) What are your impediments?
There is a sprint planning meeting at the kickoff of the cycle to write “stories” and apportion them. (Units of work in Scrum are called stories, and have a consistent syntax: “As a X I can X so that X.” For example: “As a user, I can save calendar events so that I can keep a customized calendar.”) There’s a demo at the end of the cycle for stakeholders to review the work. And there’s a retrospective after the demo for the team members to review how the process worked (this is what I cheekily described up top as the meeting to discuss the meetings).
The roles
Scrum teams feature three roles — a product owner, a Scrum master and the product team. The product owner represents the “voice of the user.” This person is responsible for answering any questions that come up in the course of the team’s work, prioritizing the team’s work, and deciding when that work is completed to satisfaction. The Scrum master safeguards the process described above, removing any impediments that team members face.
The team, of course, is responsible for deciding what work to do and collaborating to get it done. Scrum places extraordinary emphasis on the importance of the team, its autonomy, and even its physical proximity. “The dynamics of the team are as important as the problem you’re trying to solve,” Miller said. The team collectively writes the stories they’ll work on during the cycle, estimates the amount of work each will require, and collaborates closely to complete the work.
Outside of the Scrum team, there are various organizational stakeholders who inform and review the team’s work. Most notable among this group of stakeholders is the “executive sponsor” who stands behind the process and helps to insulate it from outside tinkering.
Three key takeaways from Scrum
Both the product and the process need owners.
For Scrum to work, Miller said, there has to be a development team, there has to be a product owner, there has to be a Scrum master, and none of them can share these jobs. The separation of the roles of product owner and Scrum master strikes me as a particular novelty. It means there’s someone whose main job is looking after the product right alongside someone whose main job is looking out for the process. These two tentpoles of the product team serve as a check and balance on one another.
This implies — quite astutely, I think — that to have a truly iterative approach to product development, you’ve got to iterate the process too. You have to put real thought and effort into optimizing how the team communicates and collaborates. That’s why there’s a meeting about meetings.
The team must be self-organizing, autonomous and deeply collaborative.
Scrum grants teams an extraordinary amount of independence during the cycle. It forces stakeholders to cede a good degree of control over the project, Lumbard pointed out. In some implementations of Scrum, stakeholders are allowed to come to the daily Scrum meetings, but only to observe, not to talk. During the two weeks the team is working on a cycle, they’re empowered to produce the solution they think is best without the meddling of outside forces. They’re also empowered to focus all their attention on the project at hand without being pulled into other efforts, and the Scrum master is there to ensure this.
At the end of the cycle, stakeholders have the option of not accepting the team’s work. This happens, Lumbard said, and it must happen, although it’s painful for everybody. But only two weeks of work are at stake, rather than the many months that might be involved in a complex waterfall project.
Also, most members of the team have a diverse set of interests, Patrick Cooper pointed out to me. A product development framework that isolates the role of each person on a team to his or her area of expertise doesn’t make use of that person’s full range of knowledge and curiosity. By encouraging joint ownership of a project, Scrum engages all the relevant interests of each team member, Cooper said, like the designer who loves writing and has good opinions on the editorial direction of a project.
The team must be able to communicate fluidly and transparently.
That daily 15-minute meeting is one of the smallest aspects of Scrum, Lumbard said, but it makes a big difference. Much of the success of Scrum comes from greasing the wheels of communication, putting team members close together enough that “you can just yell for a piece of gum,” as Miller put it. And conversely, as Cooper told me, things break down when you’re too focused on milestones without communication.
That doesn’t only include communication within the team, either. Product owners have to be diligent about communicating to stakeholders, and teams should be able to eavesdrop on one another’s progress as well. Meeting notes, wireframes, and other project-related assets are all stored on an internal wiki, where anyone can dip in and see the latest updates on any project in a cycle, or what’s ahead on our project roadmap.
The case against Scrum
I’m going to stop proselytizing for a minute and argue the opposite case. Here’s a set of reasons from my NPR colleagues why you shouldn’t use Agile, or Scrum:
It makes you do less. One of the 12 principles of Agile says, “Simplicity — the art of maximizing work not done — is essential.” Scrum demands that you pare down the potentially infinite list of to-dos for your project into an ever-more-focused core idea. (There’s even a metaphor for the ideal Scrum outcome, sliced down to its purest essence: sashimi.) At a news organization, working on a single project for a cycle can feel indulgent, when our standard mode involves juggling a bunch of projects at once. Even as you may be getting more (and higher-quality) work done, you lose the sense of activity for activity’s sake that can be perversely gratifying.
It’s expensive. For stakeholders to feel comfortable ceding control to a team for two weeks, they need to be comfortable with the skills and instincts of the team. That means Scrum teams require highly skilled employees in all the roles. It’s not the experiment you try with a team of untested interns.
It’s meeting-heavy. Allow me to mention one last time the unironic existence of the meta-meeting in Scrum. Even beyond the daily meetings, the retrospectives, the sprint planning meetings, etc., face-to-face contact is a foundational premise of Scrum. If you’re the lone ranger type, Scrum is probably not going to be your thing.
It’s not a way of making an organization more strategic. When you come to Scrum with a problem you need solved, the framework will help you accomplish that goal in the most efficient way. It will make sure you don’t over-deliver on your goals, but it won’t set your strategic goals for you.
If these knocks on Agile sound like I’m answering the “What’s your worst trait?” question in a job interview, it’s because my colleagues are generally enthusiastic about how it’s working here at NPR. I told Cooper that I expected more of a backlash against the framework, and he replied that he, like me, was surprised to find near-universal acceptance of the concepts.
OK, I’m sold. Now what?
I hinted at the beginning of this article that I think Scrum could be used for all sorts of projects that aren’t just about software development, including journalism. I definitely believe that’s true. After all, as Lumbard pointed out, most newsrooms do have a version of a daily scrum meeting, so we’ve got a foundation already.
If you want to expand your knowledge of Agile, consider a book such as “Agile Project Management with Scrum.” That’s how Miller and one of our other senior project managers at NPR got started with this approach. Then a trainer was brought in to teach the concepts of Scrum more formally to most of the Digital Media department.
Or maybe you could use the principles of Scrum to evolve your team toward this way of work. Find a trusting executive sponsor, start holding daily 15-minute meetings, and start writing some stories. Using the techniques of Scrum to convert your team to Scrum … now that would be meta.
Comments