How to successfully incorporate UX/UI into Agile?
The organisation I work for employs UX/UI contractors, who have worked on so-called 'Agile' teams in the past. Yet within these teams, it has been common practice to spend a significant amount of time upfront on mapping out user journeys and flows across the system from an experience and interface perspective. I am not a UX/UI practitioner myself, but this all sounds very 'Waterfall' to me. The designers are keen to spend time working 1-2 Sprints ahead, but say they also need to dedicate time to the upfront period to obtain this bird's-eye-view; it also helps them challenge many of assumptions in advance.
I would like to hear from SCRUM Masters and UX/UI experts about how to make these roles as Agile as possible? I appreciate that UX/UI needs to play a part in the definition of 'ready', but what about the bird's-eye-view part? Can this be achieved by only working incrementally, a few Sprints ahead?
The designers are keen to spend time working 1-2 Sprints ahead
Is this the view of the Development Team? Are the designers actually members of the Development Team, in so far as their involvement is needed to create an increment once a Sprint is underway?
but say they also need to dedicate time to the upfront period to obtain this bird's-eye-view; it also helps them challenge many of assumptions in advance.
How are they currently validating the assumptions which do end up being made, before a Sprint has started? What quality of empirical evidence are they gathering?
Hi Ian. Thanks for the reply. Yes, the UX/UI functions were included in a former Development Team, who itself promoted the upfront design work. It became common practice to capture a user journey map, which fulfilled a role not too dissimilar to an entity diagram, before the Sprint began. It was considered as 'empirical evidence' internally as it was signed off by the business and technical staff.
I can foresee the response from you already on this! What I'd really appreciate is finding some ways I can engage and inspire the UX/UI function in relation to Agile. The risk here is that we follow inherited ways of working because "it's always been done this way". However, the last thing anyway wants is to hear: "I know you think you are Agile now, but you aren't; please apply the theory and it will be so much better!"
So...any examples or reference to articles would be most welcome to help individuals discover for themselves. Perhaps some shared stories about transitioning from Waterfall to Agile, specifically in the UX/UI domain?
In my experience, one of the key unwritten duties of a Scrum Master is to be the first to tell people the last thing they want to hear. It’s his or her responsibility to put transparency over the Scrum process, always, and to highlight any shortcomings or risks in its implementation.
In your case it sounds as though UI/UX people were formerly Development Team members, but in practice are not now. The work they do may however be of value to the Product Owner in forming Product Backlog items in advance of each Sprint.
My advice would be to discuss the situation with the PO, explaining the meaning and value of empirical evidence proven via actual release, and the risks inherent in taking the present leaps of faith. Where there is delay or wastage in proving value, the PO carries the can.