Someone on the XP mailing list wrote:
Ever done a real ExtremeProgramming
crash and burn? Everything on our project is like it usually is (chaos) but suddenly it strikes people, "<g> There is no ass to kick but my own!". I've been on crashing projects before, but none that hurt as much as this one. We aren't sure if we should "blame" it on XP yet, but I think most do. I'd say half of the people I work with will think hard before going into any form of agile process again. Most of them like to have another ass to kick. Myself I only wish they would kick ass instead.
I guess I could, but I'm pretty convinced that we made every mistake and suffered from all the drawbacks that can possibly exist with an XP-type project. I think you'd be better off just asking questions. First some background and then I'll try to answer your questions as good as I can.
The project team consisted of a mixture of experienced developers as well as developers pretty fresh out of university (with 6 months to 1 years experience). It was pretty much 50/50 and in total the project had 8 developers. The time frame for the project was set to be both challenging and realistic, but also took in consideration that this was a first timer with a "new" methodology, thus I would estimate that another 30-40% was added for "pedagogic" reasons. All in all it was estimated that 4 months would do the trick, though 1 month of vacation was included. Since we do product development, our CTO was appointed OnSiteCustomer
. The project itself was about developing a second generation of one of our products. My role in this has been system architect and team leader.
Iterations: Our plan was to do very short iterations (less than a week to begin with). We also wanted to practice ContinuousIntegration
, thus we would have R&D releases more or less the whole time (3-6 times a day). We also invested quite a lot of time into getting CruiseControl
running and integrated with our SCM tool (perforce). Some of us have done these things our own way before, so I think it would be fair to say that many of us knew what it means. So far we have managed to do 2 organized releases, both which have been controlled chaos. I should perhaps point out that we have not yet missed a deadline so in that respect the project hasn't yet failed.
How far into the project could I/we tell that things were going in the wrong direction? Well, dare I say...a couple of months before it even started?! From my point of view, XP isn't something that you just start "practicing" in the way you sometimes can do with RUP and the like. I have the feeling it has to be evangelized. I happen to know the guys I'm working with quite well, so I think we started the process of selling it almost 3-4 months before we sat down and decided to have a go at it.
During this time, I had long and hard discussions with all of the involved (including management) about what XP is and isn't. By now, I think I can quote almost anything from any XP book out there, not to mention all the web pages and emails about it. The goal was not to have everyone sold on the concept, but rather a few selected people (which have shown great interest in it) and have the others curious and in an acceptable state. But I really wanted everybody to understand
what it is, to be able to make an educated decision whatever they want it or not. Well, with cards on the table I know that not everyone did understand, thus the project should really never have started in the first place. We do communicate a lot with each other (always has been that way) but the one noticeable difference now from before is the lack of respect that somehow developed during this period. I think that was what made it fail in the end (*).
We never managed to satisfy the egos either. Two of the newbies even told me that they think XP gives them too little visibility. I fail to see the relevance of that, but I still suspect it to be part of why it failed. Perhaps some of them even wanted it to.
Ron asked, "How did the process seem to let you down?". Well, look at it like this: Most of us are used to NOT accept that it is the users that are doing things wrong, but it is the programmer that doesn't do what the user wants. If you want to have an easy way out, just apply that to the process and you know it's not the people that is the problem. Or how do you suggest I explain to this group that we all failed at the same time, all in our own way?
But I don't think the reason for this failure has really anything to do with XP. Just that from now on I know 18 people that will think it has, so it will be much easier for them to live with that explanation.
In the end, how it was done, was a real classic. A couple of heroic programmers, working day and night for a month and a half, to deliver something that they felt they could be proud of and that would satisfy the customer. Jell on us, and we love it.
(*) I should perhaps add that I think merciless refactoring was what started that trend (at least that's what I'm told). People say that there is a factor 100 on experienced programmers, and this tend to show during refactoring. Less good programmers sometimes (if not always) have a hard time not taking it personally.
I think a week's training and a Coach are two key factors for success with XP.
It has been said that all healthy families are alike, but unhealthy families are each unhealthy in their own way...
You mention Ego, LackOfRespect?
, and BlamingTheProcess?
... key problems of an organization that Learning Organizations have to fix in order to be able to learn. (see TheFifthDiscipline
and its sequel.) This is why I say that XP requires a LearningOrganization
to be successful.
Alistair Cockburn's not-yet-published book
> recommends that the team do ProcessReviews?
-like reviews) every iteration (perhaps even in the middle of an iteration), in order to constantly adjust their (actual) methodology to rectify problems that have been seen.
Perhaps this is the SecretFourteenthPracticeOfXp?
... sometimes the problem is that people are not following the methodology, other times the problem is lack of communication, so ProcessReviews?
can help in those situations.
XP and ProcessReviews?
probably will not help a whole lot if the organization doesn't know how to Dialog (communicate without too much attachment to your own viewpoint, being open to other viewpoints), do SystemsThinking
(understand how processes can reinforce or dampen other processes, recursively), work with MentalModel
s (which can uncover hidden assumptions that color your thinking) and so on... [Dialog, SystemsThinking
, and MentalModel
s are concepts from TheFifthDiscipline
The story sounds familiar. I'm interested in learning from this experience and I'm also looking for what can be done on the next project. What we must do to avoid XpCrashAndBurn
Questions about the project:
- Did you BeginWithTheEndInMind?
- How did you recognize that you began to go in the wrong direction?
- How many technologies we used and was it distributed system?
- What were the goals of those with big egos? (e.g. to be: experts; team players; successful in the eyes of the client; better than another team member ...?)
Becoming experts in XP practices is not enough. XP requires learning organizations to be successful
is the claim KeithRay
makes and that is convincing to me.
Questions about future projects:
To answer some of the questions above:
Yes we did BeginWithTheEndInMind
. We had a very strong vision and an existing version of the system at hand. The system is indeed distributed and uses CORBA, Servlets, Java, C++ and VB (MFC), databases, and XML in the core. We have experts in every area so we know the technology.
Anyway, we are now running a pretty healthy & happy XP project. We started all over again, from scratch. The key to this was a very ExtremeHour
(3 hours actually) where we put together almost all the team (except one because he wasn't there) to do something fun. During these 3 hours we built a basic WikiWiki
system from start to finish, which we are now happily using to further increase communication in our team (lack of communication was pointed out as a problem). The ExtremeHour
enabled everybody to see and experience a full-blown XP project from start to finish, testing all the practices together. Also, because of the good result, most people were impressed with themselves and the team. The egos mentioned earlier were quite surprised to notice that their talents actually shone through. I think this pretty much did it for us.
Can anyone summarize in organized fashion was crashed and burned? [EditHint: can anyone reword that question so that it makes sense?
] I was unable to extract how XP was a problem.