ia play

the good life in a digital age

zagile across divides – aches and pains

We did a lot of Agile projects at the BBC, as a general rule it was a style enthused about by the developers and grumbled about by the designers. I had good experiences and bad and to be honest most of the bad were where the project was called Agile but was really nothing of the sort.

My current headaches with Agile are different, and mostly come down to the client-supplier situation:

Lack of co-location
Essentially the developers are in one office and all the decision makers are in another. Questions are often saved up for face-to-face meetings rather asked at the right time to prevent wasted development. Face-to-face conversations are too rare and are often replaced by easily misinterpreted email debates.

Developers aren’t the only pigs
(http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig)
There are plenty of other people are producing vital deliverables. The methodology needs to manage them too but if those people are off-site and employed by a different company (even if that is the customer) then it is easy for their work to be less closely managed.

Confident Agile leadership
Most projects I’ve been in have involved a significant number of Agile newbies. Usually this hasn’t been a problem as there has been a strong, experienced Agile advocate. With a client-supplier relationship there needs to be an advocate on both sides. In the absence of an experienced advocate, all problems will be assumed to be the fault of the method.

Shared ownership
With a supplier involved it creates a barrier between team members. Prioritisation decisions are left to the product owner rather than being made by a team of experts (or at least on the recommendation of a team of experts).  It is too easy for the supplier to leave tricky decisions to the customer, who doesn’t always understand the consequences of the decisions.

The financial bottom-line
I’m not an expert on contracts but the wrong choice of contract can damage the choice of Agile as a methodology. For some more informed thoughts about contract choice try:
http://alistair.cockburn.us/Agile+contracts
http://www.poppendieck.com/pdfs/AgileContracts.pdf

I’m trying to tackle the first two points, as they seem to be the most within my control. We may be able to repair some of the damage to the project but I fear it may be too late to rescue Agile’s reputation within the organisation.

Written by Karen

December 30th, 2008 at 5:03 pm

Posted in agile