Extreme Management

An idea we're kicking around at my new employ. Think of the traditional XP management division between coach and tracker (TrackerRole). They're kind of a pair, right? So let's make 'em a real pair and enlarge the roles a little. Tracker also focuses outwards, operating on the organization to obtain resources and agreements for the group, as per a typical project manager. Coach focuses inwards and also does what a typical ChiefArchitect does.

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.




-- PeterMerel

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.


-- BrentNewhall

Here are the core practices; how do they map?

Fine scale feedback

Continuous process rather than batch Shared understanding Programmer welfare

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

EditText of this page (last edited September 6, 2004)
FindPage by browsing or searching

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006