The Agile Tribe

Why so little good Agile?

on May 9, 2011

Author: Shane Hastie (reproduced from Shane’s blog)

Today I gave a talk at the NZ Government Testing conference in Wellington. I presented a case study about how the Farm Systems Division of Livestock Improvement Corporation have adopted Agile methods.

I told the story of Team Awesome (they choose the name themselves), how their practices have changed and the measurable benefits that have resulted from their new way of working:

  • Massive reduction in residual defects
  • Increased team satisfaction
  • Shorter time to market
  • Increased customer satisfaction.


I told the story of how the team collaborates, how all the roles work together, how testing is fully integrated into the flow of work and how the whole team (developers, analysts, product manager, testers) coordinate their activities starting with expressing the detailed requirements for user stories as test design specifications using the Behavourial Driven Development model.  They have adopted Agile well, and gained the benefits that all the books talk about.
After the talk I was chatting with one of the attendees and she said that my story was unusual – her experience as a tester on ‘agile’ projects has been uniformly negative – testers as victims of development teams who use “going agile” as a excuse for hacking and not bothering with requirements.

This saddened me; surely we know how to apply these practices properly. Don’t management in our organisations understand that agile is about applying the practices in a disciplined way?  You can’t just pick the pieces that seem easy?  Agile works when the combination of practices are applied together – for example: user stories are a good technique for identifying features and prioritising the work to be done, but they must then be supplemented by some technique to define the detailed requirements on a just in time basis, just ahead of when the story will be developed.

You can’t just adopt user stories and ignore the detailed requirements and testing – that is truly Tragile, but seems to be oh-so-common.

Building software is hard work; building good software takes a concerted team effort, irrespective of the methodology being used. We know this, and have known this for the last 40 years.

Please stop calling these half-hearted implementations Agile – it’s not, it’s just a continuation of the bad practices that many organisations have followed over the years, just with a different brand.

About the author:

Shane Hastie is Chief Knowledge Engineer at Software Education and also Agile News Editor for InfoQ.com.



Advertisements

4 responses to “Why so little good Agile?

  1. ” Please stop calling these half-hearted implementations Agile – it’s not, it’s just a continuation of the bad practices that many organisations have followed over the years, just with a different brand.” I couldn’t agree more.

     I did find it interesting that your post was slightly at odds with Tony’s right below.
     
    There is a fine line between being adaptive and pragmatic tailoring vs going too far.

    For context of a more ellaborative thoughts – http://agileforest.com/2011/05/25/a-converse-view/

    • Shane Hastie says:

      Thanks for the comments Renee – you’re right about the fine line. I’m not in favor of fanatical adherence to a set of rules as a replacement for considered thinking; find the set of practices that work together to enable the most effective delivery of value to customers, but make sure it is about effectively delivering value not about using the label agile to justify doing sloppy work.

      My tirade is aimed at teams and organizations that pick up a few practices that look easy without understanding how the various practices interact together to create a system to deliver customer value effectively.

  2. […] 08:01:59 smithcdau: Why so little good #agile @shanehastie asks… http://www.theagiletribe.net/2011/05/09/why-so-little-good-agile/ (via […]

  3. Grtgrt says:

    The problem seems to be that the Agile Manifesto is not abstract
    enough:

     

    For defining Agile we should focus on the goal of
    Agile
    rather than on the misleading, very problematic way
    suggested by the authors of the Manifesto: Please read

    The
    New (2011) Definitions of Agile
    , or

    Agility
    is fine – though the Manifesto can be Poison

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s