Working in a Agile fashion can be hard. It means collaboration, passive compliance is not enough. Using eXtreme Programing processes is even harder. XP is a set of high discipline processes. But I've often noticed that the jargon of both Agile principles and XP processes are just too easy to misinterpreted. This has lead to the birth of an Agile and XP dark side, an interpretation that absolves developers of all responsibility, encourages passive compliance, and gives the customer god like powers. It moves responsibilities to the customer.
The XP Dark Side seems to me like planning for failure in a way that the developers cannot be blamed. It is the customer who will be left holding the baby. Real seductive if you want to code without responsibility.
The most recent XP Dark Side smell I have come across is the:
'A story is what the customer says it is.'All hail the customer :-)
The customer is seen as an all powerful, all knowing, boss figure. The developer a passive compliant servant. Sometimes this comes from the customer as:
'I'm the customer, I can do anything I want.'Command and control? Certainly not agile.
A collaborative team (which includes the customer) should never move forward without the customer's full agreement, so at the end of the day the story will always be what the customer, and the team, say it is. The customer is a vital leader and owner here, but he/she is not all knowing. The team has a responsibility to work with the customer. Collaboration (Agile) is a choice, but if taken, it requires everybody to contribute to help.
I think that an Agile developer's responsibility includes investigating the cause of defects to validate the design and remove the source of future defects. Code health is the team's responsibility. To delegate this to the customer leaves a conflict of responsibility which results in the 'oh that happened because you did not let us ...'. To delay the investigation distorts velocity and the work must be done and leaving it only increases the cost.
So customers ... beware of the dark side :-)
3 comments:
I think you right on with this post Rob, often developers try and put themselves in a position of success even with failure all around them.
The only point i think you missed is that even if at the end of the day if a dev is saying "it's not my fault and he's why" and maybe s/he is right. But the customer carries the checkbook and they only have to think the dev is in the wrong and next time... no money for that company.
I suppose my point is that money talks and customers pay for results and if they get what they asked for and it turns out to be not what they needed/wanted then the dev team will be paying for it come next customer budget time.
Maybe this is the economic climate that helps developers think in a more truly customer focused way.
Hi James,
You have pricked my interest here with "customer budget time". I did not realise it, but my customer does not (realisticaly) in control of the "budget". My customer has little or no impact developers renumeration.
Dunno ... did you mean something along these lines?
Can you explain further ?
I see the customer controlling the **feedback** on the product and through that the reason for the dev team to be either hired again or given pay rises/bonuses when due.
Surely if any customer is not happy with what has been built for them they take some action. As no doubt that product now reflects on them. Whether that feedback is via choice of vendor for the next project or just bad mouthing a team within the company there seem to always be repercussions.
I often find dev in the last layer of buck passing and it provides a good reason to make sure no one needs to pass one (buck)
Post a Comment