Guess who? (Kill the Agile Buddha)
Guess who am I now.
I’m in a supermarket, I’m pushing a trolley. I’m putting items into it. I just need some bread and I’ll be going to the checkout. Who am I?
I’m in a bank, queueing up in front a machine for depositing cheques. I’ve got a couple of cheques I need to pay in. Who am I?
I’m in an electronics store. I want a new printer but I’m not sure what’s the best for me, I’m looking for someone to help me. Who am I?
Or maybe what am I?
I am a customer.
Aren’t I?
Business language backs up my assumption. The employee at the supermarket checkout is called a Customer Service Rep, my personal (customer) details are held in the banks Customer Relationship Management system, in the electronics store I’m looking for Customer Support. And after I’ve bought my printer I’ll be asked to complete a Customer Satisfaction Survey.
So everything indicates that I am a customer. Or that is what I thought I was.
Apparently not according to the Scrum zealots.
At Agile 2009 Tom Illmensee presented a paper “5 Users Every Friday: A Case Study in Applied Research”. It describes how an eCommerce division of an electronics retailers introduced agile and how the user experience team adapted to agile. It starts by describing how their initial forays into agile were deemed successful. It was collaborative with the disciplines well integrated; “whiteboard wireframes, minimal documentation, and product demos. Usability tests with paper and semi- functional prototypes were conducted with shoppers each sprint”. More than that, the whole team enjoyed the experience. A decision was made to “take agile to the next level”. The next level was the introduction of a consulting firm who brought in scrum training. The scrum dogma was painful to adopt, but they got there in the end. But there’s a line in the paper that made me angry:
“The peculiar semantics of Scrum were especially confusing at first. In retail customers were people who bought things like stereos and flat-screen TVs. Not anymore. Agile had changed the definition of perhaps the most important word in our business environment: customers were now internal product owners. Customers would now be referred to as shoppers—or users.”
I’ll write that again. Customers (the people who the business depended upon, and “the most important word in [their] business environment”) would now be called shoppers. Or users. Because in agile, customers are internal product owners.
Sorry, these consultants, these agile zealots, these software egos have got too big for their boots. Dan North, pulling to pieces the nonsense of ‘software craftsmanship’ put’s it eloquently:
Software Craftsmanship risks putting the software at the centre rather than the benefit the software is supposed to deliver, mostly because we are romantics with big egos. Programming is about automating work like crunching data, processing and presenting information, or controlling and automating machines.
Software at the centre rather than the benefit the software is supposed to deliver. Software is the means to an end, not the end itself. If a certified scrum master (certified master based on two days training and a multiple choice questionnaire, now there’s a farce) tries to rewrite your business language, tries to tell you that your domain language is wrong, show him or her the door.
There’s a budhist saying “If you see the Buddha on the road, kill him“.
If you see agile in your workplace, kill it.
Why kill the Buddha? because the Buddha becomes an object, your own illusion of what it is. And it this illusion is wrong. To turn the Buddha into a religious fetish is to miss the essence of what he taught. Killing the Buddha means taking responsibility for yourself. Same with Agile; to turn agile, to turn software development into a religious fetish is to miss the point of what it is all about.
===
I presented on the customer theme a while ago, here are the slides.
And here’s me narating the slides on google video.
[…] This post was mentioned on Twitter by marc mcneill, Leancamp. Leancamp said: How can Agile can trap you into losing sight of the customer. /by @dancingmango http://bit.ly/eo6TkP […]
Great slides Marc, good content & message.
I also liked the video presentation, it felt a bit like a stop-frame animation. I could imagine you jumping around like a ball of energy whilst doing it, in that distinctive manner of yours!
Agile is in danger of becoming a dirty word. Being over processed and over used to describe just about anything that is supposed to make team work in a quicker, cleverer and more innovative fashion. Agile has nothing to do with innovation. Great ideas and intelligent people who take risks to get something out there that rocks based on gut feel.
Allow me to react to your reaction.
You have half a post of well-founded critique of people doing harm in the name of Agile. Then you cite Dan North’s exercise in vanquishing strawmen and drag in Software Craftsmanship and generally flog a bunch of people who are trying to move programming forward.
The burden is on you to familiarize yourself with what people in the “movement” are really up to before dismissing them this way. This is as unproductive as dismissing all of Agile in 2003 because you heard of some team that thought Agile just meant you don’t have to write documentation.
Why shouldn’t I be able to turn this around on you? You want to dismiss good coding practices and techniques and write software that works for the customer, go say things that make business people believe YOU’RE the one one their side, not these hippie navel-gazers, get paid your rate, and then the day after you leave the project the product falls over or needs a rewrite in order to add basic new features.
This is dumb, it’s unproductive to say the least.
Steve, thanks for your comment. Fair points and it may have been disingenuous to link the first part with Dan North’s thinking. My agenda is not to dismiss good coding practices, far from it what I take issue with is when the dogma associated with practices and processes becomes more important that the reason and rationale behind them.