Lessons learned from dual track discovery

Reflecting on the past 6 months

Back in June, I wrote about my experience working on a government project dedicated to delivering a live casework service with a bespoke front and back office . At the time, we were in a period of change, making changes to our team structure and ways of working, breaking ourselves down into several cross-functional squads and running dual track delivery. The last article explored some of the inherent tensions in that new way of working

6 months later, with the benefit of hindsight and armed with lessons learned, I’m now offering some reflections on what we did.

Break down silos, do not put them up

One unanticipated consequence of the squad model we set up was that it created artificial comms barriers between squads. In the back office, we went from one large team into two relatively small squads, each with their own completely separate comms channels and ceremonies. This created challenges where our back office squads were feeling the effects of a lack of communication with their colleagues, creating potential product risks due to diverging decision making. We quickly responded to this by re-joining their backlogs, and running shared stand ups and retros to close the comms gap we inadvertently created.

Time your changes

The challenge was initially exacerbated by the fact that we made the change too early. We created the squad model to increase focus on different areas of the service, but in actual fact, for the first few sprints, the squads were focused on exactly the same subject matter. We definitely made too many changes, but we also made them too quickly. The devs in our second back office squad labeled this as the “Perfect storm” at the time, and it took a lot of acknowledgement to rebuild trust in this new structure. With time we switched our focus to more discrete subject matter, and started to reap the benefits, but had we just held off for a month, we would’ve avoided a lot of pain.

Identify and meet your interdependencies

We certainly underestimated our internal dependencies when we kicked off this new model. In the first article, I outlined how the Runway squad was focused heavily on the “What?” and the “Why?”, leaving the question of “How?” to our development squads, largely because I perceived our dependencies as being internal and relatively easy to meet. 

This was a mistake, because there were certain key people with the ability to meet them, who faced multiple competing priorities which took their focus away them from meeting the needs of the team. If I could do this differently again, I’d have involved those key people more in our discovery processes and addressed more of the feasibility constraints upfront.

Keep refining ways of working

Retrospectives were absolutely key during this transition. We used these as opportunities for developers to vent their frustrations, show them we hear them, and come up with sets of actions to truly improve the situation over the next couple of weeks. One thing we did really well during this time was to carry out any and all actions, no matter how big or small, which the team asked of us. Over time these decisions compounded in a positive reinforcement loop which took us from delivering a little to delivering a lot.

Run excellent handovers with the teams 

In the first article, I talked about the definition of done from the perspective of the Runway squad. I would reframe this now to a definition of ready - in that we’re now ready to start designing and developing the feature. Whereas at the start we had relatively little handover time with the designers and BAs, now we’re spending more time kicking off features, refining them together, flagging and addressing uncertainty as we go along.

Furthermore, we are practicing BDD & Example Mapping within the squads to split, sequence and refine work in a smarter and more collaborative way. This new approach, something we brought in over the last couple of sprints, seems to already be bearing fruit in that we’re refining more, delivering value faster, and the work is better understood when developers and testers pick it up.

Guard scope 

Related to the point about handovers, we were noticing that occasionally things were making it into the backlog which we had explicitly marked as out of scope during our discovery processes. Work closely with your designers, business analysts, delivery managers and developers to make sure decisions around scope and direction of the service are made as explicit as possible. The what not and the why not should factor into your kick offs just as much as the whats and the whys.

Over-communicate, consider the end-to-end user experience

One problem our new model did not address was the silo between the front office, which members of the public access, and the back office which enables our caseworkers to progress cases and gather documentation. For historical reasons, front office was running ahead of back office, meaning there was a delivery gap to bridge. As a result, we only had one small team developing front office features, offering a chance for back office to catch up. 

Most of the complexity and focus sat in the back office, but as a product manager it is your responsibility to make sure both services ultimately come together into a joined up experience for the various user groups. A lot can change through the course of a software delivery project, and what was true when one thing was built may not still hold true. Continue to clarify and question things, bring people together from across the service, shine a light on disjoints and take action to ensure coherence. 

Final reflections

The squad model is a great way to delegate discrete and focused work to multiple different teams simultaneously, and allows you to deliver at scale, but it is not without its challenges. Practice some patience, open your teams’ communication channels over and above the squads, and you will see the approach bare fruit. Carve out plenty of time to share findings, and conduct forward planning and technical design before delegating out, and before long you’ll be finding it hard to keep up.