Thursday, June 21, 2018

The barriers to successful agile adoption by software Testers | Supreme Agile


I think that almost any major changes in life face barriers to success and in an agile transition, the story is not different. Once the organization decides to start an agile transition, he expected to face multiple barriers that arrive from many areas and especially from the organizational culture.

Let us examine the organizational culture from the eyes of the QA teams. Think about a QA team that has already established a strong organizational culture about quality, this team is now committed to the culture, which makes it extremely hard for them to drop it for the new culture that is a mandatory part from any transition to agile.

In this article, I will focus on some of the most common barriers to adoption of agile development frameworks that you can expect to see in your testers and QA teams. 

The uncertainty of their new role as testers in agile teams


There are many differences between agile and other traditional software development, the role of testers in agile teams is just one of them but yet a very important one. Testers that integrated into agile teams must have the preliminary knowledge of what are the boundaries, expectations, and responsibilities that they will need to follow in their new role. 

This is the only way to allow those testers to reduce the amount of uncertainty prior to the start of the agile transition, a tester that will not gain this important information will most likely have much more difficulties to perform at its highest performance and to be a productive team member.  

It is not just about testing anymore

Agile teams built from a set of individuals that work together to achieve a common goal. Each team member will have to use is knowledge, experience, and technical skills to help the team with the many challenges that involved in the environment of agile development.

To become really valuable team members, testers will have to take more responsibilities and roles than what they used to have in the old traditional environment. Besides the obvious activities that involve in testing, testers will have to understand the true needs of the team and take an active part in resolving them, just for example:
  • Work closely with the analysts and developers right from the very beginning of the project.
  • Help the product owner to design and determine the acceptance criteria.
  • Help the team to move forward to complete the iteration goal.
  • Interact with the product owner to clarify the business requirements.
  • Help the team to estimate stories, define ‘Done’ and assess testability. 

Relying on negative past experience


Hold your horses….past experience is critical for anyone and especially for test engineers when I analyze common pitfalls of integrating testers into agile teams, I can see one common issue that repeats numerous times and that’s software testers that have been through changes that did not succeed.

As a result, from this bad experience, testers are kept focused on their previous unsuccessful patterns and start the agile transition with a negative approach that will defiantly not help them or their new team members. Questions like “Why should I do it again?”, “I already been in this process and saw how it fail” are just classic examples and big red warning signs for this issue. 


Loss of Identity


I can write thousands of words about this topic alone, but for this article let us keep it simple. In traditional testing, test teams and each individual tester are working in an independent group with known barriers, responsibilities, and goals. 

Now that they need to move to small agile teams that built from more developers than testers, this change alone is enough to trigger many fears from the tester's side, for example: 
  • Fear of losing their ability to affect the quality process.
  • Fear of losing their job during the agile transition.
  • Fear of losing their ability to affect the prioritization of quality items.
  • Fear of being less productive in a continually changed environment.
  • Fear that they do not have the relevant skills to work in agile teams.
  • Fear that they will not get the support they will need to do their work. 
  • Fear of losing their QA identity (Now that they need to invest time in many other activities).

Bad Attitude


Is there really need to explain why bad attitude can be devastated for software testers that now need to work together with their associated developers?  By using the wrong attitude, testers will up to face major challenges in integrating into their new teams, here are some of the classic examples:
  1. Testers that does not participate in the day-to-day activities.
  2. Testers that perform only the minimum tasks without taking more responsibilities.
  3. Testers that use bad attitude towards the deliverables of their associated team members.
When the organization faced with a transition to agile frameworks, many engineers have a bad attitude that does not allow them to give a real chance to the new agile process, the results. In most cases, this engineers will leave the organization at the start of the transition or after a few weeks of the implementation process.

Although agile development has many advantaged over traditional methodologies, we need to keep in mind that agile development is not for everyone, but using the right education, training and the removal of many uncertainties can really help to mitigate engineers with the wrong attitude.

Lack of Training (Methodology/Technical)


Training is one of the most important things for testers prior they integrated into their new agile teams; the training sessions should focus on two main aspects:

Methodology – This is relevant to the entire organization that will need to get the necessary training about what is agile and how to work in this new environment. However, for testers there should be an additional educational layer that will help them to succeed in their new teams, this layer should allow the testers to visualize their future in their new agile teams and how can they contribute to the success of the team.

Technical - There is a Hugh difference between traditional and agile testing, testers should get the necessary technical training that will allow them to stay relevant in their new teams. Just, for example, a good training of programming languages will allow the testers to handle many automation challenges such as writing/using the automated framework, writing and debugging tests and share a common language with the rest of their team members.

After many years of involvement and directing agile transitions, lack of training is one of the most common reasons of failures to integrate testers into agile teams, so there is a Hugh important that your testers will gain all the training and knowledge they need prior and during the integration into their new teams. 

No comments:

Post a Comment

My Presentations