Mick,

You made the point I was trying to invoke in the readers. The two hours have to be augmented with something, including coaching. What you describe is what I see. But, in my opinion, the really tough problems, the people problems, are not solvable, and the ‘magic’ Norm Kerth speaks of is not achievable, ever, in two hours. (And tears of joy or sorrow are not magic.)

Cirilo,

Thanks for the comment. But what you do, call Mike ‘old-fashioned’ and call him an oracle, is a really good example of agile bullying. Mike’s team are not highly skilled or motivated, their environment is an absolute mess. Yet, using directive coaching/leadership Mike brings in his projects in on time, every time.

Now, consider an alternative. People I often clean up after, agile gurus, who opt for a coaching style that delegates too much to the coachee and, in their wake, leave a trail of destruction and excuses. They do this because they are shit at coaching (but they had their noses up the arsehole of some high priest the week before at a conference.)

Which would you prefer? Which delivers software?

And old-fashioned, too, is not fair. What we do, as engineers, is as old as the world. Setting up agile as new and deriding others as old is the false-dichotomy and false-consciousness that sells books but does not solve problems.

(Although I do admit that Mike’s comment was puerile.)

Hi Ciaran,

Bad form indeed.

An agile bully is someone who uses the rules to coerce or inducde shame, very much in the mode of 'you can't do that'.

I am sorry that you find my language offensive. 'Shit' is simply an adjective attached to 'coach', replace with 'bad' if you prefer.

Cirilo is a boy's name.

I'll reflect on your comment if you reflect on mine. (You do see the irony of telling me off in the same comment as saying every opinion is valid, don't you?)

Cirilo,

I have no hostility to anyone. The point I wanted to make was that a lot of agilists are bullies, it's a fact, and they latch onto rules to gain moral superiority. I was trying to reflect that back, to highlight how easy it is to drop into name calling (such as calling someone 'old-fashioned'). We are all guilty to some extent.


The gist of my blog, maybe it was not clear, was that the retro should 1) be longer than 2 hours. And 2) should be prepared properly. The agile cowboys, the process parasites, do retros out, and by, the book. I had the pleasure to have dinner with Kerth a few years ago. I have worked v. hard on retrospectives and looking at ways to find the ‘magic’. The metaphor of Goat Island was meant to show how long, and how hard, it is have breakthroughs. By the book retros will not - cannot - lead to anything interesting. (The point I am making here is how serious I take retros, Kerth and I speaking at the same conference about the same topic.)

Mike, I am guessing, was being ironic. I don’t think he would come to this site to read about agile software development if he thought a command-and-control way of working was a good idea. Last time I checked, this was still a nice place to hang out, even if it's uncomfy for certain certified professionals.

However, in terms of low-skilled and low-willed team mates, a directive approach to coaching (or running a retro) is very powerful, and this maybe considered old-fashioned. Where many process parasites fail is that they jump to delagative coaching/retros too early. For this reason, despite the irony of Mike’s comment, it’s important not to dismiss things as ‘old fashioned’. (My comment about gurus was aimed at people who have done a two-day course and – rather arrogantly – think they can run a software project. They cannot, and that’s why they fail, leaving destruction behind them.)

I am back in Holland soon and am looking forward to going over this stuff with you, over a beer, perhaps.

Hope you are well, J.