Agile Won’t Get You to Done: Here Are Four Ways to Fix That
Last month, Jeff Gothelf and I were at Barcelona’s annual Llum festival, an amazing event that features light installations stretching across Barcelona’s Poblenou neighborhood.
Some of the installations were breathtaking. Others were downright baffling. Looking at one particularly confusing student work, Jeff turned to me and asked, “How did they know they were done?”
Definition of “Done”
How do you know you’re done? For artists, this is a hard problem. (DaVinci is supposed to have said no work of art is ever finished, only abandoned.) But artists aren’t the only ones who struggle here. This is hard problem for technology teams too.
Tech teams have invented countless ways to solve this — with specifications documents, and requirements documents. With acceptance criteria and user acceptance tests. And with what Scrum — the most widely adopted agile framework — calls the definition of “done.”
The definition of “done” is a shared standard that Scrum teams create to determine when each work item they undertake is complete. Scrum values “done” so much that it insists that the fundamental objective of every sprint is to get to “done” for all the work you’ve planned in that sprint. Don’t think you can complete the work in that time period? Then break it into smaller pieces until you have work that you’re confident will get to “done.” But you have to get to “done.”
The Problem With “Done”
This was on our minds in Barcelona because over the last few months, Jeff and I have been working with Scrum.org to develop a new course that’s all about how to successfully bring UX methods to Scrum.
If you’ve ever tried to add UX to Scrum, you know that you can run into conflicts. For the most part, these conflicts are tactical. Scrum and UX share the same high-level goal, which is to produce great products and services that create value for people. But sometimes, the methods are difficult to reconcile.
One of the biggest conflicts we had to resolve as we created this course involved this idea of “done.”
Scrum defines “done” as working software. Traditional UX practice defines “done” as designed and tested with users and revised as needed to ensure the design works for users. Lean UX added another layer, borrowed from Lean Startup, that the design is done when the product creates the outcomes that users, customers, and businesses seek. We use the word “validated” for this idea. So, the design is “done” when we’ve validated it.
So, we have three different concepts to describe “when-the-work-is-finished.”
- For traditional UX work, “done” = designed and tested with users and revised as needed.
- For Lean UX, “done” = validated
- For Scrum, “done” = working software.
These are not the same thing at all.
The Conflict Between Done and Validated
When teams struggle with these ideas, it usually shows up during planning. UX people, thinking about their traditional meaning of done, will ask for more time to complete their work. “We have to design, test with users, and then revise.” This can frustrate agile teams, who have more flexibility to scope down in arbitrary ways, and find it easier to fit incremental work into sprints. Designers get blamed for blocking team progress. And everyone feels frustrated.
Four Tactics to Resolving the Conflict Between Done and Validated
Working with Erik Weber and Gary Pedretti, two fantastic Scrum trainers, Jeff and I worked through this conflict as we created the course. It took a lot of work to sort through the problem, but based on what I learned over the last few months, here are my recommendations for resolving the conflict between Done and Validated.
1. Scope down and deliver every. single. day.
The best team I ever worked with had two simple guidelines for managing the stories they worked on.
- No story could take longer than a single day to complete. If a story was going to take longer than a single day, it had to be sliced until it met this criterion. (On rare occasions, the team would encounter a story that took two days, and was flexible enough to allow these.)
- Every story had to create a visible feature or change to a feature so that the client could accept the story.
These two rules were remarkable in their power. They created transparency and trust. They created comfort with incomplete features. We all came to understand that the features we were seeing were continuously evolving, and created the conditions in which is was possible to continuously evolve and refactor the user interface of the system.
2. Commit to evolving and refactoring user experience.
One reason designers want to adhere to an older idea of “finished design” is that product teams tend to de-prioritize user interface work in favor of “new features.”
But this gives birth to the twin sister of technical debt: experience rot. Experience rot happens when features are launched with half-assed user interfaces and then abandoned. It’s created by launching feature after feature until they pile up like crappy plastic merchandise in a dollar store. At some point, you have to go back and integrate all these features. The same way that technical debt accumulates if you don’t pay it down constantly, experience rot must be refactored away on a continual basis. When your team sees that it’s possible to continuously evolve the user interface (see #1 above), you make this refactoring possible.
So, commit to making every story create a visible change, and you’re on your way to continuously evolving and refactoring the user experience.
3. Give up the traditional UX notion of “finished design.”
Design is never done. The context of use into which you’re delivering your product is always change — in no small part because if your product is successful it is creating changes to the user’s environment! So get used to the idea that your design is going to evolve forever.
Also, accept that usability testing your design pre-release (while crucial) is not the same as validating your product. There are things you’ll never learn by testing in a lab context. At some point, you’re going to have to see what people actually do with your product. You will learn that when your design goes live. So get used to both testing pre-release and validating post-release.
4. Recognize the difference between “done” and validated.
“Done” has such magic power in the Agile world because so many teams are struggling to simply ship software on a regular basis. Being able to do this is no small achievement, and I don’t mean to discount it in any way. (If you can do this, look your team-mates in the eye at your next retro and recognize how privileged you all are.)
But “done” ain’t finished. Not by a long shot. “Done” just means that you’ve created an output. Congrats, you shipped a feature! The bigger question is this: did that feature create value? You need to observe that feature in the wild to see if it created the outcome that you want for your customer and your business. If it didn’t, that feature is pure waste. It’s overhead. It needs to be refactored until it delivers value, or you figure out what does deliver value.
In other words: “done” gets you an output. “Validated” gets you an outcome.
Professional Scrum with UX
Want to learn more about all of this? Take a look at the course that Jeff, Gary, Erik, and I put together for Scrum.org. Professional Scrum with UX is a 2-day deep dive into all of this. It’s pretty cool.
PS: When is art done?
I can’t help you much on this one, but sometimes, it looks like this:
