Another conversation on the XP Group.
Why do some people manage to have successful projects without using Agile methodologies, while others who are using XP still fail?
XP is a toolbox. Think about a mini project in which you need to remove a shelf from a book case in order to put taller books in the space.
A bad workman will always blame his tools. If the book case is still without a shelf for tall books after a day, he’ll tell you it was because he couldn’t find an appropriate screwdriver.
A good workman will find the best tool and improvise. A good worker might use a nail file if he can’t find a screwdriver.
I wouldn’t recommend using Waterfall any more than I’d recommend using a nail file to get the screws off a bookcase. You can do it, but it’s ugly, it takes ages and you’ll bleed before it’s done.
Liz Keogh, lunivore 
I still remain entirely convinced that projects succeed or fail based on the quality of the people on them (at every level), and that most methodologies are equally effective in terms of very good people (the project will succeed anyway) and very bad people (the project will fail anyway).
So, these peoples projects are failing, maybe they should have a close look at their team (and their client!) before they blame the methodology.
Not that I’m saying that Agile methods aren’t better than the waterfall method, merely that I’ve seen a lot of waterfall projects succeed without ugliness, untimeliness or bleeding…
For that matter, projects can fail due to reasons completely unrelated to the team, the methodology and the client!
It’s always about the people, not the process. The most adaptable tool in the XP toolbox is communication and customer collaboration.
My experiences of Waterfall have always involved BUFD (Big Up-Front Design), concrete legal contracts surrounding delivery and payment, late-night heros and neatly packaged deliveries of blame. It’s made people money, so in that respect it was a success, but it was always ugly, and people bled.
There again, I can get the screws off a computer case just fine with a nail file; appropriate tools for appropriate jobs.
In a way I’m glad I haven’t seen any of your successes. I might have stayed where I was. I’m curious as to whether Agile might have delivered faster, but my betters tell me there’s no way to measure these things.
Heh. We still consider a cancelled project to be a success, as long as it’s for the right reasons (and we’ve been responsible for several never even getting off the ground!)
Maybe it would have done, who can say? If everyone’s happy, does it matter? 🙂
Communication and customer collaboration are not unique to XP (nor are unit tests nor is releasing often, etc) and I think it’s great that XP brings these things to the attention of more and more people.
I know that deep down you’re all pragmattic about things and want to actually deliver the best service to your clients as you can, but often this isn’t what comes across. It comes across as a dogmatic ‘this is the one true way to write software, this *is* the silver bullet’, and it just turns me off [1].
To go back to your points about the waterfall, maybe the waterfalls I’ve worked with have been a bit more pragmattic than yours, a BUFD only ever makes sense in a blame culture, and, well, well done for getting out of that! But what works with one team is never going to work the same with another team, it’s all down to people, and culture, and all that stuff. Which takes me neatly back to my first comment [4]. 🙂
Do you think anything could have sorted out the stuff that went on at your previous employer? Could you have ever got management buy in for XP? How would this have sat with their culture? Would it really have ever worked?
[1] As the only XP persons blog I read [2] you probably get more of my irritation than anyone else, sorry!
[2] I’ve stopped reading most IT related blogs (apart from Hani) as pretty much without exception they make me want to kill either myself or other people [3].
[3] I need some kind of prescription or a career change.
[4] But it does make you think ‘what if there was a methodology’, and maybe I’m just too much of a cynic…
If a project looks doomed and I escape I always count that as a success! 🙂
The part of me which enjoys watching other people fail is something I really need to work on…
I think XP would have sorted out a lot of the problems in my old place, yes. There was one project which was into Feature Driven Design, with focus on getting working functionality in place, and that went a little way towards it.
The cost of change curve was written into one of the contracts we worked on, in that every time the customer wanted a change he had to pay more and more for it as the project went on. Eventually he decided we were being obstreporous or something, hence the whole litigation thing. Since we had a watertight contract and had visibly delivered on absolutely every single thing he’d asked for (regardless of its importance) I don’t think he stood a chance. So probably there was money made on that project, but I wouldn’t consider it a success.
Oh yes – if you’re collaborating with your customer, writing unit tests to enable frequent refactoring and releasing often, I would humbly suggest that you’re not doing Waterfall.
That was me, above – LJ logged me out for some reason.
Do you really believe that’s true?
Really?
That nobody wrote unit tests before XP? Really? That refactoring didn’t exist before XP (although obviously Martin Fowler gave it it’s name and formalised it), do you think nobody has ever done iterative development before XP?
As I said previously, XP is good for the fact that it emphasises these things which may have been lost by people who haven’t studied software engineering or who aren’t interested in it as a subject.
As you say, XP it’s a toolbox, but it’s not a toolbox containing brand new shiny tools.
No, but it contains a ton more tools than I had when I did Waterfall. Check here:
http://en.wikipedia.org/wiki/Waterfall_model
for a definition of Waterfall as I understand it. The big defining feature for me is the up-front requirements analysis and design; if you’re collaborating with your customer, accepting new feature requests, redesigning, coding and delivering them incrementally, then you don’t follow this model.
In fact, I would say any team behaving this way is pretty Agile. XP isn’t the only Agile methodology. In reality, our team steal lots from other methodologies, including Scrum and plain common sense.
Did you think that iterative development was part of Waterfall? Interesting…
Google for “iterative waterfall”, it’s not a new idea, classically this ends up with the spiral.
You still have the phases of the waterfall, but they’re more tractable and realistic.
“In future months we will describe Iterative and Incremental Development
Processes (IIDP). and show how it addresses the weaknesses of Waterfall.”
“The Rational Unified Process (RUP) advocates an iterative or spiral approach to the software development lifecycle, as this approach has again and again proven to be superior to the waterfall approach in many respects.”
“Iterative vs. waterfall software development: Why don’t companies get it?”
So an Iterative Waterfall, or Iterative Development, or Cascade, or whatever other name you want to call it, isn’t the same as plain old Waterfall, which is what I was referring to.
I’m not saying there aren’t processes or ways of modifying Waterfall to patch up its defects – just that what you get out of it isn’t Waterfall any more; it’s something very different.
A good blog entry, Liz. It’s also pretty special to work with good people with vision. I myself didn’t realize how special it was until I found myself working with just-average developers just drawing a paycheck.
You write, “In fact, I would say any team behaving this way is pretty Agile. XP isn’t the only Agile methodology.” This is a point I keep observing as well. XP at root is about finding the things that work and taking them to their logical conclusion. That’s why it doesn’t surprise me that XP’s critics end up with a lot of the same tools in their toolbox.
In embedded development, there’s one well-known author and speaker who rails against XP. But he continues to amuse me with the practices he himself espouses. They seem to be ripped out of the same Scrum handbook whence came much of XP. Sometimes I wonder if maybe some XP adherent once said something nasty to him.
-TimK