The Biggest Mistakes We Made on Our Agile Journey (and Why We are Glad We Made Them) — May I Take Your Order?

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 ninth 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 as well as some of the background about our agile journey here.

Around noon, you and your team go to lunch at your favorite restaurant. The waiter walks up to your table, turns to you and asks, “May I take your order?”.

You order the cheeseburger with sweet potato fries. Your teammates order as well. The waiter leaves, brings back drinks, returns later with your food, checks in with you to see if you need anything from time to time, brings the check and so on. If the waiter does his job well and the chef prepares your food properly, you are happy with the experience and leave a nice tip. If not, you reduce your tip and might even complain to the manager.

Your lunch experience is not terribly unlike how stakeholders experience agile in many cases. The business identifies a feature they need to solve a problem they have. For example, a stakeholder might ask for the ability to search customers by last name. Your PO turns that into a story that gets prioritized and assigned to your team. Your team picks up the story and gets it done. If your team collaborates well with the business, you probably check in with your stakeholders as you work on the story to get questions answered, show mockups and generally refine your approach. At sprint review, you show the stakeholders what you’ve produced and they are usually happy enough to accept the story as completed. If not, they provide feedback and might even complain to your manager.

However, the model above is a terrible way to work and ends up undermining the team’s ability to deliver business value. When developers take orders, as the old joke goes, they end up delivering exactly what was asked for but not what was wanted or needed.

Our teams fall into order taking mode from time to time, but they usually pull themselves out of it by simply reminding themselves and the business that they need to understand the problem that needs solving rather than the way the stakeholders would like to see it solved.

In the example above, customer service needed to find the customer record for people calling in on the phone. Once the team understood the problem, they proposed a comprehensive search that would allow the customer service rep to lookup the customer by phone number, email address or name. Although it cost about the same to implement as the simple name search, it actually solved the underlying problem more completely since phone numbers and email addresses were more likely to return the single customer record the service rep wanted. It also opened the door for more sophisticated features in the future. For example, once we tie in the phone system and our CRM system, the same search API the team developed for this feature can be used to automatically pop the customer information onto the screen as soon as the customer service associate answers the call.

There’s nothing unique about how our teams avoid order taking mode. Truly, it is Agile 101. The INVEST model for user stories calls this making stories negotiable. The idea is to leave room for the developers to negotiate the details of the implementation with the stakeholders. In this model, the PO works with the business to understand the needs, provides them to the developers in the form of a story and then the team collaborates with the business to converge on a solution.

However, Agile 101 is not good enough. In practice, teams want some certainty around stories before they are willing to estimate them. In addition, stakeholders require more detail around screen layout and workflows before deciding on what stories to prioritize. Therefore, POs end up working ahead with designers and stakeholders to flesh out the details. Inevitably, implementation details leak into stories in the form of screen mockups and more specific acceptance criteria. By the time the team sees the story, the business rules are cast in stone even though technical details remain perfectly negotiable.

In traditional agile fashion, we tried to fix this by asking developers to spend more time grooming stories with the business. In practice, this meant select developers would sit in on design sessions. This gave them the opportunity to inject the technical viewpoint on stories. For example, suggesting a popup screen instead of a new web form because it would make the flow easier and faster to implement.

Our teams got pretty comfortable with this. It seemed to fit the agile model. The business decided on the business stuff. The technical people decided on how to solve the problem technically. It was efficient because everyone stayed in their comfort zone to deliver working software that solved the problem at hand, or so it seemed.

Unfortunately, when we looked closer we realized things weren’t running quite as smoothly as we thought. Instead of being part of the decision making process on the most important business aspects, developers tended to accept business decisions as gospel and focused entirely on the technical implementation details. Although this seemed efficient, it undermined our ability to innovate because we were not truly leveraging all the intellectual capital our development team could bring. Far too often we focused too much on building features that the business wanted and thought they needed instead of finding innovative ways to radically improve our business. The same artificial divide between technical concerns and business concerns handcuffed our stakeholders and limited their ability to drive different thinking around implementation. Because everyone stayed in their comfort zone, we were having trouble actually driving innovation. 

Over the last couple of years, we’ve changed that in a big way by focusing more on building truly cross-functional teams of business and technology experts that work together to define, prioritize and deliver innovation.

Part of the solution is process. For example, our exploratory division has a fire team structure that combines one or two development teams with a dedicated leadership group that includes a PO, a UX expert, a technical leader and a business decision maker that work together to deliver a comprehensive solution for a big business problem given audacious goals and some basic constraints around budget and timeline. One of those fire teams is currently focused on revolutionizing the way we sell decks and decking materials online and in-store. We are also using the OKR framework from “Measure What Matters” to frame the objectives and how we measure results.

The bigger part is culture. For us , this starts with encouraging people to ask questions they wouldn’t normally ask. These days, it’s not unusual for one of our business leaders to ask a developer rather technical questions about a proposed implementation or for a developer to probe a business person for data to support a proposed story. A couple years ago, these kinds of questions weren’t asked because people naturally stayed on either the business side or the technical side. These days, we actually demand cross-functional debate.

Every initiative that we work on in a truly cross-functional way ends up delivering pretty spectacular results. For example, our core business used a cross-functional effort to double our services business over a period of 90 days. Furthermore, pretty much everybody involved ended up broadening their skill set. In essence, our developers are becoming better business people and our business people are become more technical. They are also enjoying the work despite the challenge of working hard to deliver on some pretty audacious goals.