Few days ago, Phillip Calçado from Thoughtworks came to our office and gave a presentation on Agile Web Development.
Here are the slides of his presentation - Agile and Web Projects in 20 Minutes (slide 12 really cracks me up). Phillip is also a blogger - http://fragmental.tw/ - beware he writes long posts!
The timing of the presentation coincides nicely with me finishing Scrum and XP in Trenches (free non printable PDF from InfoQ) last week.
Phillip explained cheekily what tends to happen in a (waterfall) project - project started off with high spirit but ended up sourly in the end, why? It is because the long delivery (and feedback) cycle on the traditional waterfall way.
This is what usually happens - after the scoping period - the client signs up a contract that lists X number of features to be delivered by Y date. And then away the development team goes implementing - closer to Y date perhaps 1 month before - client is starting to review the staging site. The client begins to see things are not exactly what he had in mind - he becomes unhappy and requesting changes to be made (the closer to the delivery date, the appropriate word to use will be demanding and threatening).
The development team’s boss doesn’t want to lose the client (and the money) and does what a normal boss would do - he asks the team to work overtime to meet the change requests (and still meet the deadline). And so the team work overtime.
At the end (and this is the slide number 12) - the client gets the end product that he “can live with” and some fed up developers just resigned all together.
The solution that Agile proposes is to have shorter delivery/feedback cycle. The development team can release a version of the project say every two weeks - get it reviewed by client. All well and good, but here’s the catch - using this approach, the development team cannot promise X number of features to be delivered by Y date. What it can promise is, there will X number of people working in this project until Y date, there will be a release every 2 weeks. The outcome of the project (or whatever features will feature in the end) is continually shaped throughout the project by the client and the team.
Phillip then explained the tools and techniques he uses on his projects:
First, Agile (or Scrum at least) requires dedicated team works on a project for a period of time. A team doing a sprint shouldn’t be doing any other things not related to a sprint. This doesn’t seem to be the case with web development firms (at least not the ones that I have ever worked with) - more realistic picture is developers are floating between few projects, being pulled to different projects at ad hoc basis as required. Perhaps this would be easier if the company has larger pool of developers.
Secondly, it will be hard to ask client not to sign up on features deliverables. To implement Agile, the client needs to be on board with Agile practices as well. Apparently Thoughtworks will not accept clients that won’t go through Agile practices. It will be impossible for smaller web firms to say no to clients that won’t do Agile (and not committing on x features by y date).
I’m still pretty green with the whole Agile thing, it makes sense, but it seems also too good to be true - so far I’ve read the successful outcome, would be interested to see when and where Agile projects fail as well.
It seems learning Agile would be a beneficial thing to do, kind of a good break as well from learning new languages/frameworks. By the way, if you are in Sydney there are 2 Agile meetups here: http://agile.meetup.com/cities/au/sydney/.