The Biggest Mistakes We Made on Our Agile Journey (and Why We are Glad We Made Them) — Parity Plus

I am working with Tim Coonfield to develop a talk for the one day Agile Shift conference scheduled for April 12, 2019 in Houston, TX titled “10 Biggest Mistakes We Made on Our Agile Journey (and Why We are Glad We Made Them)“. This is the seventh in a series of articles that Tim and I will use to explore some of those mistakes and what we learned from them. You can find other articles in this series here.

If you are interested in hearing this talk or some of the other awesome speakers and topics that will be covered at the event, you can learn more about the conference and purchase tickets here.

Everything I will share here happened at Global Custom Commerce (GCC), a Home Depot Company, as we developed and improved our 2nd generation e-commerce platform, called Autobahn, designed to make it easy for customers to shop for and buy more complex configurable products and services like custom window blinds, custom windows, flooring and decks. 
 
In 2011, when the Autobahn platform started development, GCC was already the #1 seller of custom window coverings online and owned several brands including blinds.com. We were a couple years away from acquisition by the Home Depot and had about 80 employees. The existing e-commerce platform had been in production for a number of years and was still actively being improved by a large team following a traditional project management philosophy using Gantt charts and reporting on percent complete.

The Autobahn project marked a number of firsts for GCC including our first use of cloud hosting at AWS and our first use of agile methodologies. This article highlights one of our bigger mistakes and how we were able to improve as a result.

This mistake pushed me to the edge. I lost sleep over it, I started hating my job and I almost left the company because of it. You need to know that before you read this story. I can even pinpoint the date when all my pent up emotion spilled out in a post I published back in June of 2013. I’ll share that post later. For now, let’s see if time has improved my perspective.

Autobahn was one of those rare opportunities to build something from the ground up. Everybody likes starting a project from scratch. You get to use all the latest tools. You just know your design will be perfect, your code stellar, your tests complete. If you are replacing a system already in use, like we were, you know that your new system will be much better than the buggy, messy thing that nobody wants to work on anymore.

But that was the problem. The existing e-commerce platform that had been developed over about ten years was successfully serving customers across four web sites to the tune of around $100M annually. A team of developers, designers and marketers worked together every day to continually improve that platform, driving up conversion and growing the business at double-digit rates. There was no way our business could afford to stop that team from improving the platform while we waited for Autobahn to have enough capability to replace it. The market was simply too competitive. As a result, the Autobahn effort was planned to run in parallel with a small, dedicated team while the existing team continued to improve our proverbial cash cow.

We called it parity-plus. Autobahn had to do at least as much as the existing system before we could switch over our busy e-commerce web sites to the new platform. On top of that, Autobahn had to do more. It had to be more stable. It had to be cleaner and easier for developers to modify. It had to have better automated testing. It had to live in the public cloud where it could easily scale with our business. It had to be faster. Of course, it had to have tons of new, customer-facing improvements too. Finally and most importantly, it had to have a better and more flexible product configurator capable of selling any kind of complex, hard-to-buy product so that we could easily expand our business to other product categories in the future. It wasn’t exactly required to make coffee. However, we did decide that, at least in theory it would have to be capable of selling everything complex and configurable from blinds to the evil flying monkeys envisioned in “Wizard of Oz”.

We weren’t concerned. We baked parity-plus into the plan as well as into the psyche of our business leaders. The Autobahn pitch was like one of those kitchen gadget commercials you see on TV — it slices, it dices and it’s all easier and faster than ever before. All our stories and demos talked about parity-plus. In fact, our business would often provide an acceptance criteria that said more or less “this has to work exactly like the one in the existing system plus the following”.

We talked about flying monkeys all the time too. When we designed key features that involved how products and configurations worked we would consider how the feature would handle blinds and then asked ourselves if it would work to sell a flying monkey too. As silly as it sounds, I can say with 100% honesty those soaring simians played a key role in our biggest success: The core of the new Autobahn system was capable of handling almost any complex product we could imagine.

The rest of our parity plus strategy was not going so well. Almost immediately, it became clear that the existing system did lots of little things that almost nobody knew about, which made it impossible to deal with those acceptance criteria that said, “does everything the existing system does plus the following”. As a result, the development team started insisting on stories with acceptance criteria to cover the parity-related features. This proved harder that expected as it was difficult to identify all the little things the existing system did and exactly who relied on the resulting capability.

