I saw recently one of Mike Cohn’s presentations on Scrum. Actually Szymon organized a series of meetings in our company where we watch some of agile though-leaders and have discussions. Mike’s presentation was a good one and a good discussion followed, but one thing struck me at the meeting.
Most of presentations about agile approaches are completely naive.
I sure am biased with my skeptical approach but definitely I’m not an agile-hater. Quite the opposite. I use Kanban (yes, some of you will tell that’s lean, not agile). I will be speaking at Agile Central Europe next month. You can’t say I’m against agile.
Yet still, I often feel offended how agile is sold to me on different occasions. “Agile raises your productivity.” “Agile makes your product better.” “Agile is going to make your product suit better customer’s needs.” “Agile is just better.” Oh, really? And agile makes the best coffee around, doesn’t it? Throwing arguments like that with no knowledge about background is brain-dead. With agile you can achieve all these and even more. But at the same time agile doesn’t guarantee you anything.
What more, with any other consistent and reasonable methodology you can achieve such good results. Yes, with waterfall too. Unless you know more about specifics of organization you can’t really tell whether this or that approach would be better.
And then I hear someone telling that 20 years ago someone else said some methodology (likely waterfall-like) was ineffective and the conclusion is: if it was ineffective 20 years ago it is even more ineffective now, that’s why we should switch to (new, cool) agile. I may even respect both guys (at least to the point where I’m not going to give their names) but that doesn’t make their statements any less stupid. Or less naive. Or less insulting. Or all three at the same time.
So please, please, please, don’t tell how silver the agile bullet is. When stating how it improves work add few sentences why it helped. How exceptional was client’s engagement. What top management did to enable and increase agile adoption rate. How hard these few people worked to convince developers that agile is fine. What were specifics of projects run agile way. What did you do with tasks which don’t suit well to most agile approaches (like maintenance).
Don’t mix your well-grounded arguments with purely marketing messages generalizing everything to the point where it has no value whatsoever and is completely meaningless.
You’ll sound less naive. Well, maybe people would see these as obstacles and treat them as excuse not to try agile. If they do so they wouldn’t have succeeded with agile anyway. For the rest your voice will be more reasonable and more convincing.
All posts of The Carnival of Agile Bullshit.