An indepth look at merging Agile development with UX and user-centered design.
Agile is, at its heart, a flexible risk management method. But that flexibility can have a dark side. In fact, the better the development team is at applying agile the greater the danger of the organization becoming wrapped up in successful short-term efforts and not focusing on the big picture. When forming an understanding of how UX and user-centered design fit into Agile its important to remember that, while making huge strides towards transparency and centering development around the real needs of a development team, Agile doesnt solve the basic challenge of delivering high value products, and can even create new problems. Agile can become a crutch for organizations lacking strong long-term leadership.
What is Agile?
Before we dive into how Agile and UX can be integrated lets do a brief overview of Agile itself (or SKIP directly to Agile and UX).
The Agile movement has become the dominant project management method, but its basic approach is much older than that and dates back to the means of quantification developed by Galileo, Descartes, Newton, and other luminaries of scientific thought. It can be summed up as three basic steps: intuition, demonstration, and experiment. Each of the scientists mentioned substituted their own language to describe each step and each used their own instruments of measurement, and Agile does as well, but the fundamental steps remain the same.
The Agile Manifesto was written in 2001, its four tenets are:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
And within the many Agile frameworks there are some key practices they share are, including:
- Create a list of prioritized work, and break down the list into smaller actionable items.
- Clearly display to-do lists and accomplishments.
- Do work in set time periods (sprints).
- Hold short daily meetings for the whole team, encourage everyone to share.
- Hold reflection meetings to discuss what went well, what went wrong, and what can be improved in the next sprint.
XP and Scrum are two of the most popular frameworks under the Agile umbrella, but Agile is flexible and open to other permutations and experiments depending on the team or project. For example I developed the no-handoff Agile method initially to solve one specific problem: the difficulty of integrating design and code into a cohesive team. The main goal of Agile is essentially managing risk and delivering value but its exact implementation is up to each team.
Agile has become dominant because it works, period. But it doesnt do everything well, atleast not without deeply thinking about its best application in specific scenarios. Instead of adhering to established practices to the detriment of real project needs its healthy to ask what is the role of Agile for my team that will truly lead to the best results?
<a name="agile-ux"></a>Agile and UX
This became especially clear to me when trying to integrate UX and development into an Agile process. Most development processes are geared towards rapid delivery which naturally preclude high-level, time-consuming planning periods. UX in this environment runs the risk of being squeezed into a form where it loses much or all of its value. Im sure this is a familiar and painful scenario for any UX manager, and I recommend this excellent review of how Agile can go bad by ignoring UX.
The revolutionary aspects of Agile are its cross-sectionality, in its simplest form getting everyone into a room daily to share information, insights, and support (per Agile Manifesto “Individuals and interactions over processes and tools”). Even when this concept is expanded to include all disciplines (this case study on NPR and agile is worth a read) still, from the perspective of a rapid iterative development process, it doesnt leave room for high-level planning over a longer timescale than the current sprint. UX deliverables take time to mature and this causes a potential conflict.
Agile development also assumes that requirements are in place, and that they are based on good research and sound reasoning, without in fact including planning and documentation into the process, or even purposefully omitting it (per Agile Manifesto “Working software over comprehensive documentation”). UX is a research, planning, and documentation process, seemingly at odds with Agile development. The no-handoff method seeks to integrate UX and development (as well as other disciplines like security and accessibility) into a holistic agile environment. Bringing all disciplines, including development, into user-centered planning adds value, richness, insight, and the potential to leapfrog issues and save time.
Agile is critical to all my projects, but we shouldn’t mistake Agile as a complete path to project success. The tension between Agile and UX can be found in the words of Galileo himself when he writes “Measure what can be measured, and make measurable what cannot be measured.” UX exists in the realm of trying to make measurable what cannot be measured, while Agile processes are built around what has already been measured accurately. This natural tension will be familiar to anyone who works in development, design, or other web development fields that fall on one side or the other. But just as Galileo merges the two processes together in his life, so must we in our teams. They are two sides of the same coin.
UX can be too documentation-heavy, take too much time with too much risk. Agile gets work done fast but doesnt do a good job of defining requirements or providing the long term leadership that guides the work. Agile is great at refining a product, UX is great at defining the scope of the product. Agile is successful at breaking down barriers and creating transparency between the production team and the customer while UX is successful at breaking down barriers with the end user, and forging shared goals within the team itself. Really sounds like they need to work together, right?
Working together with no-handoff
In addition to following the three basic tenets of no-handoff, lets futher breakdown of how UX and development can work together. My projects fall into 3 organic phases: Planning, Production, and Finalizing. The planning phase has flexible sprints with more open deadlines, while production and testing follow rapid agile iteration. I implement dual-track and parallel track agile methods during all three phases, though it might not look or feel like what you traditionally expect from agile at some points.
During the Planning phase the user experience team (who I call “UX guardians” to differentiate between the team and the shared goal of UX) takes the lead in developing the blueprint, the big picture. They cast a wide net and bring in information from as many sources as possible, including drawing on the combined experience of the team itself. Customer, business, and user requirements are researched and conclusions are tested, verified, deeply understood, and articulated into shared project goals. All disciplines are involved. UX does not generate a complete list and hand it around, that is a shared responsiblity of the team, but it is the role of UX to make sure all discussions are oriented around user needs and that all disciplines end up with clearly developed and articulated goals with the user in mind.
At this phase you might see sketches and whiteboarding and hear big, bold ideas floated. Different directions tested for merit and occasional messiness will ensue. This will feel familiar to the UI team, and may feel chaotic to development. During this phase ideas are brought into a rough working prototype. In my teams we skip the use of popular software like Sketch or InVision and go straight to a working prototype/wireframe. Prototypes are the shared language of the web and all disciplines can intuitively read and understand them. And frankly there is simply no other way to realistically communicate or analyze the success or failure of ideas.
Despite a potential difference in pace between this phase a development, planning is still iterative with cycles of planning/executing/reflection. Iteration and the basics of Agile project management are essential to user-centered design.
During Production UX/UI and Dev cross paths in iterative phases, with UI always just slightly ahead. Iterative sprints bring the prototype further to life in deliverable stages. UX takes the new development work and does user testing, gaining new insights into what works and what doesnt hit the mark. Development continuously integrates new insights from UX and incorporates updated UI. Focus on the 80% of functionality that servers 80% of users and makes up 80% of the site’s success.
Some risk and moving ahead of the known data is appropriate because the risk is mitigated by the rapid feedback cycle. The product cant move ahead in the wrong direction very far without quickly getting results back from UX and correcting course in development. That benefit goes the other way too… UX cant move too far off course without a rapid reality check from development as they deliver the next working iteration for user testing.
Production is the heart of the project, but the success of this phase is built on the strength of planning. A badly run planning phase will result in poor quality insights and undermine the success of the production phase, no matter how well executed each sprint is.
The Finalizing phase is similar to production in its workflow but centered around more in-depth testing of an increasingly refined product. At this final stage we are focusing on the 100% of users and 100% of functionality. User testing of more and more granular components brings insight for UI and development, but on a more focused scale. The agile principle most at play in this phase is risk management and not moving ahead of your knowledge and information. The pace will more closely match that of a mature product rather than a fresh, raw startup and be ultimately set by end user testing and the results that come in.
The heart of Agile holds incredible tools for teams to work together. Integrating UX and development however poses some challenges due to differences in pacing, tools, language, pressure levels, and expectations. It is not a problem with Agile itself, but with rather with the preconceived expectations that we bring to Agile. By setting aside some well established but misinformed expectations about the roles involved in web development the no-handoff method better integrates multiple disciplines and focuses the entire team around user-centered goals.
UX is not a team or a person, it is not a function, or a phase. UX is the ultimate shared goal of a successful web project and Agile is how we get there. Through this lens its no longer a misfit couple, but a match made in heaven! Parallel (or overlapping) tracks are not forcing Agile to be something it is not, it is simply using Agile principles to accomplish ALL of a projects goals, and not confining those principles to development goals alone.
Lou Schwartz. Agile-User Experience Design: an Agile and User-Centered Process. PDF file. 2013. https://pdfs.semanticscholar.org/59f1/259165f9537222140b5b90f1ea7bd59c56ff.pdf
Multiple authors. The Agile Manifesto. Website. 2001. https://agilemanifesto.org/
W Fisher Jr . Galileo and the Scientific Method. Website. 1993. www.rasch.org/rmt/rmt64g.htm
A. Blanton Godfrey. Quality Management. Article. 1997. https://www.qualitydigest.com/sept97/html/qmanage.html