Agile / Not Agile, and the Impact on Testing

Do you remember the time you were on an Agile team, and the various members were going on and on about “Agile this” and “Agile that” and celebrating having the perfect velocity and perfect process? And you were so excited to start every day because you were so confident in what everyone was doing – until it sunk in that “Nope, I don’t think I got this, because I don’t think they got this either?”

We’ve all been there. So, what do you do? In some cases, you hope for the best. In others, you try to inject a set of best Agile practices which will work for that team. The best case is both: remain hopeful and move from “Not Agile” to “Agile”.

As the changes begin, focus on three things to ensure where and how best to inject best Agile practices:
1) Assess the ‘openness’ of the current project team towards adopting best practices, or if you need to take baby steps, better practices
2) Identify what current problem areas are in need of improvement
3) Assess what the improvements should/could look like

Within the finer points of this structure, the project is guaranteed to improve.

Let’s talk about each a bit more.

1) Assess the “openness” of the current project team.

If you have project team members that are not as aware of the non-compliance of the project to true Agile practices, then the openness aspect becomes a bit challenging. Some team members have never been trained in how Agile is supposed to work, others know but may not like the rapid delivery and levels of accountability that come with Agile. If people are closed-minded in their approach and willingness to change, the change may need to come in the staffing itself. On a recent testing project at SPR, the client’s development team and SPR’s testers were challenged to become a lot more direct and one-on-one in communication. Developers and testers were made aware of what is expected in Agile communication and had a strong desire to implement more compliant practices, little by little, piece by piece, in hopes that in time a full conversion would occur. You gotta start somewhere.

2) Identify what current practices are in need for improvement.

Project teams may believe and feel that they are practicing Agile when in reality it’s “Agile-like”, at best. For instance, the milestones and deliverables of each Sprint are key to Agile methodology. Development is quick and specific, Testing is thorough and deliberate, and the resulting product can be successfully released to Production, all within no more than a 2-week window. Anything more than that is Agile-like (sometimes also known as Agile-fall…get it?). If your team is truly looking to adjust, then in-depth strategy and planning is necessary to identify the quick and dirty areas to focus development on, and to allow sufficient testing to occur. If you can’t have testing as part of your “definition of Done,” then the content planned for the Sprint needs to change.

3) Assess what those ‘need for improvements’ are and should/ could look like.

Once aspects of the current process are identified as ‘needing improvement’ then work closely with all team members to see it come to fruition. Remember, transition is a work in progress. Everyone should have input, and everyone should be responsible for changing. On the previously referenced project, small change made all the difference in the world, starting with Sprint planning meetings occurring with everyone on the team (developers, testers, etc.; not just leadership). The simple idea of design documentation, to clearly identify and map out what should happen within the product, gave new depth to user stories. And let’s not forget the concept of reviewed and approved acceptance criteria, giving the testing team a simple target that truly makes a world of difference.

This is not to say that these ideas are the be-all and end-all to working with a project team to assist in Agile best practices transitions. However, they are almost assured to be a great start to helping things move toward a more successful work flow and maybe, just maybe, we’ll truly see the light at the end of the Agile tunnel. There’s always hope.

Not Agile…Agile!!!