After a few years of experience with agile software projects, I have read the Agile manifesto again and afterwards read more specifically about the details of XP and Scrum, the most well-known agile methodologies. It occurred to me that from both ‘sides’ a way of mixing the two is actively being sought. It seems like a logical choice to me, as XP has always been targeting more the technical practices to get to a good end result and scrum takes aim at the processes that should enable a team to get to a good end result. But that is just a sidestep.

I have noticed that in real-life projects it is quite a challenge to keep using some of the more involved practices (like TDD and Pair Programming) or even to just start using them. These are for a lot of developers new ways of working (still), that take an investment before they start delivering any value. That is why it is necessary that everyone that is asked to perform these practices, is prepared to keep using them during the first period.

For that, it is necessary that everyone in the team knows them, knows why they work en is prepared to give them a fair chance. Unfortunately, just starting out with the practices everyone agrees upon at first doesn’t work very well, because they interact. So to make that selection, someone should first understand fully how they interact. It is better, in my opinion, to go trough all the practices with the whole team, talk about how they contribute to the end result and to decide to start the ‘full monty’ with the whole team.

Important is that all opposition is taken seriously, countered and a unanimous decision is taken to give it a fair chance for several months. Agree upon an explicit review moment with some objective criteria to assess the influence of the practices on the end result. This can pull the last sceptics in, because it is clear to them that they are not agreeing upon starting something unstoppable.

Of course, for a number of practices it is necessary to have the explicit cooperation of higher management and the client. For instance, certain documents (fixed estimation of work hours, full functional desgin, a work breakdown structure) need to be delivered that are not important or not fixed in agile projects. These need to be negociated.

If the client and higher management can be or are already convinced to give it a good change, than that is the best outcome, of course. Making clear what the advantages are (better alignment towards results, beter quality, higher productivity), taking away as many cons as possible and (again) agreeing upon a fixed assessment term should all help. A clearly less favourable starting point, but sometimes the best possible, it making clear agreements on the deliverables, but not on the way they will be produced. A detailed functional design can be produced easier and of higher quality later in a project, than in beginning, when nothing is certain (actually the way it is done in waterfall processes). The chances of it representing the actual system are also much higher this way.

Of course I am interested in experiences that others are having with agile adoption, so reactions are valued. You could also do it in-person at one of the AltDotNetherlands meetings. There you will find a couple of developers, all interested in .NET, open source projects and agile projects. Surf to and you will find more info there, like when the next meeting will be held. Come to one of them if you are interested.

Written by Rick | Tags: , |

No Comments - Leave a comment »

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress | Aeros Theme | WordPress Themes

Better Tag Cloud