Guest Blogger: Tim Coonfield
Sr. Director of Interconnected Retail Technology
Global Custom Commerce (a Home Depot Company)
I am working with Tom Cabanski 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 fifth in a series of articles that Tom 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.
Growing up, I loved cartoons – what kid didn’t? One of my favorites was Voltron: Defender of the Universe. For the uninitiated, Voltron tells of the adventures of five pilots who each command a robotic lion. Individually, they were undeniably skilled and capable, but invariably each Saturday morning episode would present a challenge seemingly too great to tackle. I remember this as the point where I’d leap to my feet in anticipation. I knew this was where the magic was going to happen. The yellow and blue lions morphed into gigantic robot legs. Red and green assumed their places as the giant’s arms. The black lion and commander lowered into place as the head and torso, and Voltron was complete. A giant five-piece robot greater than the sum of its parts stood ready to dispatch whatever foe dared to stand in its way.
It wasn’t until years later that I realized how flawed a design this may well have been. Five pilots for your super robot?! What happens when the yellow leg decides to make a move to the right while blue decides it’s time to juke left? Or when red moves to block a blow at the same time that black lion ducks out of the way? The logistics of synchronous command are, to say the least, fraught with peril.
So what does any of this have to do with our agile journey at Global Custom Commerce (GCC)? This hearkens back to one of our early agile rollout mistakes, the selection of the all important Product Owner. Like all good agile shops, we recognized the importance of product ownership as a key to success. What we could not agree on was who should take the reins. Indeed, the problem facing us was just too great. We were trying to build an all-encompassing eCommerce platform, including administrative tools, a killer user experience, fulfillment systems, and support utilities for internal users. How were we going to find someone who could effectively represent all of those concerns simultaneously?
To find resolution, we looked across the organization. Our marketing department had some obvious choices who could speak adeptly to the most valuable impacts on customer experience. Our Customer Engagement Center had representatives who could outline the needs of our internal users fielding direct customer calls. Accounting knew well what back-office tools were needed to ensure that fulfillment ran smoothly.
In fact, we had a wealth of riches! Product owners everywhere! And if Saturday morning cartoons had taught us anything, it was that the only thing better than five robot lions is their combined and collaborative might as Voltron. It was with that “insight” that we formed what came to be known as the Product Owner Committee. We had a product manager at the head of the group to facilitate all of our backlog refinement and prioritization discussions amongst designees from each department in the organization.
Early on, it seemed to work. We were getting things done and building a platform. In hindsight, though, that’s probably because most of these initial decisions were the easy ones. We all knew in broad terms the direction we were moving, and it wasn’t terribly hard to obtain consensus. The committee was unanimous in nearly everything we did. There were a myriad of other realities that greased the skids here for us, but suffice it to say, we thought we had hit on something.
Somewhere along the way, though, things started to get more complicated. As the product started to “feel” real to our users, committee meetings started to feel more like a jockeying for position on the backlog. Each product owner was there to represent the priorities of his or her piece of the organization. As a company, we always worked to ensure alignment on overarching priorities, but that didn’t stop competing concerns in the moment. Different perspectives would inevitably lead to different conclusions on how to achieve our larger goals, and it showed in our backlog refinement. Prioritization was weighted as much by reactionary behavior to persuasive (or persistent) arguments as it was by strategic thinking. Complicating that was the harsh truth that development is a bit of a zero-sum game in some ways; if I’m developing feature A, I’m not working on feature B. As much as we struggled to keep a common alignment, the reality was that, in the stress of doing big things, we would sometimes move in contrary directions to one another.
I don’t know that there was a specific moment in time that we realized what we had built, but we don’t have a committee anymore. We have a product owner (several of them, actually, thanks to years of growth) and a group of identified stakeholders that may vary from one epic to the next. Ultimately, our product owners are empowered to make decisions about our backlog, a trust bestowed in large part due to their inquisitive nature and ability to synthesize different groups’ concerns in alignment with organizational goals. And in reality, it was that TRUST that was the turning point. The company as a whole said, “This is someone we trust to sift through these competing perspectives and develop with a backlog.”
The power of this shift in thinking was palpable. Backlog refinement didn’t become easy, but it had a focus and a clear direction. Everyone knew – whether stakeholders or development team – where prioritization was being decided. Product owners took the trust they had been granted seriously, too. That meant being good stewards of the company vision while at the same time making sure to hear, digest and incorporate diverging stakeholder perspectives when making a decision.
Like everything we learned along the way in our agile journey, I can today appreciate the value of the mistakes we made. The autonomy, authority, and trust in our product owners was molded by our struggle harnessing the product owner by committee that we started with. I’m not sure any product owner appointed on day one would have been able to gain the trust of the stakeholders the way they have today. It was a valuable lesson to learn, and one that was crucial to where we are as an agile shop today. And sometimes, that’s an even more powerful thing than a super robot made of lions.
Tom Cabanski 