Dual track - How much discovery is enough discovery?
Exploring some of the trade-offs involved in running discovery in parallel to delivery
I recently joined a government project, leading a large team dedicated to delivering a live casework service with a bespoke front and back office. The aims of the project are quite clear - get as many cases off the existing system as possible by the end of the financial year in order to save substantial costs to the tax payer.
While the team have been doing a great job building quality work, and are close to rolling out the first case type on our roadmap, the project has not been without its challenges - especially when it comes to team and processes.
The challenges we faced
1—Clear aims but unclear scope—While we knew which case types we needed to support, when it came to the scope of those case types, you’d often get different answers depending on who you spoke with, creating confusion and inefficiency.
2 - Disjointed teams - the front and back office teams were working on separate journeys that often didn’t align, leading to inconsistencies in what was meant to be a coherent end-to-end service.
3 - Multidisciplinary involvement - our engineers were only seeing work for the first time during refinement, and they often found themselves pushing back with other more efficient ways to deliver on a user's need.
These factors led to a lack of clarity which meant that a lot of work went around the houses at the refinement stage, resulting in frustration among team members and significant waste through rework.
How we addressed them
To address these challenges, we created a story map which defined what we will tackle as part of each case type, and what we will not, validating it with stakeholders at an in-person event last month. Based on that story map, we have restructured the teams into five multidisciplinary development squads. Each squad now comprises one Business Analyst (BA), one Designer, two Developers, and one Tester. Alongside these squads, we established a runway squad tasked with conducting up-front discovery, clarifying scope, testing wireframes and prototypes with users, and validating work before handing off to the development squads.
Despite only being in sprint 2, our new approach is showing some early promise, and the smaller team structure seems to be solving some of the problems we’ve encountered. Team morale is higher and the squads are finding it within themselves to clarify and unblock work, speeding up velocity.
But they are not without their tensions and trade offs, and I want to explore those trade-offs today, as well as some initial first impressions, with the hope of coming back to this in a few months time armed with lessons learned.
Clarifying scope vs dictating solutions
In a dual-track discovery process, the Runway squad is responsible for exploring and validating ideas before passing them on to our squads. To put it in Marty Cagan’s terms, we’re trying to answer questions of feasibility, desirability and viability to find a solution our users want which also works for the business.
This approach doesn’t run into any issues when the same people conducting discovery go on to deliver the work. But what about when a specific team discovers the work before handing it off to a development squad? When presented with this new team shape, one team member remarked that it seems like a waterfall answer to our problem. And those concerns are certainly valid - while our aims are to help clarify requirements and cut unnecessary scope, we run the risk of being overly prescriptive, which could stifle creativity and ownership among the multidisciplinary squads.
So how do you strike the right balance and tone? How can we help shape and clarify the scope of the work in front of us, while at the same time allowing our squads to bring their expertise to bear on the work when it makes it to their sprint board?
Meeting delivery pressures vs getting it right first time
Similarly, there is a significant tension between the need for efficiency and the need to give ourselves enough time to get things right. Our goal is to provide our squads with well-scoped and validated epics without stalling their progress, but dual-track discovery deals with inherent ambiguity, and is necessarily iterative, so how do you balance that with the delivery pressure of feeding a large volume of work to multiple squads?
I’m reminded of the saying not to let perfection be the enemy of good. Based on sound advice from colleagues in our product community, we’ve all agreed an initial time box of 2-3 weeks for each epic, which is the amount of time we think we’ll have to keep abreast with the squads’ collective velocity, which seems to be working so far.
Definition of done
Another thing we established to try and strike the right balance between the concerns above was a clear agreement between squads on where Runway would take a piece of upcoming work before handing it off to the squads.
At a high level, the Runway squad refines epics, while the Development squads design, refine and deliver the user stories sitting under those epics. At its core, we in the runway squad are responsible for identifying the user types, identifying their jobs to be done, determining which are in and out of scope (and why) and building wireframes which demonstrate the end to end process.
We have defined “Done” for us as having completed and handed over confluence document for that epic which documents all of the above. Exactly how we will cater for each JTBD is left to our development squads. We focus on the “What” and the “Why” and give them relative autonomy on the “How”.
Documentation vs communication
But as agile principle number 6 states,’ the most efficient and effective method of conveying information to and within a development team is face-to-face conversation’. Relying too heavily on documentation means there’s inevitably going to be misunderstanding, or people missing key facts which can lead to delays and rework. We can’t let documentation replace communication. So to ensure alignment, we’re having regular sessions with the squads, reviewing work in flight, fielding questions, and handing off documented epics, as well as participating in squad ceremonies to help provide guidance and clarity.
So far, we seem to be covering more ground during those ceremonies, and the need for rework is slowly dwindling. But importantly, we’ll also attend retros, monitor delivery data, and listen to feedback from our pilot release in the coming months. We want to overcome any barriers or siloes which might come with this new way of working.
I will return to and follow up on this article with the benefit of hindsight - I’m sure we will have been wrong about half of it! So keep an eye out for a follow-up, reporting back on how things have gone.