Why so little good Agile?

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.



---