NPR logo Redesign Process and Tools


Redesign Process and Tools

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.

A typical 10:02am meeting of the redesign team. NPR hide caption

toggle caption

A typical 10:02am meeting of the redesign team.


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