Interview: Keith Braithwaite, an Agile Skeptic

"knots and bolts" => "nuts and bolts"

I wonder if selling agile is the real smell Keith is describing. In order to effectively sell a particular agile methodology you must package (catalog) best practices in such a way that easily identifies what you are selling, resulting in the symptom that Keith describes:

There is an answer and your desire to do things differently from that is an indication that either you haven't understood, or you've not appreciated something else and your organization is broken and that makes you want to do things differently, or something of that nature. There is a kind of excessive strength or force in the way these things are performed. You can almost understand why an author would do that.

Unfortunately, some of these catalogs of Best Practices, say things like "If you feel you want some Monkey Bag with our set of Best Practices, that's an indication that there is something wrong you." More specifically, if you want to change them, then you've made a mistake, which I think is quite a dangerous principle to have floating over your head.

Hi Cobbie. I didn't, and don't think that it would be terribly helpful to go around "naming names" on this. However, the danger sign is pretty well defined and that's the thing to beware of.

By the way, your transcript isn't quite right (the fault of my accent, I'm sure) What I said was:

Unfortunately, some of these catalogs of Best Practices, say things like "If you feel you want to monkey about with our set of Best Practices, that's an indication that there is something wrong with you." More specifically, if you want to change them, then you've made a mistake, which I think is quite a dangerous principle to have floating around in your head.

Well said Keith. Should be required wiewing for anyone considering Agile as an approach.

I have this hypothesis: Agile brands that have a well defined commercial marketing strategy are going to be defended more than brands that don't. When it comes to agile, defending the commercial interests of a brand (components, identity, and language) is counter productive because it leads to unacceptable levels of rigidity.

As you point out it is very ironic when any agile approach has rigidity that does not allow you to refactor the approach itself. All agile brands have rigidity: there is a point at which, having altered or abandoned enough of its components, where XP is no longer XP. Hence if someone says: we are going to do XP, there is a tendency to limit the degree to which you adapt XP to fit your needs.

However, when you overlay a strong marketing and commercial structure on top of an agile methodology you increase the inherent rigidity of an agile brand still further, thus increasing the pressure to confine your approach to those practices directly promoted by the brand you are purchasing. For example, if as a CIO I pay money to have someone become Scrum certified I'm going to expect them to implement Scrum, and not something that doesn't resemble Scrum as it was sold to me.

For this reason maybe agile best practices should not be defined (packaged, cataloged) to the degree that they can be sold. You are right, the box is the problem, however, perhaps selling and marketing the box magnifies the problem to unacceptable levels?

With regard to specificity: I can understand your hesitance to name names, and this isn't the first time I've seen this issue mentioned (agilethinking.net).

Scrum is a useful framework to get started down an Agile pathway, but if the framework becomes a rigid way of thinking it destroys its own purpose.

Fixed. Thanks for noticing.

seems as if Certified Best Practices have been proposed since antiquity and have been knocked down since antiquity.

uncritically applying behavior from one context to another is not good. adopting a permanent, certified "Context-driven" stance is also not good.

Here, a message from Library Science:

There is no single set of preferred or "best" practices that one should follow in collecting free Web resources. What succeeds in one context might prove fruitless in another. The practices recommended in this report have proved effective in a specific project or show promise for broad applicability, regardless of the fiscal, technical, or human resource parameters in any specific institutional setting. Ultimately, it is not the practice per se, but rather how well that practice lends itself to a particular set of goals, workflows, and staffing preferences, that determines its effectiveness and value in any given setting.

www.clir.org/pubs/reports/pub98/bodya.html#intr...

Shouldn't we in software development know this already?

I'd like to see the rest, 9minutes is not enough :)

I'd like to see the rest, 9minutes is not enough :)

nice one Floyd I didn't even notice the questions in the transcript, thanks.