I frequently get asked about how to best integrate UX / UI teams into Agile initiatives, so that they work in a more iterative, incremental manner. UX folks coming from a more sequential development environment often report that Agile compromises their creativity and their ability to provide a well thought out user experience. In my experience, feedback in this vein tends to be more of a reaction to change. The habit of doing big up front UX design at higher fidelity is not a required behavior for producing a winning UX.

The transition for many UX folks can be a struggle. It’s like any significant change, you can choose to try to do it all at once as a big bang change, which is almost certain to be reacted to out of the amygdala in our mammal brain or you can undertake the change in more of a kaizen approach, as small changes, measuring the effect as you go. The small changes are more likely to keep the person being asked to change rationally involved rather than fighting or fleeing the situation.

UX is frequently a limited resource on teams and shared between project and sprint teams. Because of this, it’s important to keep in mind flow and the demand for service from their product development team. I’ve used an approach like the RITE – Rapid Iteration Testing and Evaluation model, which originated at Microsoft. In the RITE model, UX Team works collaboratively with the rest of the team, but they divide their time up between the different demands for their service, designing for upcoming sprints, collaborating with other roles on the team during the current sprint and testing UX deliverables of the previous sprint with users. This cycle helps to balance flow and allocation of UX capacity across these 3 essential areas of their contribution to the team effort.

Image From article “Adapting Usability Investigations for Agile User-centered Design” – Desirée Sy

The amount of time spent in each of the areas depends on the team and domain context and can be tuned from observing execution from Sprint to Sprint. I suggest involving the greater team when having this tuning discussion. This can be an excellent topic to visit during the team’s retrospectives.

Recently I’ve been considering tracking UX efforts in multi-team contexts as a separate ‘sub-system’ on a Kanban board to help visualize better the flow and available capacity of this frequently constrained resource. So while there would be a backlog and story board / task board for the overall team working in a Scrum manner, the UX function would track their overall work function demand and provide visualization of it to the organization on more of a Kanban board. I think this could assist in balancing flow by enabling teams to better manage resource dependencies and of course to enable them to see when they could pitch in to help with some of the design process work where they have interest and or skill when UX becomes the bottleneck. In my experience, not all UX work can only be done by UX folks.

Bottom line, big change is nearly always a challenge with human beings, it’s just the way our brain has evolved and what has kept us alive as a species. Consider making changes in small increments, measuring the effect and adjusting as necessary. Also, consider utilizing something like the RITE model to balance the flow of UX service type demand for your context. And lastly, consider using a Kanban board to help better visualize UX work across teams and the available capacity and timing dependencies to optimize flow.

Join the Discussion

    • Dave Yates

      I know I’m late to the party on this article, but as a UX/UI designer, new to Agile, in a team that is new to having a full time UX/UI designer, I am desperately trying to find ways to integrate, adapt and make it all work.

      Unfortunately this is another of those articles claiming to give insights into “Integrating UX Into Agile” but its starting assumption is that the designer is the problem and is resistant to change.

      Believe me I am very enthusiastic about Agile and its potential for UX/UI, but at a level Agile actually promotes poor design. It is concerned with the production process. Design in Agile requires a series of artefacts rather than an holistic engagement between a person and an interface. Design assets are often required up-front and scrum meetings early in the sprint consist of developers saying ‘I’m blocked by UX’. So while the developers are doing nice Agile things, they seem to be demanding that the designer provides a waterfall feed into them to make the Agile process work in the first place.

      Agile is not some sacred cow that cannot be challenged, that is the lesson we have learned. I think more Agile experts should be prepared to consider the possibility that designers are not the problem. Agile is certainly part of the problem and Devs are being resistant to change if they expect UX to integrate without any compromise on their part. As it is, most case studies are written by devs and imply that designers should do all the compromising while still producing commercial standard work.

      it isn’t impossible, we are making progress. But in our experience (devs and designer alike) developers and the Agile process has to be as flexible, if not more flexible, than UX to make it work effectively.

    8 + 2 =