Word Salad on Extreme Programming

[bcholmes]

I'm trying to organize some thoughts on this. I don't expect this to make sense.

Project leaders are usually senior members of teams (in waterfall methodologies).

There is a project management skill that requires people to be fairly experienced in their positions before they're really good at it.

A lot of the stuff that is easy to point to and say, "This. This is what project leaders do" seems kinda... low skill level: tracking tasks; determining plan versus actual expenditures; gantt charting. Heck, there are tools that do most of this work. What seems to require experience is getting the project leader into a headspace where they think about things in project management ways.

The project manager is usually in conflict with the development team because they're thinking about things in project management ways, and the team is thinking about things in development terms ("let me bang out this righteous code...")

The headspace of project management is a shibboleth. It divides.

Extreme Programming is usually sold on its quality and "develop faster" benefits. I like its project management benefits. It simplifies the language of project management and turns it into something that a team takes ownership of, rather than something that the project manager takes ownership of.

Comments

[androgyna.livejournal.com]

Actually, it’s quite interesting when you have a meeting with the customer, involving a S/W Engineer, his boss, and his boss’s boss, the project manager. I recently had the opportunity to sit in on such a meeting and observe the thinking patterns at each level. It was very illuminating!

[futabachan.livejournal.com]

The project manager is usually in conflict with the development team because they're thinking about things in project management ways, and the team is thinking about things in development terms ("let me bang out this righteous code...")

As a team lead at Kodak (in a very, very Waterfall environment), I was in a position where I had to be in both headspaces simultaneously, and be the bridge between the two worlds. There are definitely two skill sets: the "hackerly" skill set of producing excellent code quickly, and the "process-oriented" skill set which includes what you describe, but also some things that eXP developers take for granted, such as testing. The real answer is that heavyweight methodologies really want all of the developers, not just the leads and management, to wind up in the process management headspace. The CMM-ish headspace is all about having things neatly contained in manageable boxes, which is hard to do and still retain the ability to produce creative solutions that require thinking outside the box.

The headspace of project management is a shibboleth. It divides.

eXP's ability to align project management and individual developer goals is wonderful (getting my team to spend time on good tests was like pulling teeth before I switched us to eXP-under-CMM). I've been in IT management, though, and I can definitely see a danger of eXP becoming a shibboleth of its own, dividing the project management level from the Director level within an IT organization. It could be argued that the C3 project is a good example of precisely that phenomenon.

On the gripping hand, Kodak spent gobs and gobs of money funding a SPI organization with a headcount larger than most eXP shops, whose aim was to get the company's software organizations to CMM level 3 and above using a home-grown custom process based on the way that Kodak manufactures equipment and film. We had barely gotten to level 2 before I left, and that by stretching the truth considerably, and it had been an ongoing effort for multiple years before I was hired. And even at supposed CMM level 2, our whole process was profoundly broken. I'm not sure how much it cost Intelliware, or how long it took, to get the whole organization up to speed on eXP at first, but it had to have been whole orders of magnitude cheaper per developer, which is a big win.