Agile not done “by the book”?

Joel: I got back from Japan a couple of days ago. Just like I do in most of my trips, I got to sit and talk to testers.  I talked to testers in small companies, to testers in huge organizations, had sessions in 2 meetups, and in general had a chance to listen and learn more about the testing community.

One point that came up a number of times, and to be clear this comes up everywhere and not only in Japan, is the frustration of testers when they talk about how their organizations are moving to something they call “Agile” (air quotes).  But this Agile is not really what is thought by consultants or what is written in the Agile testing books.

For each organization it will be different, for some it will be Agile, but testers work and test after the developers finished their work.  For others it will be Agile, but developers are not willing to hear about testing. For others it will be Agile, but they are expected to run full regression suits of testing that take 2 or 3 sprints to complete.  And there are many many different complaints of how they are working Agile, but “not by the book”.

A theme that you hear all the time is that, Development adopted Agile, but everyone forgot to think about testing as part of this adoption.

So today, let’s talk about this, what happens when your team adopts Agile, but they do not do it “by the book” and the testing aspects are left outside of this adoption process.

Agile is not a methodology, it is more a cultural approach. So do not expect to have a book to tell you what to do

  • Each organization can and will implement Agile in their own way. It is more about a cultural approach to managing the project than it is about following a step by step recipe.
  • Agile is also expected to change, evolve and adapt based on the changes and challenges affecting the team. We do this in the same iterative process as we do software development.
  • Agile is nothing more than a set of behaviours. Underneath every framework or book or approach were some people doing things. And it worked for that company, with that company’s problems, constraints, budgets, people, marketplace etc. Because it worked for them, it’s unlikely to work for you by the book.
  1. Does that mean it’s not helpful – of course not
  2. Does it mean you can learn from it – absolutely
  3. But to implement it by the book is to implement a solution to a problem you likely don’t have

Try to understand what is the reason the company is adopting Agile

  • Once you know this, you will be able to also align the testing aspects to this reason.
  • When looking for a reason, find the things that we wanted to change?  Deliver cadence, features being closer to what customers wanted? To be more sexy for the developers in the market?
  • Agile is not the end goal. It is a means to an end. 
  • Agility is about moving smoothly and quickly towards your goals.
  • The key thing to remember is that there are people in other businesses achieving massive success who are not doing agile. 
  1. There are lots of companies who are agile who do not succeed.
  2. It is a way of working and behaving that suits some people, companies and industries better than others.

Don’t take it personally, most of the times people are simply looking out for themselves

  • So your team is doing Agile and they forgot about testing…?  OK, go and explain and remind them. Do not think they are doing this for any strange or conspiratory reason to leave you out of the action.
  • Linked to the previous point, most people do not even realize that testing is a huge part of Agile.  Go and explain how this fits and why this is needed.
  • Agility is moving smoothly and quickly towards your goals, surely the goal is to ship good quality software that does not fail.
  1. Maybe, maybe not.
  2. Agile does not mean removing testing.
  3. It means looking at ways testing can aid in delivering smoothly and quickly, hence it tends to move from a phase at the end of a cycle of work, to an activity that is done continuously.

Take ownership, do not expect people to solve your problems

  • One of the points I have learned are critical in Agile teams and in the Agile approach in general, is the empowerment of each team member to influence and improve the team.  This means that you, as a tester, need to take ownership and also work on influence the team towards achieving their / your goals.
  • Find the people who will be willing to listen to you, work with them, then work with the rest of the team.
  • It means looking at what the goals, measures and business results are, and approaching testing at that level. Taking ownership means helping the business achieve the business results – so all testing approaches, ideas, experiments must be in aid of that.
  • It means thinking through the real problems, not approaching the world of testing in the same way it’s been done for years.

If you are going to lead, then make sure to learn first

  • This is an important point, and many people do not do it. If you are going to demand for testing to be taken as part of the agile change in your company, you need to have a clear understanding of what this means. You need to get educated on this.
  • There are many resources you can learn from, blogs, talks on youtube, peers, etc.  I always recommend the Agile testing BOOKS by Lisa Crispin and Janet Gregory. They now have 3:
  1. Agile Testing
  2. More Agile Testing
  3. Agile Testing Condensed – Leanpub. Start from the last, then 1 and then 2.

Close Out

It is up to you, and also up to how do you prove your value to the team and process.

  1. Do your homework
  2. Work iteratively
  3. Do not take it personally


No comments yet.

Leave a Reply