Natalie Hanson Principles & Practices of Agile
This Part 3 of a 4-Part series on Agile.
The Agile Manifesto resulted in a set of twelve principles which provide further guidance on how the goals of the Manifesto will be achieved, including early and frequent delivery of software, regular face-to-face collaboration between business stakeholders and developers, and fostering a self-organizing and motivating environment for developers to work. Perhaps most importantly, the final principle is one of change and continuous improvement as a competitive advantage. These tenets have much in common with Lean – both in the aspirational tone and the content. (If you don’t know anything about Lean, you can read some of my blog posts on the topic, here.)
The goal is to get a Minimum Viable Product out the door as quickly as possible, and – like the pull model in Lean – use those experiences to drive direction and future improvements. The reasoning behind this approach is that the first product (or major new capabilities) to market enables the team to secure first mover advantage, which usually translates into a significantly greater share of a new or emerging market. This approach also seeks to ensure that the team produces on a regular cadence against the defined requirements, and that the outcomes are validated with business user or the market incrementally, leading to a better fit between what is being built and what the market demands. This is possible in part because business stakeholders do not disappear after a requirements document is completed; those individuals (or a well-informed proxy like a product manager) remain available on a bi-weekly basis (or even more frequently) to ensure that questions from the project team were answered in a timely way.
Over time, this new way of working has resulted in a host of other changes into how software development projects were structured and managed. For example, development teams that take an Agile approach typically meet on a daily basis to talk about the status of what they are working on, where they might need help and so on; that daily meeting is called Scrum. The term comes from rugby; unlike American football where the ball is passed or handed off for an individual to progress down the field, in rugby the ball moves down the field protected by a cluster of teammates.
All members of the project team – from business stakeholders to product managers to developers – participated in early definition of the product, so that the engineers could remain true to the vision of the solution as they sought the best technical approach. At the highest level, this methodology has four major elements to it. The largest box represents the Roadmap, which might be planned at a high level 1-2 years in advance. Within the Roadmap is a series of Releases. Releases are comprised of a series of Sprints, which in turn are comprised of User Stories. [You can click on the image below to see it full screen.]
Each milestone in that roadmap is deliberately not defined at the beginning – objectives further out are left at a high level. This is sometimes described as an inverted pyramid. Those activities in line of sight are at the top and defined in the most detail; the work further out is still only generally understood and planned.
The rationale of this approach is to ensure that immediate priorities and next steps are clearly defined for everyone involved. This also allows time for further discovery – about markets, users, or technology – in areas that may not be sufficiently understood. However, until those early building blocks have stabilized, building a house of cards on top of them is not recommended. That means that Big Up Front Design (BUFD – I’ll talk more about that below) is a risky proposition. Not having the complete picture may be disconcerting for those who have never worked in this way! In fact, there are some things (such as the overall Information Architecture or navigation of the application) which may difficult (if not impossible) to execute in a piecemeal way.
However, the benefit to this approach is that it enables the team to remain flexible and adapt to changing circumstances (e.g. unexpected technical hurdles) while still sharing the same desired outcome. The challenge for all User Experience professionals (including researchers) in these teams is that it does require continuous involvement and attention as priorities, approaches, and planned deliverables shift.
In the following section, I’ll describe each part of the methodology at a high level, describe some of the typical activities at each step, and elaborate how a researcher might expect to engage.
The Roadmap
At the outset, a common understanding of the project is achieved through a workshops or a series of them, if needed. Through these, the team achieves a shared vision or Roadmap. This might include an understanding of the markets for which the product is intended (and therefore what price points and project costs need to be considered), what capabilities are the most critical, and so on. This exercise might be conducted only once a year, maybe twice if there is a lot of ambiguity or change. This is not necessarily a research-led activity (although it could be – more on that later); oftentimes the product owner (who could be a business stakeholder or a product manager) leads this effort.
The Release
The shared Roadmap is broken into Releases based on business objectives, what is technically feasible, and so on. As mentioned earlier, the most current part of the Roadmap (e.g. three to six months out) may be well defined, but oftentimes beyond that the team sticks to more general descriptions of what will follow.
What if you arrive into a project team that has already established a roadmap, and perhaps plans for the next release or two? The key is to align with other resources that are planning more than one sprint ahead, for example a systems architect or a business analyst. Recognize that many teams have a Sprint 0 (zero), which is a planning window that overlaps with the end of the previous release. So it might look something like this, rather than the figure above:
There are numerous presentations and articles that argue in favor of this approach, including James O’Brien’s The Secret of Agile UX, and Anthony Colfelt’s Bringing User Centered Design to the Agile Environment. After some elaboration on both user-centered design and agile methods, Colfelt proposes the following approach:
In essence, Cofelt is proposing some up front research and iteration (either in advance of development or at least a few sprints ahead). My experience and recommendations are similar, though from a staffing perspective it is really tough (read: almost impossible) to have a single researcher that can look at foundational research questions early in the iteration or product lifecycle, and expect that the same individual can test and validate with users during the active development cycle. Whether you’re an individual contributor or a UX team lead, at some point you’ll have to make tough decisions about how you can best contribute. Let’s assume that the product vision is set and some good information exists about the target users (I’ll talk about alternate scenarios in a subsequent post). For the moment that means you can focus your UX capacity on getting the best possible product out the door.
A good team player (you want to be a good team player, don’t you?!) will keep in mind what the rest of the team is trying to accomplish. The goal is to achieve a Minimum Viable Product (or a Minimum Usable Design). Remember that design is never finished; unless a product is approaching end-of-life or the team is being disbanded for some reason, there are always opportunities to engage and provide user insights! Since the team is trying to get a Minimum Viable Product out the door, user-centered design testing and validation should focus on supporting that goal. Aligning UX to the Minimal Viable (or Valuable) Product may be harder than you think. What has to be in? What can’t be out? If a UX designer is contributing to that product vision, the improvements to the design need to be given the same consideration. Some authors have called this Test Driven Design, Minimum Viable Design, or MUD: Mininum Usable Design. But the short version is that testing needs to be considered at the outset. In addition to being practical, it will ensure that the UX team garners the respect of the larger team. In an article called Have You Tried Talking to Your Customers?, blogger and COO Des Traynor says that “The quality of a product depends not just on the ability to generate ideas but also the ability to test and iterate through them based on good feedback.”
So if you find yourself in the deep end, where do you begin collecting and providing that feedback to the project team? Options include testing the existing product, using paper prototypes to test divergent design ideas, or reviewing customer support data to identify opportunities for further improvement. As with other project phases, the key to making a contribution is to understand the roadmap, what releases are forthcoming, what is known (or not) about the Epics or User Stories that are on the horizon, and even what user problems or bugs have been reported.
How do you ensure your insights get incorporated into what the team has planned? As described earlier, both releases and sprints have a planning phase (sometimes formally established as Sprint 0), which may overlap with the tail end of the previous release. Agile project teams use an artifact called a Backlog to collect all of the key themes that were established in the initial planning meetings, as well as new issues that emerge over time based on feedback from customers or members of the team.
Although release and sprint planning are regular occurrences, in general they do not attain the same level of breadth as the early planning sessions where the vision and roadmap has been established. However, in these meetings the items in the Backlog are refined and reprioritized, as needed. Although these meetings may be extremely detailed and technical, engaging in them is critical for understanding and influencing what the development team does next! This approach also makes it possible to incorporate both small and larger issues into the Backlog for inclusion into an upcoming release or sprint, as appropriate.
The outcome of a Release is something that is usually complete enough that it can be released to the market. The Release is executed through a series of shorter working bursts called Sprints.
The Sprint
Sprints are two to four week increments during which the developers are required to produce fully functioning features or capabilities that can be demoed, reviewed, and validated by the whole team during a Sprint Review. This truly means the whole team – business stakeholders, researchers, product management, quality assurance (testing), and the developers.
This style of working is what I think most characterizes Agile, and the piece that is also the most different from the traditional waterfall approach to software development. Teams meet in Scrum (or Stand-up Meetings) on most if not all working days. They check in about what they have completed, what remains to be done, and where they are stuck or might need to interact with another member of the team. Although these may appear to be very technical discussions, these are often the moments where clarifying questions may be asked about the rationale or the behavior of a certain feature. If a researcher or designer is not present, it’s quite possible that the work will deviate from its original intent, and be hard to address later.
Each of the developers selects or is assigned or selects User Stories to work on during the Sprint. During the Sprint Planning, they often use an exercise called Poker Planning to estimate the amount of time the work will require, what other team members they will need to collaborate with. In all cases, they will work with a testing (Quality Assurance – or QA) resource to agree on how their work will be technically tested before Release.
At the end of the Sprint, the team should be able to demo a piece of functionality that is complete and shippable. This is another great time to participate and see if the emerging product is consistent with what you’ve learned from your user community.
User Stories
When I was first exposed to Agile, I remember being thrilled that the team was talking about users, and user stories! I thought – “Wow! They are already taking a user-centric approach to development!” That excitement was quickly followed by surprise and dismay when I realized that these stories were not ‘owned’ by the User Experience team, but rather that they were defined and elaborated by the whole team.
Many authors have described the centrality of user stories in the agile development process. These artifacts are a radical departure from the monolithic requirements documents of the past, as they are jointly created, refined, and iterated as the team’s understanding evolves. In its simplest form, the user story describes the individual engaged in a task, what they are trying to accomplish, and why. In the early days of Agile, stories were written on index cards. As practices have matured, most stories are now documented electronically, often in specialized software where they are eventually broken down into work tasks for the various technical team members. This approach also enables the team to track completeness, which has been achieved if all the criteria of INVEST (Independent Negotiable Valuable Estimable Testable as defined by Mike Cohn in his book User Stories Applied) have been met.
The stories are likely the last moment in which user insights will be discussed in a form that is understandable to a non-developer, and so they are a critical locus of engagement for researchers. User Stories provide a great means for researchers to engage with the project team, because well-written user stories focus not on tasks, but truly on the people who will use the software and their desired outcomes. As Tony Ulwick says we have to be cautious not to let the tail wag the dog. That is, we should not conduct research in the service of a specific feature – rather, our starting point should be to achieve an understanding of our target users. Otherwise the risk is that we come to the conclusion that people want a quarter-inch drill, when in fact what they truly want is a quarter-inch hole. Along the same lines, User Researchers can contribute to the creation of user stories by ensuring that stories focus on experience and outcomes, and not just on tasks. In two very thorough articles about the UX of User Stories (Part 1, Part 2), Anders Ramsay says we can help make the transition:
- A user story might read: “I often order the wrong part, because the part numbering system is confusing. It wastes time and makes me look stupid in front of customers.”
- Instead, we can modify it to read: “Help me make users feel confident their donation is going towards the actual cause, so they’ll want to encourage others to donate.”
The second example focuses on outcomes, so that the user can recommend (and/or the designer can look for) multiple ways to solve that problem. This reminds me of a quotes which was attributed via the Internet to Mathieu Lehanneur who said “do not ask a designer to design a bridge, but ask him to design a way to cross the river.” In a similar vein, author Cagan [see correction in comments below] writes about Why We Need Storytellers at the Heart of Product Development. User Experience teams often report into Product Management, which in turn is often placed within the engineering organization. He says that “Ultimately, an engineering organization is focused on execution and that culture is not optimized for the process of discovery, curiosity, and play, all of which are fundamental to those who engage in storytelling.” The researcher has a critical role to play in ensuring that the user’s perspective and experience is not lost as the product is engineered!
In Closing / Learn More
In my fourth and final post, I’ll talk more about the general implications of Agile for UX professionals – especially researchers.
Natalie Hanson 
I just stumbled upon this post. Towards the end you say that Cagan wrote the article “Why We Need Storytellers At The Heart Of Product Development” (from UX Magazine). I just wanted to point out that I wrote the article. I’d really appreciate it if you could update your blog post to correct that.