Meanwhile, the company continued to focus most of its energy and resources on improving the existing platform. In fact, the development team for the cash cow platform was larger than the one focused on Autobahn. Of course, this made the Autobahn backlog grow regularly as each new feature added to the existing system would be needed in the new one. To make matters worse, the necessary focus on driving the existing business made it hard to get time from key stakeholders to work on developing Autobahn.

To the credit of all involved, we worked together to try and solve the problem. The Autobahn development team got bigger. Business leaders freed up time to put more attention on the new platform. We even slowed development on the existing platform to some extent by asking hard questions about every new feature and how long it would be in production.

Despite all those efforts, the schedule continued to slip away. By late spring of 2013, our most optimistic estimate put Autobahn at least one year away from achieving parity-plus after almost 18 months in development. This assumed development of new features on the existing platform stopped completely, which wasn’t going to happen. This also assumed that many team members continued working long hours to try and push the effort to parity-plus and launch. Like I said, one year was a very optimistic estimate.

Team morale suffered. Some of us started advocating for radical solutions including killing the Autobahn project. We felt this would free up resources to focus on radically improving the existing e-commerce product to make it capable of delivering on our CEO’s future vision. Although the business carefully considered even our most radical ideas, it was decided to continue on course.

Many team members, including me, started to wonder if we were on some kind of death march. I expressed my extreme frustration in June of 2013 when I published “When Green Fields Become Killing Fields” on my blog.

But we didn’t give up. The next few months were a blur as we buckled down and tried to get on course to launch at least one website on Autobahn by the end of 2013. To some extent we succeeded. By around October 2013, Autobahn was fully capable of selling custom blinds to customers though it still remained far from reaching the parity-plus goal.

At that point, the development team gathered offsite with out PO,
Wade Pinder, to brainstorm how to get Autobahn into production. The discussion centered on two options. Most of the team favored targeting our smallest e-commerce site, Blinds.ca, and convincing the business that we could launch it on Autobahn well short of our parity-plus goal without negatively impacting sales. That group believed we should put a fairly tight timebox on the remaining effort to force everyone to focus on only the most critical features. In agile terms, this group wanted to aim at a minimal viable product or MVP. The rest wanted to maintain our focus on the biggest site, Blinds.com. They thought we could deliver closer to parity-plus given more time and a development freeze on the existing platform. After vigorous debate, the team decided to take the blinds.ca MVP strategy to business leaders . We then worked together to put rough estimates on the remaining stories so we could help the business decide what would end up in the MVP.

A few days later, Wade led a meeting with the development team and all the key stakeholders that he ended up calling the “Red Line Exercise”. He put all the remaining stories up on a board in priority order. Because we had rough estimates, he was able to draw a red line at the six-month mark. The exercise for the business was simple. Stories above the line would be in the MVP. Below the line would not. If somebody felt a story below the line was critical, they moved it up in priority order so it was above the line. However, this would move stories of lesser priority down the list and some would end up below the red line. Some of the resulting trade-offs were easy, others inspired spirited conversation, but ultimately we converged on a solution . By the end of the exercise, we had successfully killed the notion that parity-plus was needed before the first launch and had a path to launch blinds.ca in six months.

It took a little longer that we expected, but we launched Autobahn with Blinds.ca on June 10, 2014 roughly 8 months after the original red line exercise. Although it launched missing a number of key features from the existing platform, blinds.ca revenue actually showed a small year over year increase and conversion improved too. It also gave us a platform to continually improve as we drove towards the launch of our other brands.

Over the years that followed, timeboxes became our most effective tool for driving major releases that required multi-sprint efforts before going public.
Although we can usually deploy these larger changes incrementally using techniques like feature toggles, we really can’t expose them to the public until they deliver a MVP. We timeboxed our blinds.com launch. A timebox drove the rapid delivery of custom window coverings on Homedepot.com after the merger. We also use timeboxes extensively in our exploratory division to rapidly deliver new product categories and buying experiences both in-store and online for The Home Depot.

If you ever find yourself stuck on a project that is expected to deliver parity-plus or you can’t seem to finish your minimal viable product, you need to introduce a time box. This happens naturally in startups due to financial constraints and is a big reason they often seem to get so much done with so little. Make the timebox smaller than anyone likes and try a red line exercise. Your MVP will likely get smaller, you’ll definitely deliver faster and your customers will end up far happier than anyone believes. Just remember, the MVP is not the end; it is only the beginning of a journey of continual improvement.