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 third 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.
Because he plays such a big role in this story, I’ll be referring to our first PO, Wade Pinder, by name. He played a big role in our agile journey and an even bigger one in this story. Although we have lots of POs these days to serve our twelve agile teams, Wade remains the strongest agilist here at GCC. You can find Wade speaking and coaching agile around Houston and on LinkedIn.
Several years ago, we started having conversations like the following between development teams and Wade Pinder, our PO at the time, often very late in the sprint when the team was rushing to finish up the last few stories to meet their commitment for the sprint:
“Wait a second”, Wade says pointing at the screen. “this is the first time I am seeing the screen and such and such doesn’t work the way we need. I can make some specific suggestions now that we have a screen to look at. Maybe we can get some of the end-users to take a look and help as well.”
The engineer doing the demo grimaces and says, “Well, the story is really done and the requirements weren’t called out in the acceptance criteria. We won’t have time to do any of that this sprint. We can write it into a new story and maybe pick it up next sprint”.
Sometimes the conversation would turn into a more extensive debate. Wade would remind the developers that a well-written story was “a reminder to have a conversation” and the agile manifesto calls for “customer collaboration over contract negotiation”. He would also accurately make the point that the intent of the story was quite clear by the time sprint planning started based on all the conversations that had taken place. Down deep, the development team knew they had failed to deliver on that intent. However, most times a narrow reading of the acceptance criteria gave them the cover they needed. They were acting like lawyers that get a guilty client off on a legal technicality.
The changes needed were generally not huge. They often ended up in what we would categorize as a small or medium story. Equally importantly, these weren’t cases when a story turned out to be too big and sprawling to actually be a single story. It was really the case that the team was not delivering on the intent of the story. It was happening more and more often and resulted in far too many sprints where one or more stories would be “done” but did not deliver the expected business value until the follow-up story was completed and deployed in some future sprint.
After months of this, Wade decided to take action. He decided to write stories that captured every single aspect of everything expected in excruciating detail. Small stories that used to have less than five acceptance criteria, had 20 or more. Every UI change came with a mockup and a clearly-written expectation for pixel-perfect delivery. Every field was described, every validation was specified, expected response times were documented and every error message was spelled out. By the time he was done, every story ran for several printed pages. Each one was like the most cunning contract ever assembled by the most skillful corporate lawyer — completely devoid of wiggle-room, full of landmines and utterly impossible for mere mortals to understand.
The development team was horrified by the more detailed stories when they first saw them in a backlog grooming session. There was no room for creativity and no room for their input. Every detail was locked in.
Where was the room for discussion? What if there was a better way? What if there was an easier way?
Then we really started to talk. Wade and the developers saw eye to eye for the first time in months. The developers agreed to show Wade screens and other story artifacts as quickly as they became available to provide time and context for meaningful conversation and course adjustment. In fact, many teams adopted an extra step at daily stand-up to ask out loud “what can we show Wade today”. Wade agreed to go back to writing stories that were reminders to have conversations instead of contracts that specified every detail. Together, everyone agreed to focus on delivering the business value each story was intended to deliver even when it meant missing a sprint commitment.
Agile Lawyers still popup from time to time, but they are easier to deal with now. If it’s a developer, someone that’s been around for awhile simply tells this story and reminds them of what can happen if they force the PO to turn into an agile lawyer. If it’s a PO, it almost always turns out that the PO is reacting to an agile lawyer on the development team and, well, you know that story.
Tom Cabanski 
You must be logged in to post a comment.