AI and the rise of Total Experience
April 2024
Dual-Track Agile – when everyone is a researcher
Dual-track agile is an approach to agile project delivery in which the team breaks its daily development work into two tracks: research and delivery. It is a unifying approach to product development. It is a method that embraces the differences between the work of a developer and the work of a designer. It can foster collaboration and collective ownership of all the work. And it can bring efficiency to the development process and rigour to the creative process.
We have recently been working on developing a new government digital service. If you are familiar with government project cycles, then you will know that there are five stages to product delivery; discovery, alpha, beta (split private beta, public beta), live and retire. For simplicity, we haven’t included retire in our diagram below.
We began the project using this approach. The ‘discovery’ and ‘alpha’ phases were supported by research work; exploring the client’s problems, understanding the users and their needs and establishing how the system is going to work. Our plan was to continue with research into ‘beta’ so that we could obtain live user feedback during the product deployment. You’re expected to use agile delivery throughout the lifecycle of a service. It was during the alpha phase that our problems started. We used a scrum approach, delivering in two-week cycles and began to notice that the research was being stifled in favour of delivering something within the sprint. It wasn’t working. We needed a plan B.
Agile became popular in the 2000s, and it felt like a revelation for the industry. Gone were the days of drawn-out projects where you would only see results right at the end of the project. With the agile methodology, success was measured by quality outputs during the delivery phase. An agile approach was great for creating software where the user could access revised and improved versions at a regular cadence. It also put developers in charge of their own workload, and it brought stakeholders closer to the action since they were involved in the day-to-day work.
Industry experts in the UX space saw a big flaw. An agile approach doesn’t work so well for research. With research, the length of time it takes is dependent on so many things. It depends on when the users are available. It depends on how much data you get. It depends on what outputs you need to create. All of these factors are unknown at the beginning and may not fit into the two-week sprint timeframe. So, a new approach was required to help make agile more UX-friendly, and that evolved into what we now know as dual-track agile.
The spirit behind dual-track agile is that the entire team engages in two distinct work tracks; research and delivery. The research track utilises the team’s expertise to produce, test, and validate ideas that help strive towards a solution. The delivery track takes that validated idea and converts it into a usable product version within that sprint.
From a research track perspective, it’s important to be versatile. Not every design cycle has to create something tangible; it may be used just to validate, or even invalidate an idea. Some loops can be short, others need to be larger. The dual-track approach makes space for the flexibility and versatility that the research track requires.
We learned how to focus on what’s viable, not what’s perfect, which helps shorten the iteration cycles. It is important to involve the whole team within the research track. For example, we had our technical architect support us in co-design sessions with users and stakeholders. Developers and testers would join us in user research sessions.
No method is perfect. We encountered some key challenges. There were four large ones:
With dual-track agile, all the team work on both tracks. This was a tricky mindset for a few reasons; reluctance to donate time, context switching is hard work and there was apprehension around someone critiquing an area that wasn’t their responsibility, such as design or development. We overcame these barriers by introducing some ground rules to encourage constructive ideas and feedback within a safe space. We introduced technical refinement sessions to give everyone time to think and iterate. And we added visual reviews and UX reviews as checkpoints in the development process for the designers to review and discuss the progress whilst ensuring that the planned output still met the desired need.
Dual-track agile is a fast-paced method. It kept the project and team focused by creating and monitoring a roadmap for delivery. And it empowered us to be disciplined with what was needed now and later.
When you involve more people, you generate more ideas, which can lead to scope creep. Consciously sticking to the roadmap helped, but we needed something more. So, we adopted a ‘good enough’ mindset. Every solution was challenged as to whether it was ‘good enough’ to solve the problem. And if it was, we asked, ‘does it fit the roadmap’? If we got two yes’s we knew we could implement it and move on.
Triad has a track record. Clients from ten years ago are still using us today. We work hard to hire brilliant people. We are award-winning. We want perfection. At first, ‘good enough’ felt like we were settling for second best. But we realised that ‘good enough’ isn’t settling for anything at all. In reality, ‘good enough’ is about delivering excellence rather than searching for perfection.
There were lots of benefits to the dual-track approach. The stand-out benefits were:
That’s because you’ve tested something that has been validated by the user needs and built within the constraints of technology.
Because the entire team is involved in the research track and delivery track, what you end up with, is the ability to create something that is truly deliverable. This is helped by the ‘good enough’ mentality in that you have solved lots of small problems with simple solutions that collectively end in an intuitive product that isn’t trying too hard. It doesn’t put demands on the user to ‘over-think’. Therefore, everyone has confidence in it.
Fostered collaboration increases dialogue between your specialists across the team. It creates a better overall decision-making process. It forces the delivery workstream to adopt a forward-thinking approach and be mindful of what problems may be on the horizon rather than waiting for them. It also helps validate the research and prevents developers delivering something that doesn’t solve your client’s problem.
Now, in public beta, we can safely say that the dual-track agile approach worked for us. It was the ideal method for a heavy UX project that kept the scope contained within a tight timeline. We have some great learnings. It’s important to adapt your methods as the project goes on. It is ok to veer from the original Agile principles,or from what everyone else does. You’re unlikely to always get it right the first time. And that’s ok. Agile your agile process. Iterate your iteration process. And go on that journey to let research inform delivery at every sprint.
Originally posted here
