Stories Case study: A Fortune 100 financial company
300 teams, XP, and the habit that stuck
Two years, about 1,000 people coached, and roughly 10% better lead time and change failure rate
A Fortune 100 financial company wanted every engineering team to work the way its best teams already did: extreme programming instead of Scrum. The program ran for more than two years and reached about half of the company's thousands of engineers. I coached on roughly half of it, so I met about 1,000 people from some 300 teams, two weeks in a classroom and six weeks embedding their everyday work.
After the first six months the teams in the program had about 10% better lead time and change failure rate. The habits that stuck were more efficient standups, retrospectives and pairing.
- Scope
- 600+ teams, thousands of engineers in the entire program, about 1,000 people and 300+ teams met by me
- Duration
- May 2024 to August 2026
- Measured after six months
- about 10% better lead time and change failure rate
The challenge
A few years earlier the company had run an XP transformation for some of its teams. Those teams became the best-performing teams in the company, so the company wanted the same for everyone. That meant thousands of engineers, spread over multiple continents, all of them delivering while they learned.
The teams I met were pretty average for the industry. Standups were long and unstructured, about everything except the important things. There was little real testing, no TDD, and no pairing. Backlogs couldn't be estimated or prioritized, and user stories were never properly written. They did their best every day, and there was a lot of room to improve.
One team had test methods about a thousand lines long, generated by the IDE and named after the method, a timestamp and the person who ran the generation. Nobody understood them, so they went unmaintained, and when one broke the team had no idea why. The tests existed because they had a code coverage gate, but they were useless noise.
What we did
- 1
Two weeks in the classroom, half a team at a time
Each team came in two waves, so half of every team was always free for incidents and requests. Engineers and product managers sat in the same room and covered the same ground: a healthy backlog, what a good user story looks like, acceptance criteria in Gherkin, the ceremonies, pairing, TDD, refactoring, legacy code. We started with slides and ended with stickies on a Mural board and conversations, because that's where people actually learn.
- 2
Six weeks embedded
After the classroom, coaches embedded with the teams for six weeks. We watched how they worked, gave feedback continuously, and fixed what went wrong before it became a habit. Everything was tailored to their backlog and their product. I was responsible for two of the regions, so in this phase I also met people I hadn't seen in the classroom.
- 3
Methodology over technology
The program was somebody else's. I delivered it, and I was also responsible for improving it. The biggest change I suggested (and got accepted) was to stop teaching technology and teach the method and the mindset. Anyone can pick up a mocking library. Doing TDD properly is what needs a coach. I recorded end-to-end TDD and refactoring demos for people to watch in their own time and added the test pyramid to the curriculum. That freed the classroom hours for practice.
What changed
The program measured its teams on DORA metrics. About six months in, it reported roughly 10% better lead time and change failure rate for the teams that had been through it.
Retrospectives are the first ceremony most teams drop, because they don't see the value. These teams started holding them every week, and kept holding them, because they saw that's where improvements are found. Most teams kept pairing as a normal thing to do, though not for the majority of their days. TDD stayed the hardest habit to adopt, because it takes discipline and practice, and six weeks isn't a lot of practice.
And the thousand-line tests? We refactored one of them together. The managing engineer cheered, loudly: "Finally I can understand what the test is doing."
What we took from it
Two weeks of eight-hour classroom days is too much. People can't retain that much, and pairing can't become a habit in six weeks. I had seen a different format work elsewhere: two or three hours a week with a coach, theory in small chunks, practice between sessions, pairing on every task from day one. That's how the Judgment Dojo runs.
The same applies to AI-written code. A code generator whose output you don't understand is no different from an AI whose output you don't understand: it might work and you don't know why, it might not and you don't know why either. Understanding needs foundational skills and engineering judgment. Once the team with the thousand-line tests had those skills, its quality went up and so did its speed.
The client isn't named, and neither is the company whose program it was. On a call I can say more about what we did and how.
More stories
Which habits would stick in your teams?
A short conversation about how your teams work today. You leave with a recommendation for where to start.