Nerdy
Shifting Left to a T-shaped Team
On the left, a developer. On the right, a test engineer. They are mob programming test automation for a story that had been marked done further upstream, and the test engineer is teaching the developer how the team’s automation works. Off-camera, the rest of the team watches and calls out suggestions, waiting for their turn to drive.
The Situation
The team called itself Free Folk. The Game of Thrones finale was weeks away, and the name also reflected how they saw their dojo challenge: theirs to direct. They came in with two goals among several: improve team dynamics and agility, and become more T-shaped.
Every dojo challenge starts with a skills matrix. We define “T-shaped” (a generalizing specialist who can cover most of what the team does) and ask the team what it would mean for them. Free Folk’s matrix showed a clear split: developers on one stack, test engineers on another, and developers curious about the end-to-end test toolchain.
The red columns are the developer stack (columns one and two) and the test stack (column three). That’s a pairing opportunity.
Then the team walked us through its Jira board. It was candid about how work really moved, and the board told the story: a string of wait states inside the team.
What We Did
We talked through value streams, wait states, and the cost of context switching. The team agreed to an experiment: collapse development, review, and test into a single “Dev & Test” state, and pair a developer with a test engineer on every story so each one moves as a vertical slice.
That’s shift left in its plainest form. QA stops being a queue at the end of the line that sends defects back upstream. Testing becomes part of building the story. And once nobody waits on a handoff, mob programming and pairing give the team somewhere to put its time, while skills cross over between roles.
Our sequence for this is the same everywhere. First remove the silos outside the team, then remove the ones inside it. Cross-training only works once the team is self-sufficient.
What Made It Work
Goals before practices. David Hussman kept a line in his email signature: “If you don’t know where you are going, it’s easy to iteratively not get there.” The dojo starts from target outcomes and only then picks practices. That’s the opposite of the lecture-and-lab training model.
The team chose. Coaches suggest what has worked for them before, practices they can teach and demonstrate. The team decides. Goals come out of facilitated sessions that put strengths and gaps in plain view, and only then does coaching start.
Time for courage. Mobbing feels strange at first. We all write this one piece of code? Everyone is watching me type? Rejecting it on instinct is easy, and trying it takes psychological safety. A six-week challenge, with delivery commitments negotiated in advance, gives a team enough time to find out whether a strange practice works for them before it decides.
Coaches who fail in public. Coaches propose experiments too, and some of theirs flop. The team watches them move on to the next one, and learns from that that a failed experiment is cheap.
The real outcome is agency. Free Folk didn’t adopt a workflow we handed them. They built one and made it their own.
Resources
- T-shaped Skills — the generalizing specialist and how teams grow them
- Shift Left — moving testing into the work instead of after it
- Mob Programming — the practice that made the skills transfer
- Skills Matrix — the inventory that surfaced the opportunity
- Scaling a DevOps Dojo at Target — the dojo model at scale