InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Interview: Keith Braithwaite, an Agile Skeptic

Posted by Abel Avram on Dec 30, 2008

Sections
Process & Practices
Topics
Agile Techniques ,
Agile
Tags
agile2008

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.

10 comments

Watch Thread Reply

Correction... by Clinton Begin Posted
Re: Correction... by Abel Avram Posted
Selling Agile is a Smell? by Cobbie Behrend Posted
Re: Selling Agile is a Smell? by Keith Braithwaite Posted
Re: Selling Agile is a Smell? by Cobbie Behrend Posted
Required viewing by Chris Matts Posted
seems to me more of a criticism of "BEST PRACTICES" by Richard Kucera Posted
the video appears to be clipped around 9minutes by niall fallon Posted
Re: the video appears to be clipped around 9minutes by Floyd Marinescu Posted
Re: the video appears to be clipped around 9minutes by niall fallon Posted
  1. Back to top

    Correction...

    by Clinton Begin

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

  2. Back to top

    Selling Agile is a Smell?

    by Cobbie Behrend

    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.
    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?

  3. Back to top

    Re: Selling Agile is a Smell?

    by Keith Braithwaite

    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.

    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.

  4. Back to top

    Required viewing

    by Chris Matts

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

  5. Back to top

    Re: Selling Agile is a Smell?

    by Cobbie Behrend

    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.
    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.

  6. Back to top

    Re: Correction...

    by Abel Avram

    Fixed. Thanks for noticing.

  7. Back to top

    seems to me more of a criticism of "BEST PRACTICES"

    by Richard Kucera

    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?

  8. Back to top

    the video appears to be clipped around 9minutes

    by niall fallon

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

  9. Back to top

    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

  10. Back to top

    Re: the video appears to be clipped around 9minutes

    by niall fallon

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

Educational Content

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.