Extreme Management

These roles are peers; the group is responsible to the pair. So then we can take that pair and make them an element in a larger group, led by a larger pair. This structure continues up to the top, which is a CEO/CTO pair.

Advantages:

• most elements of XP can be used throughout the entire organization.
• Because a pair can manage twice as many members as an individual, the overall number of levels in the hierarchy is reduced by a very large factor. A company of 10,000 could work with just 4 levels of management. 3 if you don't count CEO/CTO.
• If one of the managing pair gets knocked out temporarily, by a vacation say, or permanently, through a reshuffle, we're not practicing ProjectOwnership, so it's easy to bring a replacement up from the group, down from the coach member of the upper pair, or coming in sidewise from elsewhere.
• The pairing mitigates ChineseWhispers.
• Pairing is a really fun and enjoyable way to solve problems; managers will get less stressed and be kinder to everyone.
• ProjectVelocity, however you manage that (yes, I still like IdealDays, so there) can be communicated consistently throughout the organization. This is to say you don't have to worry about turning a CommitmentSchedule into one of those ridiculous MS-Project graphs to please CaptainHornHair.
• Pairing with senior and junior members of the group is a good way to groom staff for promotion as the organization expands.
• When two groups need to cooperate, the leading pairs make a nice sized steering committee.
• This goes for QA. So QA can have exactly the same structure as development; a QA team is paired with a development team and uses all the XP practices to keep its development of AcceptanceTests on track, answering ExtremeProgrammingChallengeTwentyTwo.
• This is probably the right way to ensure that ExtremeProgrammingMayScaleUp.
• Others?

• I thought a "permanent pair" interfered with the spirit of PairProgramming, which was that pairs always reform.
  • I figure a ManagementPair? is permanent for an iteration - an iteration is their analogue of an EngineeringTask. I imagine but don't know whether a ManagementPair? would stay permanent for longer than that.

• The mappings and metaphors for all the various ExtremeProgrammingCorePractices aren't entirely clear yet. Stuff like CommitmentSchedule, DoTheSimplestThingThatCouldPossiblyWork, YouArentGonnaNeedIt, and DontGoDark are clear enough, but how about CodeUnitTestFirst?
• How often should StandUpMeetings be held when you get above a group of developers?

XP is based on actual practices, used by actual practitioners, honed until they work.

Well appreciated, though of course the combination of those practices was, until recently, unhoned. Still, so many of the practices are generic, you have to expect non-developers are going to try them out. I hear a lot of interest in this direction in the organizations I'm involved with. XM may not be a problem domain of interest to all, but it will be very interesting to some. Consider the above the start of ideas for a spike.

In TomDeMarco's talk at XpImmersionThree, he spoke of ManagementTeam's and the fact that there aren't many. LowellLindstrom suggested that such a thing might be just the way to scale XP up. I'll see about drawing a picture and posting it. -- RonJeffries

It is now posted at TomsTalkAtXpImmersionThree. -- LowellLindstrom

That would be very much appreciated. Especially confusing is the role of QualityAssurance, though the more I think of it, the more I think QualityAssurance's role isn't especially well defined in regular XP either. I've seen a situation where QualityAssurance lagged development badly, and all kinds of non-extreme measures were tried in order to make up the lag. But perhaps this question needs to be another ExtremeProgrammingChallenge: ExtremeProgrammingChallengeTwentyTwo. -- PM

XP is based on practices applied at more than one team. If a single team adapts by-rules that appear to work, credit could be due the by-rules or the participants, and we'll have no way to tell which. The same by-rule at a different site could fail, due simply to different personality dynamics. We have fewer management environments to experiment with, so the margin of error in these experiments will be higher.

Hmm. So what you're suggesting is we take these ideas one at a time and see how well they work as little spikes rather than one big one. Good idea.

Most new ideas seem to have an essence, or kernel.

Here's a bit of a case study:

I work at a children's club (sort of like Boy/Girl Scouts) which is traditionally headed by a single "commander." A few years ago two women took over as co-commanders, and it's been great. A traditionally difficult, time-consuming, distracting job has become a much smoother one.

This particular role involves coordinating the activities of the club; knowing all the procedures, ordering supplies, organizing special events, etc.

Advantages:

• If someone interrupts the pair while they're doing something important, one commander can answer the question while the other continues with her work.
• They can collaborate on future plans, bouncing ideas off of each other. You have fewer bizarre ideas being tossed out to the group.
• If one of them can't make it in, critical knowledge isn't lost; the other person knows pretty much everything the absent person does. Same applies if one was hit by a truck (God forbid).
• They can divide up certain work based on their different interests; if one likes making posters and the other doesn't, one isn't forced to do something she doesn't like doing.

Here are the core practices; how do they map?

Fine scale feedback

• TestDrivenDevelopment -- Does not apply to XM. TDD takes advantage of aspects of code that don't apply to people who don't work with code.
• PlanningGame -- Does this mean frequent meetings with the team to go over the effectiveness of the XM process? Things like 360-degree reviews?
• WholeTeam (was OnsiteCustomer) -- Same as regular XP
• PairProgramming -- Self-evident

• ContinuousIntegration -- Do not wait to implement new practices; implement them now.
• DesignImprovement (was RefactorMercilessly) -- Same as ContinuousIntegration in this context?
• SmallReleases -- Same as regular XP

• SimpleDesign -- Do XM pairs need design?
• SystemMetaphor
• CollectiveCodeOwnership -- could be CollectiveProjectOwnership?; no one person "owns" a team or project.
• CodingStandard or CodingConventions

• SustainablePace (original name: FortyHourWeek) -- Same as regular XP

It strikes me that a way to look at the idea is from the direction of similarity to the philosophy of XP, not the practices of XP. What dials do we turn up all the way?

PairManagement? implemented is described in recent InfoWorld: http://www.infoworld.com/article/04/07/16/HNrollins_1.html -- DenisYurkin

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006