In Agile Mindset, Guidance, Scrum

fish

 

One of the significant changes while moving to Agile teams is that testers and developers are now part of the same team.

This change introduces great advantages, as well as some challenges.

The immediate impact is that the testers participate in the Scrum ceremonies and get a better exposure to the product under development, its status and fragility. They can therefore detect better potential areas for defects finding, they gain better sync for when they’ll get a drop for testing and can better utilize their plans.

It sometimes looks more like this:

scrum-level-1

What we are missing is that as much as this seems like great progress, it focuses on the tester’s local optimum. The mindset is still of a siloed test team that needs to utilize the tester resources better, rather than how to achieve the team’s product delivery goals with high quality and in a timely fashion.

The Agile team is not really a team yet. It is a mixture of people from different disciplines but they are not compounded as a team yet. This results many times in testers that feel weakened, having lost their power of defending the product quality and of determining how and what to test. They are being told by the SM or Team/Tech Lead how much to test, usually just to minimize test overhead. They are being asked to document less, not to open defects when not needed, to test something that is still in progress, and their test manager is no longer in the teams to back them up. They feel abandoned!

This is a crucial period. I repeatedly see it during implementations and Agile testing workshops I run. On the one hand, the testers crave that the team will understand them and the quality needs, and on the other hand, the testers also need to change their mindset so they won’t impede this change from happening.

This is the place where SMs, Agile leads and the whole team need to take a shared responsibility on quality and see how they can work it out together as a team. They need to encourage the testers to voice their opinion during Scrum ceremonies and to focus the team on minimizing the gap between testers and developers and how they all contribute to testing.

Yes, it is intimidating for developers. They didn’t join the company to test…they are developers! It is time to understand that the team should focus on their shared goals. Developers should get to know the tested system better, to focus on unit testing, to strengthen the automation testing and to assist with any setup or test planning that can make a better flow.

On the other hand, it is also intimidating to the testers. They need to change their mindset. They don’t trust the developers to do testing or to distinguish between a test overhead and a risk. They don’t see the benefit of testing small batches of the product. It looks more like an inefficient plan of re-testing. They feel that if they won’t report, then no one will recognize their work. It is time for the testers to realize they have much more value to offer than to detect defects – they need to prevent them from the get go, they need to represent the user. They need to collaborate with the PO and the developers to identify problematic areas before coding. They need to become test architects, guide the team, promote these early and small batches to ensure they hold an end to end solution and are in the right direction. They should identify automation requirements and address them and gain trust in automation and in the team.

Adopting Agile testing mindset and practices should make this movement and bring you to a higher scrum level:

scrum-level-2

A mindset change takes time. Moving testers into the agile teams is not a mechanical move. It requires trust, collaboration, learning, adoption of new practices and experiments and persistence.

This is why we advise developers, SMs, managers and team leads also to join our Agile testing workshop. Ultimately, it is not only about the testers but about testing. Yes, it requires leadership to build quality into Agile teams.

What about your challenges?
We’d be happy to help you in this transition. Our Agile Testing workshop is a good starting point. Hope to see you there.

 

Recent Posts
Comments
  • Amit Elazari
    Reply

    Above is illuminating and poignantly accurate to how teams approach unified operations.

    There are, however, other alternatives teams may, and sometimes — should — undertake in order to better prepare for and acquire Agility.
    One approach to observe is proactive certification involvement as of preliminary planning stages; such involvement might enable TDD or BDD. We would see something like this (https://pbs.twimg.com/media/C1Kexg0XEAAYNIh.png).

    Or — when QA personnel are well entwined in automated processes — even this (https://pbs.twimg.com/media/C1Ke1z2XgAAyEgX.png).

    (In both cases we may wish to allow some additional hardening, challenging our collections with robust workflows, concluding load or stress runs, etc.)

Leave a Comment

Start typing and press Enter to search

%d bloggers like this: