People Vs Process

"Good people in an excellent process will DESTROY great people in a poor process" -- MichaelHammer?

"Yeah, but with Kent, Ron and talent of that level working on the project, they would probably be successful with ANY development approach." -- CarlParziale

"DoIt is successful because we have a fantastic development approach based on XP. *And* we have some of the best developers in the bank." -- BillBarnett

Nice sound bite from Hammer, but he's wrong. Process can never replace talent. Actually... upon further consideration, that sentence is not completely wrong. Forcing talented people into a stupid process can hamper their progress dramatically, perhaps to the point that a team of mere good people, not so encumbered, can achieve a better result. But talented, focused people who define their own process will always achieve the best result. Again: process can never replace talent.

What do you think?

All of these quotes are a bit dated, DoIt doesn't exist anymore and I'm no longer at FirstUnion?. And who knows what Mr Hammer is up to these days. But they highlight an interesting question.

Is XP a set of practices that can, in the right circumstances, give average developers godlike success? Or is it a development approach that naturally attracts enlightened, highly talented, ego-less developers who by their very nature give a project a much higher success possibility?

Or does it even matter? -- BillBarnett

Is XP a set of practices that can ... give average developers god-like success?

Absolutely not. But it can turn a LessAbleProgrammer into a PrettyGoodProgrammerWithGreatHabits. To get god-like success, you'll still need a GrandMasterProgrammer. Regarding your second question, I've found that XP also attracts LessAbleProgrammers. People like to do good work, and XP is a set of practices that, when followed and practiced, helps you do better work than you did before. That's the big incentive for many people.

I think the Michael Hammer quote at the top of the page reduces an incredibly complex concept to a mindless sound bite. The only thing that "talent" and "process" improve is the probability of success, they do not guarantee it. "Success" is a difficult term to define and get agreement on, as are "talent" and "process" (I believe "procedures" is what is really meant by this term). Forget the PeopleVsProcess argument and recognize that improvements in people, or process, or people and process will all lead to an improved chance of success.

I'm sorry, I don't know which "above quote" you mean? [Reference has been clarified. Sorry about the confusion] But I definitely agree with you about the difficulty in defining success. There are two distinct views on this: A. Success is delivering a working system on time, on budget, and to the satisfaction of the customers, or B. Success is creating a team and an environment that can reliably, repeatedly, and sustainably accomplish A. It seems to me that this is a broad benefit of XP practices that are often overlooked. -- bb

Yes, improvements to both process and people do both lead to improved output, but recognizing that one factor (people) plays a far greater role will help you concentrate on what matters most.

Too many managers think they can create a "software factory" with cheap programming labor, using high-ceremony CMM/SEI/ISO processes to achieve quality. That was fine when that nonsense was limited to handfuls of organizations - let Darwin deal with them. But when those organizations fail, their employees move on, carrying the process mantras with them. The ideas about the miracles of process have become dangerously pervasive. Even programmers are starting to believe these myths.

Sometimes, introducing a little bit of process can produce results that seem miraculous, but it would be wrong to extrapolate from those experiences to all software teams and all times. Process changes should happen naturally in a sort of punctuated equilibrium, similar to the refactoring cycles used to make good code. There are moments when code is poised to be powerfully reorganized, and the same holds true for group procedures. As with software design, process changes based on "smell" are going to be more valid than those purchased with a binder.

This also affects the situations in which it is appropriate to adopt XP, and when and where you can expect to get lots of benefit from it. If, as we seem to be arguing here, the people, and what I've broadly called their "talent", is the driving factor, then traditional teams should a. have a very difficult time adopting XP and b. show much reduced benefits from it.

By the way, when I mentioned "talent," I didn't only mean technical software writing ability, and certainly not wizardry in one given language. Those are not any more important than critical problem solving ability, good communication skills/teamplay, etc, etc. -- bb

By "talent" I mean an inate aptitude for something -- here, specifically, building software systems. I do not mean acute knowledge of a language or some other detail, although deep knowledge can occasionally indicate some level of talent. Talent for building software systems includes all these things and far more: the ability to relate well to business folk to efficiently extract domain knowledge, the ability to synthesize a great design quickly, the ability to resolve problems in a deployed system over the phone, the ability to lead not through title but through charisma. Talent is very rare, but exceedingly powerful. Knowledge amplifies the power of talent, but talent is not knowledge.

You know, there's a second reading to the title PeopleVsProcess, in which people are seen to indict "process" as some kind of criminal force, and relegate it to the dungeon in which WaterFall has been doing some hard time. That would be a sham.

I confess to being deeply suspicious of the term "process" in this context. People so frequently get blinded by love of process that they miss out on the total failure to deliver anything of value. Which is why I like the fact that XP is a low-ceremony development approach rather than a pack of tightly defined processes. -- bb

hummm... There are multiple BIG perceived places for process.

(architecture is the customer) You have a well defined infrastructure (or production line) and you want to ensure that the ongoing application level functionality (or product being produced) uses the infrastructure in an efficient manner (sometimes a framework can capture this for you).
(business customer is the customer) You want to express the business need in terms of functionality as quickly and correctly as possible, while maintaining a level of consistency and quality that can survive beyond the specific individuals.
(The Share holder is the customer) You want to ensure that if you created a piece of Business function that it could approach the level of reuse equivalent to the routers and hardware devices that you ride on. Process is used to try to close the communication skill gaps.

All three of these cases involves coordination outside of the development shop. Don't forget that infrastructure architects and shareholder are customers too. Also don't forget that customers have detail and abstract thinkers also. You might get a detail person, or you might get a dreamer, which one do you want working on user stories and why?

If you don't always have high caliber people (or you've scaled too big and you can't possible find enough super geniuses), you still have commitments to the three customers. The issue with a process is that some of them can't extend into the realm of "Business" reuse. Lightweight in the development shop makes a lot of sense (as long as customer one and two above are happy), but to achieve business process reuse requires communication and memory of existing business function (not a simple task if you assume a corporation has thousands of them; the sheer task of finding a business function to reuse could be the limiting factor). -- CarlParziale

I cannot agree with the people versus process (i.e. procedures) debate. While it may sound nice to say "one factor (people) plays a far greater role," most people would be concerned if I restated the statem as "one factor (people) causes a far greater amount of the problems." There a many problems and areas for improvement in any system. Some need to be addressed on an individual basis ("people factors") and some need to be addressed on an aggregate basis ("procedural issues"). Neither one is more important as a whole and neither one is really independent of the other. -- WayneMack

I have no problem with that inverted statement. It's true. People can cause great problems too, simply because people have a far greater impact than process. A troublesome person can be a bigger problem than a troublesome process. Excellent programmers can and will ignore or merely pretend to follow a process that they did not choose, losing considerable time and effort. It's much harder to contain the damage from having a crummy person on the team.