Dual-track development
How can a design team fit into an Agile environment and still do the discovery work
A company that adopts Agile often drives the design team crazy, because they have to continuously deliver every two to four weeks.
The Agile manifesto pointed out: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
The purpose of this continuous delivery is to be able to learn quickly from the customers, adapt to changes, and deliver value to the customers incrementally. This prevented the team to develop software for years and fail.
If the design team has to deliver every 2 weeks, when can they spend time on research and discovery work?
Discovery and delivery
The modern product team would be familiar with these terms.
Discovery is all about learning and validation. It helps us answer two things: 1) Are we solving problems worth solving? 2) Are we building a solution worth building? For example, a Design sprint can enable a team to test the idea without putting high effort into building it into production software. In short, doing discovery help us to build the right product.
Delivery is all about building and shipping it to the users. The engineers will convert solutions to the production software. It enables the team to learn from the live data. As a result, we can slowly improve the solution.
OK, now that we get a gist of what discovery and delivery, let’s continue the conversation on how to fit the design team into this agile cycle.
Fitting in with a dual-track development
A company with an Agile environment often focuses a lot on delivery. As a result, they aren’t sure if they’re delivering the right product. The key here is to balance these two.
Jeff Patton and Marty Cagan popularized this concept of dual-track.
The idea is that one team can do both discovery and delivery simultaneously. Picture this: the design team would work on the discovery, the engineering team would work on the delivery. Of course, I simplify this distinction. In reality, it doesn’t stop engineers to be involved in the research and discovery work too.
But in order to get there, the designers, researchers, product managers should work together to get ahead of the engineering sprint cycle.
Getting ahead of engineers’ sprint cycle
Here are my common tactics to get ahead of the engineers’ sprint cycle: Every month, I’ll organize activities in my team to produce two things:
Critical hypotheses the team need to learn
Small wins and obvious improvements the team can consider
For the big and critical hypotheses, we will plan some research or any necessary activity to learn about that. For the latter, we will quickly ideate some solutions we want to test - this will keep the engineers busy and enable us to learn.
But don’t get me wrong, it doesn’t mean you keep the engineers busy for the sake of it. What you do should get your team closer to the objective. If your team has an objective to increase retention, the design team should scope their exploration around that problem space. The design lead should know that the onboarding becomes less relevant for the retention objective.
Once you reach this balance, you can learn so much in a short amount of time because your team constantly does an experiment to learn about the problem and solution, while also delivering small obvious improvements.
You can book a paid 1-1 mentoring session if you’re interested in talking further about this and contextualizing it with your condition and challenge.