Why so little good Agile?

03 May

Today I gave a talk at the  Government Test Professionals Forum 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 Behavoural 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 organizations 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 prioritizing 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 organizations have followed over the years, just with a different brand.

Thank you!

Your details have been submitted and we will be in touch.

Enhance your productivity, sign up to our newsletter

See our Privacy Policy for more details. You can unsubscribe at any time.

Problem submitting!

- {{formError.message}}

Submitting, please wait

/images/newsletter.jpg

Thank you!

Your details have been submitted and we will be in touch.

CHAT