Interview: Keith Braithwaite, an Agile Skeptic
- Share
-
- |
Read later
My Reading List
In this interview made by InfoQ’s Amr Elssamadisy during Agile 2008, Keith Braithwaite, an Agile developer, consultant and trainer, says that we should show a good deal of skepticism towards today’s Agile practice.
Watch: Keith Braithwaite, an Agile Skeptic (32 min.)
Keith confesses he is an Agile skeptic, not because Agile is wrong in its essence but because Agile is perceived and practiced in ways that distort its base principles. Many failures occur and they shed a negative light over the entire Agile movement because too many times one thinks that buying an Agile book or tool is enough to ensure project success.
Keith suggests students in Agile should be rigorously tested and a certain level of experience should be imposed in order to graduate someone as Agile coach.
Related Sponsor
Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.
Selling Agile is a Smell?
by
Cobbie Behrend
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.I'm wondering why Keith alludes to but doesn't name the primary culprits he is talking about when he is making claims:
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.Some? How many are there? Which are the worst offenders? While Keith does a good job giving you some specific examples of when extra skepticism can save time and money, perhaps people should be skeptical of boxed agile best practices that carry price tags in general? I wonder if money is the motivation that causes people to be more defensive of the agile boxes they create?
Re: Selling Agile is a Smell?
by
Keith Braithwaite
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.
Price tags aren't bad in themselves. I sell services aimed at improving the ability of an organisation to add value through building information systems. The Agile toolkit has a lot of great ideas to offer there and I use a lot of those ideas. And a lot of great ideas from elsewhere.
I think that it's the box that causes the problem. I've gigs where a client has previously had one or another vendor of a particular, specific Agile solution come in and do their thing. The end result has been a diminution of the client's ability, which I (or someone else) then has to fix. That's bad.
Required viewing
by
Chris Matts
Re: Selling Agile is a Smell?
by
Cobbie Behrend
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.I think there is a way to talk about this with greater specificity that goes beyond name calling, and works to guide people when adopting agile. For example, the quote above names the methodology and puts the criticism in the context of what the methodology does well.
seems to me more of a criticism of "BEST PRACTICES"
by
Richard Kucera
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?
the video appears to be clipped around 9minutes
by
niall fallon
Re: the video appears to be clipped around 9minutes
by
Floyd Marinescu
I'd like to see the rest, 9minutes is not enough :)
Hi Niall, have you tried clicking some of the questions in the transcript? They forward me into the interview far further than 9 minutes. I'm not experiencing the 'clipping' you mentioned.
Floyd
Educational Content
Intro to CLP with core.logic
Ryan Senior Jun 18, 2013
Spock: A Highly Logical Way To Test
Howard Lewis Ship Jun 18, 2013
Java Garbage Collection Distilled
Martin Thompson Jun 17, 2013
C++11 The Future is Here
Bjarne Stroustrup Jun 16, 2013
The Big Data Revolution
Claudia Perlich Jun 16, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think