Can I have it all? This deceptively simple, highly contested question captures dreams for our personal lives, work ambitions and even balancing the two. As it happens, many clients ask the same of their digital projects, expecting user-centred design (UCD) to be effortlessly merged with an Agile development approach. But how do agencies make this happen in practice?
Clients are more and more aware of the well documented benefits and practical applications for both Agile development and UCD approaches. The combined impact is truly powerful, rapidly delivering tangible software that offers a great experience to users. On the surface, the methodologies should work well together, with iterative, constant refinement at the core of each approach, and validating projects through testing with real users.
But in practice, the two approaches are worlds apart. For instance, rapid Agile production demands minimal up-front planning, while all decisions under UCD are defined by meticulous research. In addition, the combination can present a political minefield, as Agile is typically developer-led, while designers drive user-centred design.
This article recommends practical ways to overcome the conflict. The advice is guided by what my team at Cyber-Duck learned working with Cancer Research Technology (an arm of Cancer Research UK), launching Ximbio: a crowdsourced life science marketplace. By the end of the article, agency designers and developers will see how they can (and must) re-frame their deliverables, production process, and team collaboration to strike the right balance.
Degrees of Integration
No two projects are the same. Even if agencies have a preferred approach, they tailor the production process to the unique business challenge, scope, and requirements of each client. Most adapt a methodological development framework for this, often choosing whether to remain with the traditional Waterfall approach, or try Agile.
With Waterfall, projects are produced through distinct, linear stages, and work is finalized and signed-off before each new phase begins. User requirements and final deliverables are based on research documentation completed early in production. Generally, no working software is produced until a late stage. This is a risky process for the constantly changing digital environment. User requirements could change during lengthy production; even if early models are shown to users during testing, this may not convey the final product enough, and users may not connect with the final product.
So in my view, production teams should always adopt an Agile approach—to some degree.
The beauty of Agile is that teams can experiment with their adoption of the approach. In some instances, teams can go “partially agile,” or what I would call agile with a lowercase “a.” This means they would apply the original, broad principles of the Agile manifesto in whatever way suits their own unique workflow, and helps them to release working software more quickly.
Five Challenges
Now that we have a basic understanding of Agile and agile, we’ll continue by exploring five challenges and opportunities the combined UCD and A/agile approach provides in practice.
1. Price by Sprint
Pricing can be particularly challenging for the combined approach. Agencies habitually revolve around the “billable hour,” and provide clients with fixed quotes based on man-hours. This suits the research-driven nature of UCD, particularly with a pre-defined scope. Agile complicates this calculation, with work based on flexible sprints that respond to changing needs. Thus, a combined approach can make initial negotiations with clients tricky.
For instance, when Cancer Research Technology approached us, it was clear they would benefit from an Agile approach. They were launching a unique business model and needed the flexibility to respond to feedback from future users and the changing market. But, they also had a fixed budget, timeline and predefined vision for Ximbio: all qualities far more typical of a fully-scoped UCD project.
Extending Agile’s adaptive philosophy even to the proposal level was critical. We turned our proposal into a flexible vision for the overall project. The work we needed to achieve the Minimum Viable Product (MVP) was divided into four sprints, with an outline of production activities only. This allowed us to update the specifics of each sprint during production, while cementing the overall vision for deliverables, timeline, and resources from our team.
2. Create a Cross-Functional Team
Another challenge some agencies face is involving all members of the team from the start. By nature, Agile is a production process that requires a highly collaborative mind-set. This marries well with UCD, which attracts perceptive individuals striving to understand and frame their designs to aid users. Agencies must collate a team full of flexible, multi-disciplinary individuals who can work well together—a huge shift from other development approaches, which expect departments to complete each production stage almost independently, handing over the work completed.
For the combined approach with Agile, it’s particularly important to involve the entire team – from product owners, UX designers, developers, quality assurance, and so on – from the very outset. Contributing to the original vision builds commitment, maximizes collaboration and improves efficiency throughout production.
Although no major development work began in our first sprint with Cancer Research Technology, our developers were fully involved. As UX specialists defined and prioritised user stories with the product owner, the developers defined all the acceptance criteria required to sign-off each feature. The collaboration ensured that any high-level design ideas were achievable in code, and developers identified a “risk register” of tricky items that could throw curveballs in production. Realizing the disruptive potential of several features meant we could explore potential solutions early.
3. Simple, Quick Documentation
One opportunity that not enough Agile/UCD teams enjoy is the ability to produce simple, quick documentation. It’s easy for agencies to use the Agile Manifesto’s tenet of “working software over comprehensive documentation” as an excuse to not create any documentation. But it’s important to retain a record of deliverables, discussion and decisions, so the team can progress. Agile intends for us to avoid compiling lengthy and unnecessary studies or reports, but there is a middle ground in lightweight reporting, which communicates precise, actionable insights in a targeted way.
For collaborative works in progress, low fidelity wireframes are a great way for the production team and stakeholders to review, edit and update ideas. Tools like Basecamp, with integrated revision control and collaboration features, can also prove useful for writing and sharing user stories in real time.
Our team for Cancer Research Technology created minimal documents to explain our plan for taking the information we learned in stakeholder interviews and user testing and using it in subsequent sprints. During our project, we found highly visual show-and-tell presentations to our team and the client’s team communicated our ideas and helped us track progress better than lengthy reports would have. At the end of each sprint, we also used in-person retrospectives to reflect on what was working well, what we should stop doing, and what should continue. Each meeting concluded with a distinct summary of the next steps and scheduling the next face-to-face meeting.
Show-and-tell presentations summarize and evaluate work, providing key input for subsequent sprints. Having a consistent amount of “face time” can improve collaboration and productivity.
4. Introduce Sprint Zero: Research and Planning
I mentioned earlier that one major challenge for UCD and Agile teams is the tension between creating a full plan, and iterating flexibly. “Sprint Zero” (no, it’s not a new phone plan) is the key to easing this tension. Before full production gets started, our designers establish this sprint, with a pure focus on formulating the user experience requirements.
Following the traditional “assume nothing” tenet of UCD, Sprint Zero establishes evidence-based user requirements for the final product, informed by meticulous persona and stakeholder research. Sprint Zero helps mitigate the fear that designers will be forced to abandon user research when moving to agile sprints. The Nielsen Norman Group describes “discount usability methods,” like paper prototypes, to accommodate the short timelines.
5. Structure Via Epics
Of course, a UCD research-driven Sprint Zero is not enough to fully integrate the two approaches. Carrying user-focused research into subsequent sprints and allocating time for considered design is equally necessary, and even more challenging.
If Agile is carried out to the letter, all work for a feature should be completed within the same sprint. But, this rarely gives designers the time or holistic user perspective they need. Instead, during Sprint Zero we define high-level “epics” (or goals) that establish the key aim of each user group. Then we draft acceptance criteria to validate whether an epic has been achieved.
Epics and their requirements are written in a personal way. They can help designers and developers view their product through the eyes of their users. Each story is then broken down for the team to explore further and resolve over the course of the sprints.
Avoid design fragmentation by drafting epics first, which capture the main aim of each user group. Then, each sprint can tackle user stories that work towards this goal.
In particularly complex projects, we even break stories into two sprints. Designers work during sprint one, and then pass their designs to developers in sprint two, while moving on to another challenge. This can give designers enough creative space to consider, research and solve the “big challenges” that underpin each story.
But be warned! Don’t slip into silos. If designers and developers are working on different stories, reserve time for “show and tell” meetings to share work and collaborate. As Steve Jobs once said, “design is not just what it looks like and feels like. Design is how it works.”
Experimental Steps Forward
Once considered the nirvana of software development, Agile development, which is part of one of the basic types of software development, can be even more powerful when fused with sound UCD methods.
Before UX production teams and agencies can tap into a combined approach, they must carefully evaluate the degree to which Agile suits their staff and the project in question. Teams thinking that an Agile/UCD combination might be the right approach can get started today:
- The Nielsen Norman Group shares plenty of great Agile/UCD resources. They explore the benefits and challenges of integration, using interviews with eight UX professionals.
- Experiment with the five opportunities for integration I’ve described above: from pricing by sprint, under a flexible vision; to structuring sprints via epics, and understanding how far designers may wish to work on complex stories in advance.
- Then, discover what works best for each team’s unique dynamic, and scenario in question.—and don’t be afraid to ask for feedback! Testing with production of internal R&D projects can help, where it’s possible to try out new approaches without impacting client launches.