Image may be NSFW.
Clik here to view.
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 may be NSFW.
Clik here to view.
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.
