Why We Run Dual-Track Agile

As part of hiring, one of the questions I regularly field is “What process do you run? Waterfall? Agile? What is your team process like?” At Ncontracts, we run a flavor of Agile called Dual-Track which focuses on a long-lived-squad-based approach. Much has been said about squads and the ins-and-outs of running dual-track that are wonderful reads – you should check out a few if you haven’t already! Though there’s a multitude of reasons behind why we made the change, I wanted to highlight some of the most prominent.

Climbing the Mountain Every Project

When I started at Ncontracts, the team’s focus was primarily working against a large backlog of feature requests for each different product. Tiny things, big things. That didn’t matter because a project team could be formed to analyze what the request meant, clarify any ambiguity from the original request, design what it should look and act like, build it, test it, and release it. If a team got done early, they got to grab the next appropriately-sized effort that fit the remaining time in the sprint. Roadmaps changed quickly because the maximum wait before shaking things up is 6 weeks. This gets a team really good at shipping things. 
 
Working in waterfall but also in project teams necessitated those team allocations happened all at once. Naturally, there was a desire for everyone to have something to work on, even if that meant engineering got ahead of design, which resulted in significant rework. The process also dictated Big-Design-Up-Front, meaning end-to-end, high-resolution workflows usually took days/weeks before first tests with users. Engineering had an even longer wait before they could begin.

Mountain scene

As you can imagine, this is a large mountain to climb every project! There was never enough time to do discovery and idea validation – everyone felt like they needed to have answers already. Engineering felt the crunch to rush-rush-rush in the time that was left in the sprint for them. Locking in decisions early meant a systemic hesitancy to change directions when gaining additional feedback. 
 
Product owners needed way more time before the sprint to figure out how we chose what to work on, as they split attention between the current project and what was coming up next. The teams at Ncontracts were good at shipping things, but the things we shipped often needed a second pass, which required assembling another team to iterate and starting all over with building the context of what was done before. Instead of seeing this as an iteration or continuation of previous work, teams viewed this as what it really was: redoing a feature with a brand new team.

Change: “Just Enough” is Enough

Embracing the concept of “Just Enough” has been transformative. “Just Enough” is the enemy of checklists – it allows space & elasticity for how much or how little a squad needs to do to deliver value. 

Just Enough Discovery & Testing
When teams agree up-front on the problem they’re going to solve (but not the solution!), what success looks like, who you’re solving the problem for, and what assumptions you’re working from, the scope of what you actually need to figure out as a squad narrows quite a bit.  Focusing discovery on the biggest unknowns empowers team members to start working on the knowns. Discovery teams are also empowered to run experiments to validate whether a solution is viable. Even after we’ve shipped code to customers, gathering usage insights can inform quick iterations, biasing teams towards action.
 
Just Enough Design
Ncontracts surfaced and squashed the misconception previously held that something has to be high-res to generate valuable insights from users. For example, wireframes can effectively communicate the core of a particular solution to both users and developers – especially paired with a strong design system. The bigger revelation is that the deliverable doesn’t matter nearly as much as whether or not the deliverable communicates the concept.
 
Just Enough Delivery
Ncontracts has an abundance of engineering talent, which makes it easy to jump quickly to the more technical aspects of solving a problem… sometimes before the team fully understands the specific problem that needs to be solved. Often, experiments can be run with a smaller engineering impact, and this is something we’re getting better at all the time!

Change: Sticking Together

Making the change to squads that are together for longer durations (9-12 months) helped drive immense efficiencies in communication – beyond the shared understanding you gain through problem space continuity, there are fewer formal meetings overall, squad members have better control over how they solve a problem, and there’s more emphasis on solving the biggest unknowns early with the entire team. Discovery and Delivery sprints are staggered, meaning that everyone has an appropriate amount of things to do. Squads are testing and iterating, so we can resolve issues sooner. 

We’re shipping better software as a result.


5255efcc737ae4490ab706b24d245f16

Squad Realignment & Shifts in Priorities

Many advantages of the 6-week waterfall squads Ncontracts used to favor come from flexibility. Getting everyone familiar with all the different product spaces is crucial for any growing organization. Additionally, the ability to scale teams up or down depending on the lift lets the organization tackle giant projects without a major restructuring. Regularly shifting lets employees work with more of their colleagues, so they built rapport with lots of folks. This heavily contributed to a culture that translated well to remote when everyone needed to work from home during COVID-19 protocols. For a small, rapidly growing team, this was a very good idea. However, some good ideas don’t scale well.

Once we hit certain headcount numbers, bigger downsides to our waterfall approach started to surface. The biggest challenges were that nobody gained deep product knowledge in any one space. You learned just enough for your specific project and often knew you weren’t going to be reusing that knowledge again for a while, so it was less meaningful. Upon forming a project team, we were already committed to shipping something… even if our research showed that a new or different approach might not make as big of an impact as initially thought. Because teams were temporary, everyone was evaluated as individuals on performance in their core discipline (as opposed to being evaluated as a single project team).

These structures built a natural allegiance to our peers in each discipline, meaning developers didn’t always know or understand what was going on in design and vice-versa. Our collaboration suffered. As we found out, Value/Impact, Quality, and Collaboration are tightly coupled.

Change: Squads are Accountable

A side effect of Agile is that it requires asking better questions and reassessment of old methodologies. As incentives change, behavior naturally comes along for the ride. Shifting accountability to reside at the squad level is a big culture shift, but crucial for driving cohesion. 
 
We’ve found that squads that make their own OKRs are reliant on each other to achieve them. Familiarity with your squad means there is more incentive to have a quick video chat with someone to resolve a problem – it takes much less time than putting it in Jira (or TargetProcess)! Squads also build domain knowledge in their specific problem space and can move at higher velocity when problems are grouped. 


A process is only as good as the execution of all the people tasked with carrying it out. Ncontracts is committed to learning and refining our processes, building and growing our team and their skillsets, and most importantly providing value to our customers through doing great work.