• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

XP and inexperienced teams

 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In http://www.coderanch.com/t/130219/Agile/Stealth-XP Mark Herschberg wrote:
This might be a better (even more extreme example)...
You have a team with 1 senior engineer and 100 entry level engineers. The senior engineer is the only one with engouh experience to make major design decisions (the others tend to be wrong at least as much as they're right). Would XP work here? (Yes, I know its designed for small teams, but humor me to get to the point.) I say no because the one person who needs to make the big decisions can't have them communicated to the team fast enough through pair programming and discussions. (I don't trust B learned it when paired with A, so that C can learn it when paired with B. Those channels can get noisy.) I think some degree on "decisions from a central authority" is needed and must be formally communicated.
Now as I noted, the example above was taking an idea ad absurdum. But if you accept the above, then can imagine scaling it down to reality.

I think a team of *experienced* developers would need more formal communication, too, so I really don't get your point. I also don't think that Big Up Front Design needs to be the answer - if you want to discuss this issue, we should probably start another thread, though.
There exists a project of complexity C such that for some team of N senior engineers with combined ability X, and M junior engineers with combinaed ability Y (and perhaps all sorts of other parameters), XP is less efficent then some upfront design.

I don't understand the "versus" here, as XP *does include* "some upfront design".
I agree, though, that an inexperienced team needs to adapt XP in a different way than a more experienced team.
But I don't think that more "formal upfront design" is the best solution. What I would rather like to see is a longer exploration phase, probably with more emphasis on design discussions and architectural spikes, and more design discussions scattered across the whole project life cycle, probably supplemented by thematical workshops.
[ May 18, 2003: Message edited by: Ilja Preuss ]
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mark also wrote
I've seen teams where the senior engineers didn't fully appreciate the scope of the misundertsandings. He talks to Joe who misunderstands A, and explains it to him. He doesn't also epxlain it to Alice and Mike who also misunderstand it. He explains B to Mike, but not to Alice. he doesn't realize how widespread the confusion is (or takes him a while to figure it out).

That certainly can happen. I wonder, though how critical the concerns are in an XP environment.
So, what parts of the XP practices did they practice?
Which ones did they not use which might have helped to
- make misunderstandings less likely or found earlier out about
- make misunderstandings less critical?
Will upfront design fix this? Of course not, it's not a silver bullet either, but I think if done right, it's more likely to work in this case.

Why?
Why is an upfront design (I suppose you mean a bunch of formal UML designs and such things) more effective to communicate? Why is it less likely to be misunderstood? Why would misunderstandings be found out about earlier?
[ May 18, 2003: Message edited by: Ilja Preuss ]
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There just was an interesting posting at the XP mailing list regarding this topic: http://groups.yahoo.com/group/extremeprogramming/message/77775
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic