I often get asked how researchers and designers are meant to synchronise with the development team.
Split-team agile (aka mini-waterfall)
“Is it okay to have research and design running one sprint ahead of the build team?”
Split-team agile: the research and design sub-team creates specifications and assets in one sprint, which gets passed onto the development team in the following sprint
Their suggestion is that we split the team in two: sub-team A (usually researchers and/or designers) and sub-team B (usually the devs and testers). Sub-team A will spend each sprint creating specifications and designs, which sub-team B will implement the following sprint. In effect, sub-team A is creating sub-team B’s sprint backlog for the following sprint. Let’s call this ‘split-team agile’ for the sake of this post.
However, having two tracks of work going on separately, where one team creates work in for a downstream team, is not generally recommended for a number of reasons.
Firstly, we are building on top of unreleased product: researchers/designers are creating new product backlog items based on how they think that previously designed work will be received by users.
Secondly, this reduces the iterative way of working because we are less likely to throw away work even if it doesn’t perform as we’d expected — we are more emotionally committed to our specifications because subsequent work has been based upon it.
Thirdly, this is not a collaborative team effort and is encouraging silos.
Single-track agile (aka Scrum)
At the other end of the spectrum, we get the whole team to work on research, design and build. They dig in together to try to achieve a desired outcome. Research, prototype, test, throw away, prototype, test … eventually build. Nobody is ahead of anyone else: it is truly iterative. You could call this ‘single track agile’.
Single-track agile (aka Scrum)
As long as discovery continues once the build phase begins, I like this approach. It creates an amazing sense of team: the whole team understands their users and their users’ needs, and the team focuses on achieving a desired outcome rather than just releasing features. It also encourages the sharing of skills across professions.
Problem is, single-track agile is expensive. Clients (particularly those focused on delivery of features rather than outcomes) often balk at the idea of having a highly specialised dev involved in research: “Can’t we get them building something?”
Dual-track agile
Here, we split research and build into two separate tracks. The difference between this and split-team agile is that we are splitting the two types of work (each with their own approach), but does not split the team in the same way. The team is still a single unit, working together to achieve the single desired outcome. Jeff Patton, who gives a fuller description of dual-track agile in his fantastic post entitled Dual Track Development is not Duel Track, explains that “you shouldn’t think of it as two processes – just two parts of one process.”
Everyone is involved in research. Patton explains that “The whole team is responsible for product outcomes, not just on-time delivery. … If the whole team is responsible for product success, not just getting things built, then the whole team understands and contributes to both kinds of work.” He describes it as “a disservice” to the team not to involve developers in discovery work.
Jeff Patton’s diagram of dual-track agile
Conclusion
My view is that you can’t have everything. Split-track agile (and dual-track agile to a lesser extent) ensures that the whole team is always kept busy (i.e. it is resource-efficient) so, although it may initially win the client over, it won’t return as good outcomes. As a result it is less likely to result in repeat business from your client.
Single-track agile, which is flow-efficient (prioritising achieving the desired outcome over keeping people busy), might not seem as price-friendly, but I propose that it is actually better for your client’s pocket in the long run: because you aren’t planning and designing upon untested product, there will be less waste.
Your challenge is to get clients to understand.
Maybe show them this post?
“It is not enough to be busy. So are the ants. The question is: What are we busy about?” ~ Henry David Thoreau
