By Kim Bryant

This post is the first in a series explaining the challenges we face in managing work requests, bug tracking and other operational processes. Specifically, I'll cover Jira, the tool that we selected to help with these challenges, as well as the ways we've configured it to suit our culture and needs.

Part of my job is figuring out how we can work more effectively, and one of the first areas we needed to tackle was our work request system. Our overarching goal when managing work requests is to allow Digital Media to easily separate the noise from the important stuff. You know that scene right after the crash in the first episode of Lost where Locke sees the equivalent of a redshirt wandering near an intermittently-spinning jet turbine, and the guy can't hear the specifics of Locke's yelled warning so he stops long enough to shout "What?!" and then fahWHOMP-- redshirt becomes strawberry jam and the engine explodes and a horrible situation just got worse? Here's a refresher:

We needed to stay off the path to experiencing our own redshirt schmear in the midst of premature labor, ineffective CPR, and lethal chunks of flaming metal shrapnel. Maybe ours wouldn't be as messy, but certainly no reprise of Beach Blanket Bingo.

Our ops demons and how we started taming them, after the jump.

Continue reading "Jira: 'Swapping Chaos for a Little Overhead' *" >

By Zach Brand

So far in our discussion of the NPR redesign we covered our efforts on launch night as well as upgrades to the API. We now return to January / February of this year. The team started to formulate how we would go about accomplishing the stated goals of the redesign. Our first major process decision was to approach this project more Agile-like. Of course such decisions need to actually be understood and carefully implemented or any project team will feel they are in a cartoon:

Most of our previous projects had been very waterfall in nature with requirements being fully defined before coding started. While useful on many types of projects, these frequently had undesirable consequences that we wanted to avoid on this project: unnecessary code being written, requirements not fully understood, division between teams, compromised functionality and/or architecture, and goals at the end of the project differing from those at the end. Most importantly since we didn't really know what we were building, we wanted better flexibility to figure it out as we went. Agile was well suited to solve this.

