The Practice That Outlived Pivotal Labs

Tanzu Labs shut down in January 2025. Pivotal Tracker, the project-tracking tool that Extreme Programming teams everywhere used to run their iterations, was retired that April. If you trace the corporate lineage back far enough — Pivotal Labs, founded in 1989 by Rob Mee and Sherry Erskine, acquired by EMC, folded into Pivotal Software alongside Greenplum and Cloud Foundry in 2012, taken public in 2018, bought by VMware in 2019 for $2.7 billion, rebranded Tanzu Labs in 2021, and finally wound down after Broadcom’s acquisition of VMware in late 2023 — that’s a 36-year run ending in a shutdown notice.

I want to be precise about where I sit in that story, because it’s easy to overstate. I wasn’t a Pivotal Labs consultant. I joined Pivotal in 2015, on the Greenplum side — the MPP database EMC had acquired in 2010 and folded into Pivotal Software in 2012 — right as pairing was being introduced there for the first time, team by team. I stayed through every ownership change after that: VMware’s acquisition of Pivotal in 2019, the Tanzu rebrand, and Broadcom’s acquisition of VMware in 2023. My role was eliminated at Broadcom at the end of 2024, a few weeks before Tanzu Labs itself was shut down for good. Nine years, three parent companies, and one practice I watched go from a rocky, uneven rollout to something I couldn’t imagine working without: continuous pair programming, test-driven development, and an almost dogmatic insistence that the person next to you is your first line of code review, not the PR you open at the end of the week.

That’s the part that’s easy to miss if you only know Pivotal Labs as a company that no longer exists. The company is gone. The practice isn’t. It moved into every team it touched, including mine, and it kept moving after that.

What the practice actually was

Extreme Programming, as Kent Beck laid it out, is a small set of practices that reinforce each other: pairing, TDD, continuous integration, small releases, collective ownership. Pivotal Labs didn’t invent XP, but it ran the tightest, most literal version of it I’ve ever seen — pairing as the default working mode, full stop, two people, one keyboard, rotating regularly, for the whole day. When I joined Greenplum in 2015, that discipline hadn’t landed on our side yet. It was just being introduced, one component team at a time, and it was not an easy rollout — some teams took to it, others struggled and reverted. I ended up as one of the anchors helping teams onboard the practice, pairing across teams rather than just within my own, to get it to stick.

It wasn’t only a process change for me. Coming out of a colder, more stressful strain of enterprise software development, learning to pair was its own kind of recovery — it rebuilt the sort of close, trusting working relationships that style of work had worn down. Nine years of that, the struggle and the eventual payoff both, taught me something no amount of solo coding does: a second person watching your work in real time catches a different class of bug than a reviewer reading a diff two days later. It’s cheaper, too — you fix the misunderstanding at the moment it happens, not after it’s compiled, shipped, and become someone else’s incident.

Why this is on a database company’s blog

We build ccxp-skills — a set of Claude Code skills we use internally to run something we call “Claude Code Extreme Programming.” The name isn’t a marketing flourish; it’s a literal description. /new-task and /incept frame the work, the same job Inception and IPM do for an XP iteration. Then /drive runs the actual loop, maintainer reviewing as it happens: red, write a failing test; green, get Claude Code to make it pass; refactor; rinse and repeat. The automated test suite isn’t a nice-to-have in that loop — it’s the hard gate. It’s the only honest signal for whether an AI pair’s change is actually correct instead of merely plausible-looking, and take it away and the whole arrangement degrades fast.

I’m not going to walk through the internals here — the workflow, the specific gates, how we structure review — that’s a separate conversation for a separate audience. What I do want to say is where the instinct came from. When people ask why an AI-assisted engineering workflow leans this hard on tight feedback loops and a strict maintainer-in-the-loop discipline instead of “let the agent run and check in later,” the honest answer traces back to nine years of pairing at a company whose name doesn’t appear on any org chart anymore.

Pivotal Labs is gone. Tanzu Labs is gone. Pivotal Tracker is gone. The company that taught me this practice eventually eliminated my role — that’s just how three ownership changes in nine years tend to go. But the instinct that a second set of eyes belongs in the loop while the code is being written, not after, didn’t go with it. That one’s still running, just with a different pair.

ccxp-skills is public: github.com/Synx-Data-Labs/ccxp-skills. If any of this resonates, take a look.