Pivotal Labs is an agile software consulting company. It has grown and cultivated an Extreme Programming software process to, well, the extreme.

Extreme Programming is a software development process first described by Kent Beck based on his experiences with several projects employing innovative, incremental techniques. It is most often identified by its practices, like Pair Programming and Test Driven Development. Many software organizations embrace elements of XP like Continuous Integration, but rarely do they implement it completely [citation needed]. Pivotal chose a radical route and implements all XP practices organization wide and builds up their brand on them. To utilize XP to the fullest, they do quite a lot of things I will detail in this article.

So let’s see how a full-blown XP implementation looks like: Entering the office it at first looks pretty normal like any tech company office in the bay area: Large height-adjustable desks, comfortable chairs, whiteboards, kitchens with free drinks and snacks, etc. Looking closer you’re in for a surprise: On most adjacent screens you see two times the same content! Every developer workplace is a dual-screen setup with two large, mirrored displays, two keyboards and two mice. This is the regular working mode of Pivots (Pivotal employees): Mirrored display, dual input devices and working on one task in a pair. This setup is essential to implement a core XP practice: Continuous Pair Programming: All developers work in pairs for 8 hours a day. There is little to no code on Pivotal projects that was produced by one developer alone. A pair is the smallest work unit they have. So why the mirrored screens? With a normal desk setup, pairing for a long time can quickly become uncomfortable. Pivotal does not just prescribe pairing as the regular work mode, they create an environment that makes it as easy as possible to pair all day.

Pivotal does many more things to make Pairing the regular and only work mode. The most unusual one is probably that the basic work unit of Pivotal is the pairs. That’s right, you can hire their developers only in pairs, for example it is not possible to hire a team of 3 Pivots (developers) [Footnote: You can actually hire odd numbers, but then you need to bring an odd number of your own developers to make the team even). Another obstacle to continuous pairing at most other companies is that people arrive at very different times from 6:00 am to lunch. To make sure people arrive at the same time there is a delicious breakfast at 9:00 am that nobody voluntarily misses. Another intended side effect is that people actually have breakfast and do not become grumpy before lunch. And the time door swings both ways: At 6:00 pm almost everyone leaves. Even the AC turns off, so it is difficult to work longer than a sustainable pace. Of course it is usually not sustainable to pair 8h straight, just as you take breaks when you program solo. Pivots seemed to take breaks more deliberately than solor programmers - instead of checking hackernews every 15 minutes, you have to agree with your pair that you take a break. So far these have been techniques to enable effective pair programming: the project staffing, the office setup and the daily routine.

But what effects does it have on a company when their developers pair program all day? Pair Programming has many effects, like continuous code review, but the most visible on is the amount of knowledge transfer going on.
Pivotal uses the high amount of knowledge transfer that happens “for free” during Pair Programming to distribute knowledge rapidly and get developers up to speed extremely quick.

On a new project, only at least half the staff is experts in the given technology. You can see where this is going - the experienced half starts pairing with the unexperienced half. Through the continuous Pair Programming the newbies get a lot of exposure and practice in the target technology. Pairs are not chosen randomly, but are deliberately planned during the daily together with planning the day.

This is done even for very different technologies, like a backend developers joining a project with an iOS component. According to several developers, it takes only 2-3 weeks of full-time pairing for a skilled developer to get up to speed in a new technology. This is pretty fast!

This knowledge sharing is also applied to the ones hiring Pivotal: If you do a project with Pivotal, their developers will pair with you and in the process you will get learn about technologies, processes, etc.

So much for the pairing but what about the rest of XP?

Pairs test-drive their way through development. They use TDD to agree on one context, as a design method and of course for regression testing. A lot of effort is spent to refactor the implementation and the tests, make the build fast, and keep them stable.
Collective Code ownership follows suit through the constant rotation in a team
sustainable pace as mentioned above
On-site customer is usually what people want to get knowledge transfer
Practices like Informative Workspace and Continuous Integration are by now no-brainers in the whole industry

What about planning, which is usually not quite covered in XP? [citation needed] Every team has a 1h Iteration Planning Meeting per week (timeboxed at 1h). Product Managers prepare stories so that this goes smoothly. Stories have to be user-visible and as small as possible. This supports the frequent pair rotation because you do not have open tasks and enables product managers to approve of stories individually. There is no notion of a sprint, so these estimations are only rough progress indicators for product managers, and not commitments. This way it is low effort for product managers to reprioritize stories during a week, because there is no “failing a sprint” notion. Also stories are well enough prepared that picking another one from the backlog is always possible. In addition to the stories there are “chores”, like cleanups and doing refactorings (not fixing bugs).

Altogether most impressive strong feeling that whomever I would ask in that company, they would all follow this process. There would be no corners of “well we are supposed to do X but only pretend to to make management happen” as you often have with process models (even agile ones like Scrum!). Everyone in that company buys into the (strict) process and follows it by the book, realizing substantial benefits.

If you are interested, they are probably hiring right now - but be prepared for Pair Programming day during the hiring process :)

Pivotal - unleashing XP to a whole company

Further reading