Note: This post is the 11th in a series on Brand Building that highlights the approach that WhitePages has taken over the past 15 months to build and reposition its brand.
The following post was written by Ben Maldonado who is one of a number of rockstar web developers at WhitePages. Ben has worked with individuals across the company to help bring the new WhitePages brand, and site, to life. He’s also been doing a ton of dancing.
When I was first approached to become part of the brand team I was very excited. As part of our brand identity changes, we would be doing a major overhaul of the site’s look and feel. It seemed like an appropriate time to also review our current code-base since it was starting to show its age.
Two of our brand pillars which are “Relevant Innovation” and “Intuitive Experiences” were aligned with this effort. A new code base would allow us to be faster and more agile then we had in the past which would result in a richer, more intuitive experience for our users.
Of course everything sounds great on paper when you first start a project; in our case we had 2 sprint teams. (for more in-depth information on Agile development read Joe Heitzeberg’s post on the “Parallels Between Agile and Branding“). One team was focused on providing new ground work to support our front-end engineers, while the other team was focused on implementing the new look and feel based on the first team’s work. Managing a single code line among 2 teams is the stuff that makes development in agile so easy and fun. In contrast, you may be forced to manage more than 2 code lines across multiple teams which can become cumbersome to say the least!
For the first few months, we continued to work in 2 teams, but we soon realized that other teams would have to come online; we would now have 7 teams working on the same code to meet the same deadline (while not stepping on each other’s toes). We would also have to continue to meet the high standards set by the first 2 teams: the code must be as elegant as the User Interface while avoiding the creation of an unmanageable code base that would be non-scalable. Just to put things in perspective, I’m the kind of guy that has my code editor set to use the Helvetica font because I like to think that code should look just as good as effective print design!
At first, the merging of teams seemed like it would be effortless – as long as all of the team technical leads were in sync, we’d have no issues. I soon found that this was not the case, and that we were moving so fast that holding multiple meetings to discuss issues was just not going to happen. So what now? How could we get everyone back on track and meet our deadline?
Code Reviews
Code reviews are the first thing to be scrapped or overlooked by development teams. I’ll admit that we’re just as guilty as everyone else for not doing enough of these reviews in the past. Code reviews effectively expose developers to the work of all the other developers. We literally examine everyone’s code line-by-line to ensure we all agree with the style and approach. When you’re moving fast and trying to meet tight deadlines, it’s easy to lose focus on the overall quality of code and start relying on shortcuts and bad habits; code reviews help catch problems quickly. We also found that these reviews allowed developers to provide some insight into previously written code that could be used by other front-end engineers.
Cross-Code Line Meetings
As a way to give all tech leads and project managers exposure to what other teams were doing, meetings labeled “cross code line” were scheduled. These meetings were the place where all issues were discussed to ensure that no two teams were trying to solve identical problems; and to help come up with a solution while venting it to a larger group. I found this was an excellent forum for us to announce changes that were coming to the base code line and coordinate cross branch merges.
Good ol’ Fashioned Elbow Grease
In the last few weeks of the project, just “staying on top of everything” seemed the best approach. This included endless hours of bug prioritization in a room with Zoe (check out her site redesign post) and our fearless Project Manager, Snezana. In my head, I can still hear Snezana issuing constant demands for Zoe and me to prioritize bugs! We also closely watched bug counts, checking in with engineers on the status of their work and making sure no one was blocked as we got closer to the big day. To lighten the mood, come 2pm, I would perform the “Ben dance”. I performed in our team area, sometimes to music and sometimes (despite other’s complaints) I sang.
I’ve been involved with many development teams, some more fun than others, and some more successful. In my 14 yrs as a developer, I’ve never worked on a project where everyone was as remarkably dedicated to bringing our brand vision to life. But the true success of this huge, multi-team effort was due to our fine balancing act of very hard work and fun. Sometimes it takes dancing on tables to Beyonce just to lighten the mood and provide some inspiration; lucky for my team, I’m more than willing to perform!
I know this post takes a very high-level view of our development approach. But if you have any questions about how we managed the whole process, just post a comment below and I’ll respond.
Ben
View more posts by .
