Over a decade ago, while I was managing the UX team at TheLadders in NYC during the company’s transition to agile ways of working, the creative director on the team at the time said something to me during one of our regular one-on-one meetings that’s stuck with me ever since. “All this agile stuff has got me frustrated. It feels to me like we’re always racing for the bronze medal,” he said. It took me aback and I had to clarify what he meant.
He elaborated, “The way we used to work, there was a clear sense of what done meant. We had a deadline. We had a design to implement and we had to build the best version of that we could in the time we had. In that world we were always racing for the gold medal. We pushed ourselves to build the best thing we could in the time that we had. Now, with endless 2 week sprints, we do just enough work to keep the developers writing code, never going back to actually improve those designs. We’re comfortable with third place and we never truly try to make a gold medal product design and experience.”
He was right. And that brilliant analogy, the one that’s stuck with me now for nearly 13 years, made clear to me that if we were going to build truly cross-functional, customer-centric agile teams we would have to redefine success. I also wanted to answer his question: how do we build gold-medal products with agile?
What this conversation exposed was how we (and many teams still to this day) change their ways of working, their vocabulary, their team structures but never rethink how success is measured. They don’t change their definition of done. For most teams, as long as the feature does what the it’s supposed to do — i.e., works as designed — then it’s done. In that world, agile teams, especially truly cross-functional ones with designers dedicated to them, do bronze medal work. There’s simply no way to design gold medal work in a two-week sprint. At best you can get a decent pass at a set of design and user experience assumptions into production. But then, you have to see how well they worked in the market, with actual users at scale. That learning provides the team direction on how to improve and optimize the user experience. It gives the team direction on how to reach a gold medal experience.
But the team (and the organization) has to be willing to go back and do the improvement work. We call this iteration and it’s the key to agility and gold medal user experience. To build iteration into our ways of working (you’d be surprised how explicit you have to be about it despite it being a core tenet of scrum) we have to redefine what “done” actually means. It can no longer mean “works as designed.” The new definition of done, the goal the team is striving for, is meaningful, positive changes in the behavior of our users and customers. As Josh Seiden brilliantly lays out in his book Outcomes over Output, redefining done as a user behavior exponentially increases the amount of iteration a team does, amplifies the learning it’s taking in from the market and inspires greater org-wide agility.
If you find yourself working to feed the software engineers “dev work” simply so they can “stay busy” ask yourself how the quality of the work being shipped to market is being affected. Are you truly delivering gold medal work or are you racing for the bronze? If it’s the latter, it’s time to rethink how you define “done.”