Design Lessons from a Year in Agile
(I wrote this last year on one of Moment’s other blogs — reposting here since it’s still true.)
Last year, one of our clients decided to make the move to Agile. This was a big deal: the organization had a long history of working waterfall with all of the meetings, documentation and planning practices that come along with it. The big motivator was speeding up the release cycle, and our clients reorganized many of their employees and redefined many of their processes to ship product improvements more frequently.
“Big company makes big changes to make production more efficient,” is a pretty familiar story these days. Agile has become a very common way to achieve that efficiency, and Agile is all about throughput. The whole assembly line breaks down if every team isn’t delivering work at a steady clip, and so the process is far less sensitive to the quality than it is to the quantity of work delivered.
We’re a strategy and design consultancy, so we’re naturally inclined towards big picture problem solving. We often work with our clients to define, shape and design an entire digital product. This time, the project brief was really different: we were asked to be part of the production design team feeding several scrum teams with small and medium feature enhancements.
Our client has a defined product voice and strategy, and we’ve worked with this client on several large projects to make new features that are considerate of that strategy. With those big projects, it’s far easier to apply an existing product strategy deliberately and consistently. When we have ample time to do discovery work like opportunity mapping, we often find that we’re helping to build on that strategy as we implement new product features. It’s really hard to be true to the overall product strategy when we’re only considering a tiny slice of the product a time and we need to get new design shipped as fast as possible.
We entered this Agile experiment mindful of these challenges, but totally unaware of several others. Over the course of creating about 100 small and medium feature improvements with our clients, we continuously refined our process. Here are a few of the things that we learned along the way:
Respect the design process
Our design process demands that we understand a problem before we can begin to solve it. This is a pretty simple tenet that can be really difficult to apply while working on 12 user stories at a time, but all of the problems we experienced in the last year can be traced back to this fundamental point. In order for design to work, even within Agile, there has to be time for the design team to define and understand the problem. If that means that the team can’t take on as many stories at once, then that’s a good trade off since it results in better design and a more efficient process.
Ask “why?” early
A product backlog is fed by so many different stakeholders with so many different motivations. Those interests are almost never reflected in the user story, so if we take every request at face value, we’re going to be making assumptions about the rationale for a change. Asking “why” helps to answer those questions so that the design team can be confident we understand the business/tech/user needs driving a change.
As part of the group responsible for overall product UX, we found ourselves occasionally questioning the utility of a particular feature change. Sitting down with the person who made the request opens up the opportunity for really valuable conversations about the range of possible approaches for achieving a particular goal, which may or may not include the solution requested in the original user story.
Treat small problems like small problems, and big problems like big problems
When you read a list of 40 user stories like “Add feature X,” and “Improve feature Y,” there’s a weird flattening effect; because the user stories themselves are only about 30 words long, it seems like they should all require equal effort to design and return equal user and business values. Obviously, this isn’t true, and identifying and clearly communicating the relative importance of a user story is the best way for all stakeholders agree on the appropriate level of effort to design and build the solution.
Sometimes, that “Update feature Z,” story really will be a quick design enhancement. The best way for a design team to build credibility within an Agile organization is to identify those quick wins that help to feed the Agile machine. However, that 30-word user story could raise fundamental questions about feature or product strategy. When this happens, it’s far better to shape the approach to solving the right problem than it is to try to ignore those questions and forge ahead. Sometimes the right approach with these secretly challenging user stories is to kick them out of the normal scrum cadence and turn them into larger projects.
Deliver to the right fidelity
This is a bit obvious, but Agile doesn’t work if the expectation is to deliver waterfall-style documentation. This definitely applies to design specs, but also to presentations, project plans and almost every other type of thing that we make as design consultants.
One specific example: Early in the year we found ourselves making a lot of formal concept decks to present potential approaches. Actually sitting down to make those kinds of decks can be really important, since it makes you actually consider how to tell the story of a particular concept. However, what we discovered is that the deck as a format is simply not a good fit within Agile — it takes too long to make, no one has time to actually sit through the presentation, and no one is going to take the time to read it outside of the context of a meeting.
Once we made this discovery, we started going into meetings with our rough sketches instead of resolved decks. Beforehand, we’d meet as a small team to plan the presentation and talk about the key goals of the meeting and the story points we wanted to cover. Once the meeting started, we’d ask people to stand up and walk around to view the sketches. Not only did this force us to shorten our presentations to focus on the most essential pieces, but it also signaled to our meeting attendees that we needed them to participate actively in the process in order to make decisions and respect tight deadlines.
At the end of this year of working Agile, it’s really tempting to compare this mode of working with our more typical, deliberate and paced mode of working. I think that our team would agree that there are some frustrations inherent in using Agile to manage a design process. However, we got to see the product change 100 times over the course of the year because of the work we were doing, including some really meaningful UX and business improvements. Would we choose to run every project as an Agile project? Probably not, but the experience of the last year has given us a lot of opportunity to refine our own processes and clarify the way that we can be mindful of our role as facilitators in the design process.