Pivotal is well known for having a particularly extreme point of view, bordering on forthright religious fervor, when it comes to pair programming and taking highly bureaucratic versions of Agile development to an extreme.
Pivotal can deliver things to customers in spite of all this (given that it’s surely not because of all this), which sort of makes any advice published out of there fundamentally irrelevant for people working pretty much anywhere else.
As far as I know, Pivotal's process is based on Extreme Programming (XP), a process which deliberately takes an extreme point of view. (It's in the name.) It's not bureaucratic, but it is demanding.
I have a lot of experience with XP. In my experience, XP succeeds because of its extremeness, not despite it. It's not for everybody, but for organizations and teams such as Pivotal who are willing to understand and embrace it, it works very very well.
So I challenge your "given that it's surely not because of all this" comment. Do you have any evidence? Or are you just saying, "I don't like this, so it can't possibly work?"
Taylorism worked -- it decreased costs for companies, but people suffered -- they couldn't find meaning in what they do, their every move was monitored and choreographed, and they were squeezed for the last bit of efficiency possible.
The kind of "pairing all the time" kind of XP that is being preached is similar for programmers. It also works for repetitive work - building yet another web application - at scale, not at scale, not much of a difference. But programmers often get into the job because it is an inherently creative field. There is nothing like this kind of XP to suck it all away and leave them disillusioned about the craft until they escape and find a product role or even a consulting company with more empathy and kindness.
I'm another person who has done a fair amount of XP. Definitely some people feel this way. Some people do not. Personally, I really enjoyed it. I enjoy working with people. I enjoy shared experiences. I found the atmosphere to be challenging yet friendly. Quite often solo programming can be lonely. Sometimes you wonder what people think of your code. Sometimes you hear all too well what people think of your code -- three days after you could have done something about it ;-). In the pure XP teams I was on, I had a lot less conflict overall -- mainly because you are kind of forced to deal with conflict up front.
However, we had a few guys on our team that really didn't like it. They left and I don't think less of them in any way. It's a different way to do things.
As for the "repetitive work" aspect: the most successful XP project I did was a collaborative sketching application using pen input with automatic shape recognition: somewhere around 2000 (when did MS put out those pen based computers??? -- We did it for their unveiling).
This conversation is probably moot in teams where programmers are actually empowered to make their own decisions. In that case XP is fine, if you enjoy it, which makes it sort of a tautology.
The problem though is the Agile Industrial Complex and "thought leaders" who have pushed this as a religion on the industry. I enjoy pairing, and the excitement of two minds working at the same problem in tandem is an experience to be relished. But give it to an Agile snake-oil salesman, most of whom gravitated away from programming a long time ago in favor of making money training others in how to program, and they'll wield it as a weapon by prescribing the only true way to work.
Well, I won't disagree. I've had the moniker "Agile Coach" before it was ever a thing (I though I'd invented the term :-) ). But I have never been a business consultant. My "coaching" was exactly what you would expect from a sports coach: I helped the players, not the management :-).
XP (in its traditional sense) doesn't scale past 8 developers anyway. Anybody selling you XP for a team of 500 is someone to be wary of ;-)
This right here. It changed my outlook on software completely.
There are pains and giving folks the opportunity for change/rotation is refreshing.
Software is a team sport, its a weak-link game where we must communicate and empathize in order to see clearly (often past our own egos) in order to pull one-another up.
I was fortunate that good pairing hygiene was a focal point. Without that it can be disastrous mentally and ruin the experience for everyone. It turned into a highly collaborative sport at that point.
I am a hugger naturally but when I run into those pairs I went through the trenches with, it is a brother/sister hug. Best time of my life.
I feel you. When you pair program with someone you get to know each other deeply as programmers and people too. Not all of us can go into millitary to live dangerously with fellow soldiers, or participate in team sports, but as a weak substitue we have pair programming and high-pressure projects. I have to clarify that I enjoy pairing. It is the greatest thing when it works. But often it doesn't - it is a social activity, and so many things have to come together for that to happen. If you have a company that selects for such fit, and a culture that teaches pair hygiene, then the chances are better. Yet, I would rather reserve the freedom to choose how I work rather than be institutionalized for 8 hours a day into a specific ritual.
How are you so sure? They are so brilliant they can make great stuff despite a terrible process they choose, but they aren't smart enough to not use the process?
Yes, this is quite common. The people who choose the process are not the same as the people who get stuff done despite it.
There’s also a survivorship / selection bias inherent to companies with extreme views like this. Either you both (a) agree to cheerlead & display positive affection for the religion and (b) display effectiveness in the role, or else you will quit or get fired or self-select to never work there in the first place.
So in a large part, it’s literally unknowable to what degree success is in spite of vs because of these extreme practices. There can’t be evidence about it because by definition there is the confounding factor that the employees whose productivity you measure are only from one specific sub-population (likes extreme view & delivers good software). You never get to measure what people with diverse opinions about tbe philosophy would do in the role, and you never get to measure what less successful developers would have done in the extreme philosophy.
The same effect happens with extreme coaching philosophy in sports, where again after you apply the filter that the players are selected to both be very good and accepting of the philosophy, there’s no way to measure the counterfactual possibilities, so it reduces to religion.
Pivotal can deliver things to customers in spite of all this (given that it’s surely not because of all this), which sort of makes any advice published out of there fundamentally irrelevant for people working pretty much anywhere else.