Multi Team Extreme Programming
Multi Team Extreme ProgrammingThis page explores XP working in large projects, with multiple programming teams. (See XpCritique for some of the issues considered here.)
I'm looking for the page I recently saw where KentBeck brought this issue up. Googling for it brought me to CanOnceAndOnlyOnceLoop, from which I staked this page. I'm going to search for that page now, so don't freak out and delete/refactor/spindle/mutilate this page until I get back.
Oh - and I also want to tie in AlistairCockburn's discussion of residues.
Don't touch that dial! -- TomRossen
I would look at XpMayNotScale, ExtremeProgrammingMayScaleUp. -- francis
Damn, you're good! I just found the residues page (SoftwareDevelopmentAsaCooperativeGame), from which I grab
The only real purpose of the intermediate work products is to help the team make their next move in the game.
Now I'll check your two links. -- tr
Okay - from XpMayNotScale, I got to HundredPersonProject and HundredPersonProjectBackup (which has a great line by RonJeffries), the thrust of which is that a small XP team can handle a big project just as well. To refine my interest here, let's say that the multi-teamness is an organizational given.
Now I'll check out ExtremeProgrammingMayScaleUp. But in the meantime, I'll say that my point about residues is that they may be important for the interteam communications; e.g., package documentation, or as we say in the XpInferiorLanguage? Java - Javadoc. -- tr
Okay - on that page, Dave Cleal says "Collective code ownership won't always scale...." I agree, but that's not a problem if we think in terms of interfaces. Try this scenario: one team uses a package from another team. The former team would like a change. This becomes a UserStory.
And this is exactly the problem with multiple teams -- it takes something that would otherwise take an hour or two, and makes it take at least a week or two (write UserStory, get it scheduled, wait for it to be implemented...). Meanwhile, the original pair has to make some progress, and they code a "workaround", which turns into a half-implemented violation of OnceAndOnlyOnce. Or, worse, they decide to work on something else until they run into another road block, and another...
"Just a simple matter of interfaces?" Beware oversimplification. Now that you have a published interface, how do you deal with change? Is the team allowed to refactor the interface freely? What about versioning? Do they just release a new version every iteration and all clients just deal with changes, or is there a more formal process? What kinds of delays and irritations does this introduce? What about overall architecture? Someone has to define the packages and high-level interfaces. As time goes on, that will probably need to be refactored too. -- JimLittle
PS: This is a topic I'm very interested in, so don't think I'm trying to shoot you down! -- JimLittle
Is the team allowed to refactor the interface freely?
"Not sure what you mean by "the team". There are at least two teams involved: all the clients of the interface, both the users and the implementors. What I was suggesting was that there emerges a "temporary XP interface team", composed of GoalDonors from the client teams. Think of them as delegates to a very specific standards organization that have been given power by their constituencies to rewrite the constitution - i.e., the interface (and its UnitTests). This can be a very fluid microprocess - it could all happen in less than one day.
If all the client teams are hitting on all X PCylinders, they will be able to send any member to speak as their OneVoice? and to work out an agreement. This is intrinsically a solvable problem, because the principles of refactoring (optionally followed by enhancement and another refactoring) can handle any software situation. I hope to be able to construct something more like a formal proof of this claim, but for now I'll just troll for counter-examples. And claim that if any "non-XP-solvable software situation" could be shown possible in a multi-team environment, the same situation could arrive within a single team's code.
(R [E R...] where R is refactoring and E is enhancement - I think that's a Backus-Naurish way to put it....) -- tr
Can one team have multiple users? If you're working on frameworks/components/utilities, it's inevitable. Another scenario: virtual user groups - all clients of a package/framework/component come together as a temporary team to generate a UserStory and speak with OneVoice? to the team that owns the code in question.
More to come - I'm in frantic ThreadMode here, hoping somebody like Francis will come back when the dust settles and refactor.
The great thing about Javadoc as a tool is that I don't have to memorize a lot of method signatures (autocompletion helps here too) and semantics, as long as I have a general idea what classes I want to use. Powerful and reliable tools are essential for XP IMHO, and if you know that the tool code is owned by an XP team, there's a basis for change - and the kind of flexibility that prolongs code life. -- tr
Bioanalogy: osteoblasts and cytoclasts make orthodontics possible (http://www.bracesinfo.com/glossary.html) by respectively building up and tearing down bone. Similarly, XP teams could move the walls between them by something like the scenarios described above. Interfaces, like bone, are strong structural elements, but need not be unrefactorable. -- tr
My inclination would be to come up with ways to increase the team size XP can handle, rather than have multiple teams. I would only have separate teams if the projects in question were very loosely coupled. MartinFowler wrote about large-team XP a while back: http://martinfowler.com/articles/planningXpIteration.html. -- JimLittle
Jim, thanks for the link! Some great ideas there - that are working now:
I sense a touch of idealism in your words: "If the teams are hitting on all XP Cylinders" and "given enough master-level XP players," for example. I'm also seeing something else that I can't quite describe... the programmers' mindset, perhaps. An impression that the problem is deterministic, and that if the rules are carefully defined, then everything will play out according to the rules. But when people are involved, it's never quite that straightforwhard.
But your approach is reasonable, and in line with what other people have suggested. Please try it out and let us know what happens! And don't pay too much attention to me. :) -- JimLittle
It's true: while I'm not exactly claiming they're deterministic, I am saying that the kinds of software problems that need to be solved here are susceptible to refactoring just as in a single-team environment. But for humans to solve those problems in a real project environment, they need strong discipline and a good attitude - again, just as a single XP team does.
I actually do have an opportunity in my current contract (see OptimisticProgrammingSkunkworks) to attempt to pursue these issues. We've discovered another team in the client company that is not only doing XP but has developed a servlet hierarchy that we may be able to use in whole or in part, and even potentially make a standard in the company. Details of the attempt will probably show up on that OPS diary excerpt page.
I'm definitely paying attention to you, Jim - you're helping me refactor my thinking on this subject! -- tr
For one idea on implementing MultiTeamExtremeProgramming, see ScrumProcess and MikeBeedle's XBreed.
Try this without a master architect who owns the external design and the component interface definitions and you'll end up with a product designed and implemented by a committee. The result ought to be awesome. -- MarcThibault
Well, what sense of "awesome" do you have in mind here? We have four teams, only two of which are even on the same continent, all working on the same codebase, all using an approach derived from XP (and Scrum and...). Every time that some individual has managed to get themselves into an architect position and started owning parts of the system, the result has been expensive, time consuming failure. Every time that pairs of developers have just gotten on with building what their local customers needed we've found that a customer elsewhere in the world has soon wanted somehting similar but not quite the same, and out of acommodating both and refactoring without terribly much mercy the system has ended up with a very valuable, useful external interface and just exactly right components within it, too. See, they aren't a committe at all, they are a self-organizing collective of collaborating creators. Which is pretty awesome. I'm awed by it every day. -- KeithBraithwaite
That is awesome! What would be truly awesome would be doing it again with a different set of people and in an organization that the Age of Aquarius has missed. In the last two XP developments I've witnessed, the outcome was not so satisfying.
In the first case the developers spent a lot of time with the users and, in true Dilbert fashion, decided the users didn't know what they wanted, built what they knew the users really needed, and deployed a product that was a joy to use but didn't do anything anyone wanted to do.
In the second case, the developers spent a lot of time with the users and did a great job of building exactly what the users wanted, which was an easy way to do the part of their job they found most annoying. When the client saw the product, she was less than pleased. The product was neither what she expected nor what she had asked for. The developers had delivered a low-value service and missed the highest priority, highest value functionality. The ironic part is that what the client wanted would have been easier to produce.
An architect is not a developer that manages to get into an architect position and own some stuff. It's someone with a different set of skills who's talking to the client (not the users) weeks before the development team is put together. The architect makes sure that the client knows what he's buying and that the developers know what to build. In both of the above cases, an architect would have put the project on the right track in the first place and kept it on track, leaving the developers (still XPing) to work with the users on the best way to deliver the functionality that was actually needed. -- mt
Regarding the second case: isn't frequent SmallReleases one of the ExtremeProgrammingCorePractices? If the client was surprised by what was delivered, it sounds like both she and the XP team failed; she by ignoring the incremental releases (which would have indicated to her there was a problem), and the team by failing to ensure the client was involved. But don't listen to me, I haven't used XP yet. Could someone with experience enlighten us, please?
OK, if the team had been using IncrementalDelivery of an EvolutionaryDesign, and the customer had taken notice of this, then no one would have been surprised by anything and divergence between expectation and delivery would have been noticed earlier. But that doesn't seem to have been the major issue here.
Notice that in the description of the case the developers were talking to the users, but it was the client who was displeased: so the developers had not realized (or didn't take into account) that the GoalDonor and GoldOwner were separate and apparently not aligned amongst themsleves. It's not clear to me that having an architect (which I understand to be a primarily technical role) in place would have guarenteed that mistake not being made. The folks that we have doing things like making sure that the client knows what he's buying are called Service Delivery Managers, and they are not architects. They aren't technical at all, rather they are the facilitators of the conversations between developers, customers and users that keep all parties aligned.
As far as doing it again with a different set of people and in an organization that the "Age of Aquarius has missed", well I've made my living now for several years doing exactly that, repeatedly and successfully. My current employer hired me to be the guy to go to Singapore and create an XP-based team there.
Let me assure you that the Age of Aquarius never got as far as Singapore: folks there are about as hard-headed a group of pragmatic cut-throats as you'll meet outside of China itself. Meanwhile, the team in the UK is (myself included, now that I'm back here) exactly as ego-ridden, argumentative, and what-have-you as any other I've worked with. Not a flower child in sight. Similarly for the group in the US.
As to the first case given, in my experince there is no class of person more frequently guilty of deciding that "users didn't know what they wanted", and then building "what they knew the users really needed" than folks dubbed "architect" by their organizations. YMMV
Now, I'm not here to try and convince you to stop using (or maybe being, right?) an architect. If you've got an architect-enabled process that works, more power to you. I do, however, want to make sure that noone who comes across this page gets the erroneous idea that multi-team XP (for some value of XP) absolutely requires a single technical lead to make it work: it doesn't. -- KeithBraithwaite
Given Keith's use of "absolutely", I agree. But someone has to make sure that the distinctions are made and that the stakeholders (Goal, Gold, etc..) are consulted and that the right product gets built. I'm going to guess that, on his projects, that's Keith - undercover architect.
Project Architect isn't a primarily technical role - it's a primarily business role with significant technical demands. Creative director in an advertising firm is a similar job. (Hmmm. Maybe it would raise less fur if we adopted Design Director as a title.) -- MarcThibault
I work hard to make sure that your guess is wrong. My role (it even says so on the Org Chart) is "coach", which does not empower me to tell anyone what to do. As it happens, I am also one of the (if not just the) most experienced developer in the company, so my input to design discussions usually carries a lot of weight, but then I'm only ever in one pair at a time, so the range of my direct influence is rightly limited - to be exactly the same as that of any other developer in the team.
Meanwhile, management looks to me to build, develop and maintain the (intellectual and software) tools, processes and culture of the developent team such that no single point of failure for team decisions (aka "architect", or similar euphemism) exists, and so the team can be relied upon to do the right thing. -- KB
EditText of this page
(last edited November 30, 2011)
or FindPage with title or text search