fitting the kiva redesign into a two week release cycle
Kiva Engineering is an Agile shop. We're better at some parts of Agile then others, but we hold true and fast to the principle of "Release Fast, Release Often". We aim to release every two weeks, and for the past 9 months our largest deviation from that has been a delay of one day.
That said, fitting the Kiva site redesign into a two week iteration seemed pretty challenging. The full scope of what we’d like to do is both broad and deep, and at this point, we've really only scratched the surface. Our amazing team of designers preferred to have the entire scope released in one big release (maybe 9 months of work?). Back in Kiva Engineering, that seemed a little risky, so we worked out a compromise. Our initial release would include their full vision of the Kiva home page, an overall look and feel refresh, and a manageable amount of work on a handful of key pages.
That was still more than five engineers could do in two weeks, so we also fell back on the not-so-elegant practice of "feature flippers". It was pretty easy to tweak our system such that according to a configuration setting, the site would display with our old HTML frame and old CSS, or our new HTML frame and new CSS. With that set up, two engineers started work three iterations (six weeks) out from our target launch date. They worked on building the new home page, and the new HTML frame in a "parallel universe". This allowed us to keep the code rolling out the door every two weeks, with their half-finished work "invisibly" included in the mix. The plan was not to touch any HTML/CSS for any pages other than the home page until the third and final iteration. At that point, we would take a divide and conquer approach, pulling in a total of 5 engineers to tune the HTML and CSS for the entire site - bringing them in to compliance with the new look and feel.
That was a good plan. As usual though, we had one little hiccup along the way. We dithered back and forth a few times about whether or not this project would take two iterations or three. Signals got crossed, and our HTML/CSS guru got one iteration ahead of the rest of the team. Mid-way through the second iteration he committed a change in which he wiped out every inline style element, and re-tuned the HTML for a large portion of the site. Oddly, the rest of us failed to notice this for a couple of days. By that point, rolling back his three day series of commits looked like a daunting and discouraging task. Instead, we decided to roll forward. We brought in a third engineer a little early, and had them temporarily hack our old stylesheet to bits in order to make the new HTML look like the old look and feel for two more weeks.
On the third iteration, we all jumped in - and finally got squarely on the same page (or...errr.. pages). We divided up the site, dropped our old stylesheet completely, and set to work putting the site back together. While this was a great deal of work, our new HTML structure and our new stylesheet made things so much easier that we finished up in plenty of time.
As launch dawned, we nervously watched the feedback on Twitter (very positive - thanks guys!) and the next day we were able to check in on all of our important site metrics. To our vast relief, those all looked good too. All, in all, our initial site redesign rolled out the door very smoothly. Here's what I think we did right:
In this initial launch, we changed very, very little in terms of functionality. Although the home page looks vastly different, the central functionality is still the same. The user is presented with a choice of borrowers, and given a call to action to Lend.
We didn't change any of the major flows. Although we were tempted to make some changes to the ordering of steps within our primary "Make a Loan" flow, we resisted doing this at the same time as the site redesign. If changing the flow had wound up confusing our users, we would have had a tough time interpreting any change in metrics.
We changed very little on the back-end. Most of the PHP changes necessary to support the new home page went live an iteration in advance of the new redesign. This meant that all the issues reported after the launch were in the expected HTML/CSS layer - leaving us to fight a one-front war against the odd mis-behaving browser, rather than a multi-front war across many layers of our architecture.
Within our chosen scope (new home page, new look and feel) we went all out. We removed the vast majority of ancient in-line styling and completely dumped our old stylesheet. It made for a lot of work, but it was also very refreshing.