Recently, I was able to take an Agile training course. While I have been able to operate in an Agile environment for over a year, and been around it for several more, I had not heard some of the philosophy over why things were the way they were within Agile. This background was both enlightening and comforting. There has been a lot written about how to fit UX into Agile, and I won’t cover that same ground - many have written about it better than I will. What I wanted to do here is delve into some of the other insight that I gleaned from my training.
The Agile basics
The first thing to understand when encountering Agile, is that Agile is an overarching project management philosophy (in direct contrast to Waterfall project management), and there are many forms that it can take – Scrum being the most popular, the one I am most familiar with, and the one I will be referencing here. Scrum is a methodology that defines both how work is planned and how products are defined. The two can be separated (although not really talked about in this manner), which I believe is important, because UX has a greater impact on the latter of these two.
The planning takes the form of sprints, which help define prioritized chunks of work to be done in that timeframe and sets a backlog of things to work on in the future. The benefit of Agile is that as the world changes, the backlog can be constantly altered and adjusted to take into account new information. This is a direct response to Waterfall, which sets a plan in motion and did not handle new information well.
The product team (those who are not developers), in conjunction with stakeholders, usually defines the chunks of work. The breakdown looks something like this. At the high level there are goals, which are decomposed into epics, with are further broken down into features, which are decomposed yet one more time into user stories (Note: I have worked in Scrum where the feature level was skipped). The developers then work at the user story level. They can take the user stories and build some amount of code, which allows that user story to be accomplished. The intent is that in the end, as the pieces are put together again, the defined system successfully allows users to accomplish their goals.
UX is Agile
The biggest insight I had, and has been with me since I started working in Agile, is that Agile and UX have similar ethos. They are both designed to get the right product to the user. They both are intended to work closely with users (and stakeholders), delivering frequently to ensure that user needs have been heard and are being met. In essence, UX is and has always been agile. It just hasn’t always been run in an “Agile” way. We were Agile, before it was popular.
The way that Scrum works is right in line with what the UX team is going to want to do, with modified responsibilities. The researchers will help define the goals of the system based on observing / talking with users and understanding their stated and latent needs. Some product owner or UX Strategist will help define approaches that may be useful in accomplishing those goals (the epics), balancing against company needs as necessary. The UX and UI designers can then work to design the interface (IA, Interactions, and Visual Design) to include the features that support all of this. Finally, the finishing touches involve including enough detail within the design artifacts that let developers understand how the various components in the design work – defining the user stories, essentially.
The development team can then take these stories and run with them. Good research up front will have helped inform the prioritization of features and stories to work on, with each release providing more information as guidance.
The biggest challenge is staying ahead of the development team, while still giving them enough to work on early in the project. The goal is to stay a step ahead of the development team, but good design will include user testing and likely several iterations, so while most advise starting one or two sprints ahead of the development team, this may not be enough.
To keep everyone on the team fully engaged, the development team can begin working on their research ‘spikes’, which help them get a grip on any outstanding questions of how new, applicable technologies might work, or how they can connect with partner vendors, or anything else that might come up. If none of these problems exist, they can use early looks at designs and concepts to work on data modeling, or failing that, start prototyping what they see from the design team.
This would be UX in Agile in an ideal world, which all too often is not what we get.
Where it all falls apart
The problems with UX in Agile come when the team falls back on bad habits during the definition phase. Rather than talking with users, the team makes assumptions (or uses poor research) about what the users want and need and make decisions off of these. This is not because of Agile methodology, but in spite of it. While Agile does have the benefit of more feedback with users to catch problems early, this process can only do so much. This approach also lends itself to tried and true, or fast follow, solutions, which are safer and easier to get user approval.
The other way it struggles is when the UX is only operating at the user story level. The team (likely not involving a true human-centered researcher) has decomposed the goals all the way down into stories. There are two challenges with this approach. First, this calls for a UI designer, not a UX practitioner. Second, the designer – UX or UI - is at a disadvantage because they have to design bottom-up, putting together a bunch of parts into a coherent system, rather than working top-down defining what the parts need to be. These designs end up feeling like a bag of parts, rather than something that is intentionally put together, and the user suffers.
In either of these situations, it is clear that the need for UX has not sunk in. This is not the fault of Agile, since how UX is implemented on the product teams is an organizational matter. Either the organization recognizes the need, or it doesn’t. Being Agile won’t make one difference if user research and human-centered design aren’t involved.
Deep down, Agile is about project management, working with users and stakeholders, and being responsive to changing situations. This is in harmony with UX, not opposed to it. The question shouldn’t be 'How does UX fit in with Agile', it should be 'How can you do Agile without UX'?
The Agile basics
The first thing to understand when encountering Agile, is that Agile is an overarching project management philosophy (in direct contrast to Waterfall project management), and there are many forms that it can take – Scrum being the most popular, the one I am most familiar with, and the one I will be referencing here. Scrum is a methodology that defines both how work is planned and how products are defined. The two can be separated (although not really talked about in this manner), which I believe is important, because UX has a greater impact on the latter of these two.
The planning takes the form of sprints, which help define prioritized chunks of work to be done in that timeframe and sets a backlog of things to work on in the future. The benefit of Agile is that as the world changes, the backlog can be constantly altered and adjusted to take into account new information. This is a direct response to Waterfall, which sets a plan in motion and did not handle new information well.
The product team (those who are not developers), in conjunction with stakeholders, usually defines the chunks of work. The breakdown looks something like this. At the high level there are goals, which are decomposed into epics, with are further broken down into features, which are decomposed yet one more time into user stories (Note: I have worked in Scrum where the feature level was skipped). The developers then work at the user story level. They can take the user stories and build some amount of code, which allows that user story to be accomplished. The intent is that in the end, as the pieces are put together again, the defined system successfully allows users to accomplish their goals.
UX is Agile
The biggest insight I had, and has been with me since I started working in Agile, is that Agile and UX have similar ethos. They are both designed to get the right product to the user. They both are intended to work closely with users (and stakeholders), delivering frequently to ensure that user needs have been heard and are being met. In essence, UX is and has always been agile. It just hasn’t always been run in an “Agile” way. We were Agile, before it was popular.
The way that Scrum works is right in line with what the UX team is going to want to do, with modified responsibilities. The researchers will help define the goals of the system based on observing / talking with users and understanding their stated and latent needs. Some product owner or UX Strategist will help define approaches that may be useful in accomplishing those goals (the epics), balancing against company needs as necessary. The UX and UI designers can then work to design the interface (IA, Interactions, and Visual Design) to include the features that support all of this. Finally, the finishing touches involve including enough detail within the design artifacts that let developers understand how the various components in the design work – defining the user stories, essentially.
The development team can then take these stories and run with them. Good research up front will have helped inform the prioritization of features and stories to work on, with each release providing more information as guidance.
The biggest challenge is staying ahead of the development team, while still giving them enough to work on early in the project. The goal is to stay a step ahead of the development team, but good design will include user testing and likely several iterations, so while most advise starting one or two sprints ahead of the development team, this may not be enough.
To keep everyone on the team fully engaged, the development team can begin working on their research ‘spikes’, which help them get a grip on any outstanding questions of how new, applicable technologies might work, or how they can connect with partner vendors, or anything else that might come up. If none of these problems exist, they can use early looks at designs and concepts to work on data modeling, or failing that, start prototyping what they see from the design team.
This would be UX in Agile in an ideal world, which all too often is not what we get.
Where it all falls apart
The problems with UX in Agile come when the team falls back on bad habits during the definition phase. Rather than talking with users, the team makes assumptions (or uses poor research) about what the users want and need and make decisions off of these. This is not because of Agile methodology, but in spite of it. While Agile does have the benefit of more feedback with users to catch problems early, this process can only do so much. This approach also lends itself to tried and true, or fast follow, solutions, which are safer and easier to get user approval.
The other way it struggles is when the UX is only operating at the user story level. The team (likely not involving a true human-centered researcher) has decomposed the goals all the way down into stories. There are two challenges with this approach. First, this calls for a UI designer, not a UX practitioner. Second, the designer – UX or UI - is at a disadvantage because they have to design bottom-up, putting together a bunch of parts into a coherent system, rather than working top-down defining what the parts need to be. These designs end up feeling like a bag of parts, rather than something that is intentionally put together, and the user suffers.
In either of these situations, it is clear that the need for UX has not sunk in. This is not the fault of Agile, since how UX is implemented on the product teams is an organizational matter. Either the organization recognizes the need, or it doesn’t. Being Agile won’t make one difference if user research and human-centered design aren’t involved.
Deep down, Agile is about project management, working with users and stakeholders, and being responsive to changing situations. This is in harmony with UX, not opposed to it. The question shouldn’t be 'How does UX fit in with Agile', it should be 'How can you do Agile without UX'?