As such we implemented aspects of scrum, but also adapted to what would work for us. We made sure we had an integrated team with necessary skills (Designers, Editorial, UX, App Dev) working together from day one. We did do some rapid prototypes, and requirements were more of a ongoing dialogue than firm written down specifications. We decided to divide the project into 30 day cycles. Certainly not sprints, but clear milestones that forced us to keep moving. This became a painful, but useful tool as it was a struggle not to put off 'decisions' when there were still months to go in the project. We used planning poker (there's got to be a 10 card in here somewhere), we had standing daily meetings. And we physically moved 20+ members of the redesign team so we could sit in one contiguous area.  Of these the last may have had the biggest positive effect on the dynamics of the project. The spontaneous conversations, and ease of communication likely had as much benefit as any other process change.

Given the duration of our cycles we had varied success with burn down charts. From a management perspective having effort per task turn out to be extremely helpful. When an accounting question came up regarding hours spent on different types of tasks -- the team did not need do do anything -- all the data was already there. That said, as we got into crunch time at the end of the project, and hundreds of items were being added and removed per day, this became an a extra-step for the team that we chose to largely skip. Standing morning meetings (10:02am!) were trying at times, but under the leadership of our project manager Constance Miller they became very effective at setting expectations, raising concerns, and quickly resolving issues. They also featured amazing camaraderie and a fair bit of mirth. We also made it very clear it was the team's job to make decisions and drive the meetings -- not management. We even took to using the effective, but unfortunate labels Chickens and Pigs. The Chicken's were very limited in their role in these meetings.

Ironically in our first cycle a large portion of what we did was not directly tied to our three goals, but was about changing the project management and Application development tools we had been using. We will discuss the specifics of the tools in greater detail in a future post, but we found that our existing task / project / bug / code repository tools were not up to our forthcoming needs. Among the changes included implementing Subversion and portions of the Atlassian tool set.

Jira became the guts of the project management. We may have under estimated the amount of effort required to fully set it up the way we ultimately wanted. Ironically we didn't know exactly what the effort was as we didn't have Jira to track it! While these tools have become core to our process and a massive improvement, the migration was difficult and effectively set the team back a month at the outset.

We also did not have a development environment that was flexible enough nor one that would scale to the additional developers that we brought onto the project. As such we overhauled our entire development stack and created a virtualized development environment using a six node Proxmox ( OpenVZ ) cluster running up to 40 virtualized environments supporting a variety of OS and application stacks. This led to slow performance in some initial configurations but after increasing RAM and better optimizing the number of virtual environments per physical server became a much used tool.

Once we had the tools and process in place, it came time to really drill down on our goals.

Coming Next:

Redesign efforts in mobile

By Zach Brand

Just over a year ago we launched the NPR API. Last night we launched a redesign of the NPR.org Web site as well as substantive changes to the CMS and APIs behind it. Things are moving quickly at NPR.org!

You may have seen Scott Simon's video tour, and you may have seen the editorial note, but over the next couple of weeks we will be posting the technical story behind this redesign. In a series of posts to Inside NPR.org we will be discussing the changes we made to our processes, changes to our tools, and changes that are both visible and not so directly visible NPR.org users.

While our planning for a site redesign goes back for sometime, for a variety of reasons we did not formalize our goals and begin technical work until early in 2009. Our stated goals were:

1. Create better flexibility in how we could publish a Web site.
2. Update the design and usability of the site.
3. Improve editorial efficiency in publishing.

The first goal was to allow greater freedom in how editorial staff could present content. Previously, any major efforts to display anything differently required application development. The second was about aesthetics and usability, while the third was reducing repetitive tasks and improving tools for our editorial group. The team who was to implement these goals convened for the first time in early February. We set a date of mid-summer as a reasonable time frame to make significant strides on all three goals - even though we didn't really know what the end product was going to be. What we did know was that this was going to be the largest project for NPR Digital Media to-date. Beyond just the scope of the project itself, we were going to have to make changes to some of our tools and processes to succeed.

Six months of effort culminated last night. We kicked off preliminary migration efforts around 11am. We optimistically hoped to be done by early afternoon. Then the various realities of completely overhauling the Web site and our CMS hit. While there weren't any massive surprises, we had a bunch of time-intensive delays that resulted in large part of the team working for over 14 hours. Shortly before midnight, NPR.org had a new look, the API had new features and a bunch of internal tools had changed.

As we continue the series around the launch of the redesign, we'll be covering a variety of topics: changes to the API, changes to our development tools, changes to our publishing tools and more.

Next up: the NPR tech team tweets its way through the site migration, including our various trials, introspections, wit and wisdoms, and how our mascot Zelda kept us sane for last night's launch.

As follow up from my post back in November there are a number of events upcoming to hear and meet with folks from NPR Digital Media first hand.

Feb. 19-21 - IMA Public Media 09

For those in Public Broadcasting family we hope to see you next week at IMA Public Media 09 . It is scheduled to be: five idea filled days with 55 sessions on everything from coding widgets and measuring impact to mastering the subtle techniques of building online communities.

• As part of the the WebTech Summit on Wednesday 2/19 I will be appearing in a panel to discuss Mobile site development. The Mobile Site Development session will be a panel that includes myself, - Ann Breckbill and Melinda Driscoll, American Public Media; Keith Hopper, NPR/Public Interactive; Matt MacDonald, PRX; and the inimitable Doc Searls.

• Later on Wednesday I will be discussing the development and use of Widgets and APIs. John Tynan and I will join Andrew Kuklewicz on such topics as how do you develop widgets and how and when should you pull data from other site's APIs or place widgets on your own sites.

• Also on Wednesday 2/19 Dick Meyer Editorial Director of NPR Digital Media will be discussing the sustainability of commercial sites as part for the Executive Education & management Training program.

• As part of the core conference our Social Media Guru Andy Carvin will participate in several presentations. On Thursday 2/19 he will be on a panel discussing "A Social Media How To: Choosing and Using the Right Tools.

• On Friday 2/20 you will have a chance to meet our new boss here at NPR. CEO Vivian Schiller will be addressing the Conference at 2pm. Also on Friday Andy will be on a panel discussing "Social Media: What's Worked and Lessons Learned."

Upcoming:

On Wednesday 2/26 I will be presenting NPR's revolutionary work in digital media as part of the We Media game changers conference.

On March 15th Dan Jacobson will be part of the discussion at SXSW Interactive festival discussing APIs and the changing face of news online.

Finally on April 3rd I will be at the O'Reilly Web 2.0 Expo and joining Robin Sloan the VP of strategy at Current, a media company co-founded by Al Gore and Joel Hyatt. We'll be discussing the future of content distribution from both TV and Radio perspectives.

We hope to see you soon!

-- Zach Brand

When we first launched the NPR Community on September 28 of last year, we wondered how long it would take for us to reach 50,000 registered users, and a number of us figured it would take at least six months to reach that goal.

It turns out we were able to do it in four months.

A couple days ago on January 9, we hit the 50,000 mark. And we couldn't have done it with all of you. On behalf of the NPR Social Media Desk, I want to thank all of you who've taken the plunge with us. We're thrilled that we've reached this milestone so quickly.

So here's to reaching 100,000 users! Anyone want to take a guess at when we'll get there?

-- Andy Carvin

First, thanks to everybody for their API-related comments here and numerous other places. We are a bit overdue, but are working on putting up an FAQ for the API. As we have started to compile a list of questions, a common answer is emerging: We didn't want to hold the API back until everything possible was perfect. We do think the API today is very extensive and fills a void, but we also think that it will evolve as time allows, and as we respond to requests and new opportunities. As with everything else, we like to treat all our online efforts as an ongoing work-in-progress, with opportunities to get even better. But for the moment, we're very excited to see what ideas folks implement with it.

I've started a list of questions below. Please chime in with comments on what other questions you'd like see included in the API FAQ.

Continue reading "Proposing Questions for an API FAQ" >

On behalf of the NPR Digital Media team, we'd like to welcome you to Inside NPR.org, a new blog that will serve as our official headquarters for new features and services we're developing for the NPR Web site. It's a chance for you to explore some of the many projects we're working on, and help us make them more useful as we roll them out.

The idea behind this blog has its roots in our two newest shows - Tell Me More and The Bryant Park Project. Both of them were rolled out as blogs many months before they were ready to go on air, in the hopes of getting as much public feedback as possible. Historically, it's common to develop a show behind the scenes, only giving listeners a chance to hear it when it was ready for prime time. By creating online communities for each show while they were still "rough cuts," we were able to build better programs because of it.

Now, we'd like to apply the same rough cuts idea to our online services in general. Whether it's rolling out social networking, building new mobile products or improving our online strategy in general, we're hoping we can develop better tools if you're a part of the conversation.

In the coming weeks and months, you'll hear from a variety of people from behind the scenes at NPR.org - software developers, product managers, online producers and others who are working on new Web site features. We hope that talking about these activities more openly will help create a virtuous cycle of product development and feedback.

Thanks for joining us; we look forward to brainstorming with you!

-- Andy Carvin and Daniel Jacobson

Here's a quick rundown of the discussion rules for the blog.

First things first: If you can't be polite, don't say it. Of course, we don't want to stifle discussion of controversial issues. Some topics require blunt talk, and we're not always going to agree with each other. Nonetheless, please try to disagree without being disagreeable. Focus your remarks on positions, not personalities. No personal attacks, name calling, slander, comments about someone's mother, comparisons to notorious dictators - you get the idea. And under no circumstances should you post anything that could be taken as threatening, harassing, bullying, sexist or racist.

Don't use obscenities -- even if the word in question is often used in conversation. We're not going to list the words we object to; you know what they are. Remember, this is a public forum and we want everyone to feel comfortable participating.

Anything you post should be your own work. You're welcome to link to relevant content and to quote from other people's work with attribution. But that doesn't mean you can copy and paste wholesale.

Please stay on topic. Think of it this way -- if you hosted a book club meeting at your house, you wouldn't want someone to show up and insist on discussing reality TV shows.

Rambling is the kiss of death. Keep your comments to 400 words or less. Generally, anything beyond a few paragraphs had better be very, very interesting to the larger community. We reserve the right to edit for brevity as well as clarity.

Please respect people's privacy. We love to learn about new and interesting individuals, but most people will not be happy to have their phone numbers or e-mail addresses published. If you need to share someone's contact information, please submit it through our contact form.

No spamming the comment threads - this isn't a place to hawk your wares.

We appreciate the news tips members of the public send us. However, NPR reserves the right not to publicize rumors, allegations, conspiracy theories and other information which we know to be false or unsubstantiated.

Be yourself - and not someone else. Don't post anything on the site posing as someone else. Imposters should look elsewhere for kicks.

Please don't use public forums for private communication. Most of our forums have a link (it's on the right side) for sending private messages to a blogger or host. Similarly, if you have comments about NPR coverage or policies generally, please don't use the blog discussion threads to air them. For issues regarding NPR editorial content or policies, write to the office of the ombudsman. To contact an NPR program or any of our business and technical departments, use the NPR contact form.

If you want to know even more information on what is and isn't allowed on NPR.org, please see our very official Terms of Use page.

What is Inside NPR.org?

Inside NPR.org is a blog that focuses on the NPR Web site and all the tools and services we're developing for it. The idea behind the blog is to roll back the curtain and give you a chance to learn more about projects were working on, as well as ones we're considering doing for the Web site.

Continue reading "Frequently Asked Questions about Inside NPR.org" >