The very next question after “Wait, UX be integrated into Agile?” is usually “Okay, how’s it done?” Yes, UX can absolutely be integrated to Agile and while there are others, two of the most popular methods are ‘Sprint Ahead’ and ‘Just in Time.’
UX was born for Agile
It should be no surprise that UX and Agile can integrate seamlessly, UX was born for Agile. Both are iterative processes which seek to eliminate errors by keeping in constant contact with the customer and end-users. The key difference is while Agile maintains the flexibility to pivot as necessary to meet evolving requirements; UX gets out in front development and confirms the most efficient design and interaction, fueling even faster development times.
Let me be upfront, I’m bias. I prefer ‘Sprint Ahead’ to ‘Just in Time.’ While ‘Just in Time’ tends to be more popular and is in the true spirit of Agile development, it always seems to be less efficient and anticipates more throw-away work. On the other hand, ‘Sprint Ahead’ is less collaborative and requires more precise choreography but it better respects differences in process and provides more focus for development.
The Sprint Ahead Method
Let’s first talk about the ‘Sprint Ahead’ method. Just as it sounds, UX works one Sprint ahead of Development and hands off completed designs at beginning of each development Sprint. The Development team is constantly fed new designs at the beginning of each Sprint to keep them running at peak efficiency. It’s very much like the 4×100 meter relay.
If you’ve participated in Track and Field or happened to have caught the last Summer Olympics, you may have seen the 4×100 meter relay. There are four runners who each sprint a 100-meter segment of a 400-meter race. As each runner completes his or her 100 meters they hand off a baton to the next runner, who then begins to run their 100 meters and so on until the race is complete. The key to winning is keeping the baton moving as fast as possible; as one runner nears the end of their segment, the next runner starts running beside them at full speed so there is no slow down during the baton hand-off.
Advantages and Disadvantages of Sprint Ahead
UX and Development work in a similar manner with UX running one sprint ahead of Development. The UX team conducts Sprint specific field studies with end-users, designs, conducts testing and hands off vetted designs to Development. At the same time, Development hands off their completed Sprint work to UX, who will conduct Usability Testing and put key findings into the Backlog for future development.
The effect of ‘Sprint Ahead’ is an even more efficient process. The UX team is constantly feeding the Development team clear, actionable designs and requirements to keep the coders coding. It forces Product Owners to do Backlog Ordering in advance and everyone to be clear about what Product Backlog Items are upcoming.
Therein lies the problem. The chief disadvantage of Sprint Ahead is there is a fair amount of choreography that needs to happen. It usually take a couple of sprints for everyone to get the hang of it. Sprint Ahead is also problematic for teams that struggle to keep the backlog up to date and organized.
There is also important choreography happening between the UX Researchers and UX Designers which I’ll talk about next time.
The Just in Time Method
‘Just in Time’ is also just like it sounds, design and development are done in tandem. Both UX work and development are done in the same Sprint allowing the designs to be created on the spot to fit what is being developed.
When using the ‘Just in Time’ method, it’s highly recommended to embed the UX team among the Development groups so they can remain in constant contact. Another important benefit of keeping the UX personnel and Development teams together is to develop rhythm. Projects in which the Development teams are constantly working with different UX team members never seem to reach an optimal stride and tend to be marred by ‘fits and starts.’
Advantages and Disadvantages of Just in Time
Because the UX team and Development team are working hand-in-hand, ‘Just in Time’ requires much less choreography as there isn’t as much of a need to plan so far ahead. However, the down side is that there must be a very high level of collaboration between UX and Development to make sure the two are heading towards the same point. It’s like two bridge construction teams building from opposite shores; constant communication is critical to make sure when they meet in the middle they aren’t yards apart.
‘Just in Time’ is also much easier to track as both UX and Development are working on the same sprint. The down side is that because there is so much back and forth between the two groups, there is less time for development of universals; the common, predefined elements of design.
In order to be successful, the broad design concepts and universal elements (commonly used design components such as navigation, buttons and other interaction standards) are defined in advance. Having some agreed upon design standards keeps designers from having to solve each design challenge in a vacuum. Otherwise, even bigger design trials emerge later on when one ‘on-the-fly’ concept works in 9 out of 10 times, but on the 10th time a newly discovered requirement means a lot of re-work.
The ‘Big Upfront Design’
I should mention there is another important UX into Agile technique, “Big Upfront Design.” I haven’t used this approach in practice and would be interested in hearing from anyone who has. It has always struck me as UX operating under Waterfall rules, while Development works under Agile. While that approach might be great for estimating and reducing risk, it seems like it would rob the project of the advantages of a more iterative approach.
So, when it comes to comparing ‘Sprint Ahead’ vs. ‘Just in Time,’ I tend to prefer ‘Sprint Ahead’ as the way to get the best User Experience results and maximize efficiency; while Agile purists will argue that ‘Just in Time’ is more representative of the spirit of Agile.
Which should you choose?
Ultimately as with most things in UX, there are no rules. Take some time to get to know your organization, the project and the individuals involved to determine which method is right for you.