

Extreme Programming Revived? - ABS
http://ronjeffries.com/articles/2015-03-21-xp-revived/

======
beat
The hard thing about Extreme Programming is that it depends on 12 practices,
the practices are independent, and some of the practices make management
and/or programmers uncomfortable.

The obvious one here is pair programming. Many programmers love pairing and
immediately get the value, but many others find it exceedingly uncomfortable -
so uncomfortable that they aren't willing to do it.

And on the management side, practices like "The customer is always available"
are hard to do in practice, as they challenge organizational boundaries.

But without pairing, without a customer rep directly integrated into the team,
without TDD, without collective ownership, without sustainable pace - it falls
apart very quickly. And what do we get instead? Scrum. And not even real
Scrum, but the BS pseudo-scrum that is pretty much tv and dessert first for
authority-centric management and lazy uncommunicative programmers alike.

So how do you pull that off? Well, you hire a bunch of "scrum masters", who
are basically just busybodies with no actual authority, to go around pestering
people all the time and calling meetings in order to get anything done at all.
There's no control, everyone is miserable, old-timers pine for the days of
Waterfall, and it just sucks.

------
beat
This is also making me think of the best development environment I've ever
seen, at a large government project. Two development teams, 15-20 developers
total, were in a single large room. The outer edge of the room was lined with
mini-cubicles so developers could have a space of their own - their own phone,
a place for the coat, and really some privacy and retreat.

The center of the room had two (later three) "islands" of computers. Each
island had five computers - two on each side, one on the end. These were on
wide desks with 2 24" monitors each, plenty of room for two or even three
chairs per computer. There was a low cubicle wall dividing each of the desks -
a little isolation, but if you stood up you could see/talk over it.

All _programming_ was done at the island computers. It wasn't so much pair
programming as community programming. If a programmer was in the island area,
either seated or standing, they were available to pair or help out. One
programmer might be working alone on something, but it was in public, and help
was immediately available at any time. And with all the space and clear
monitor views, it wasn't unusual to see four or five people clustered around
one computer, "pairing" and discussing a problem.

This is the best combination of pairing, community, and privacy I've ever
seen. It was tremendously productive and relaxing.

~~~
AnimalMuppet
This kind of setup lets you "use the online manuals", by which I mean, just
somewhat loudly ask a question of the room. Those who know the answer will
swing by to help out, and those who don't will ignore it. If it doesn't happen
too often, it doesn't even break peoples' concentration very much.

~~~
beat
It's also a great contrast to the "open" workspaces that plague the industry
today. In those, people don't have a space that feels like their own,
someplace quiet to go and think, etc. A fully open space is very oppressive.
By granting explicit private spaces, everyone had somewhere to retreat.

Meanwhile, all the "shared ownership" work of actual coding was done in
public, in an open space - more open than "open" spaces, even, because no one
had a personal space to invade for that work. Terrific design.

