Moving from doing agile to BEING agile

Are you an experienced tester who has recently joined an agile team? Maybe you have testing experience but until now it has only been on traditional waterfall projects. Are you going through the motions with this new way of doing things but don’t feel like you’re completely invested? Do you even feel like you’re adding value to your team?

 

Often times, when a company begins their agile transformation they think they are BEING agile when in fact they are just doing it. Being agile takes time; it’s no sprint but a marathon. One thing that can be helpful is hiring an agile coach who has had many years of experience under their belt helping companies to adopt their agile; as they have seen success stories as well as agile disasters.

But, then there is the worry of selecting the right agile coach, right? Well the truth is… there is no one great or perfect agile coach… each one is different and has their own strengths and weaknesses and each one may probably shares different views on what they believe to be the most important key metrics, collaboration approaches, etc. Pair-coaching in agile can often help the organization and the coach by providing more than one view or insight.

Here’s the deal. Your focus before may have only been on testing, but now it must be on quality as a whole. Think about preventing defects early on, as well as finding them later. You’re used to thick requirements documents, but now you rely on a few bulleted items in a story and a lot of conversation with your team. Gone are the multi-page test plans. Now, it’s a small document or, again, you may just talk it through with your team.

In addition to the changes mentioned above, you also now take part in agile ceremonies you may barely understand, let alone embrace. You story-point, attend stand-ups, give your three updates, and go to retrospectives. You wish you could be more confident in your role, and be as excited about this new territory as everyone else on your team seems to be.

Insecurity about a new situation is normal. Right now, you are doing agile – going through the motions. This is different than being agile. Mature agile testers succeed because they are being agile and not just doing agile. Let’s get into the difference between being and doing and learn how to put it into practice.

Being Agile vs. Doing Agile

Doing agile focuses on tactics, ceremonies and techniques. Being agile focuses on team and leadership mindset, as well as behaviors and adoption. Being agile is more about living the principles and values of agile while doing agile is more about following the processes established by methodologies like Scrum, Kanban, or SAFe. The Agile Manifesto is very clear that we should consider “Individuals and interactions over processes and tools.” Here’s some context around what this actually means.

Each day you go to your stand-up and tell the team what you did yesterday, what you will do today, and list any impediments. That’s doing agile – following the process for the stand-up. If, during that same stand-up, you mention an impediment with a group of your tests and a developer automatically offers help to fix and/or execute them then that developer is being agile. The developer has an agile mindset because she is thinking about how to help the team deliver the product – even if testing isn’t what she normally does. Being agile means we take ownership of the team’s success, not just the areas or tasks we are typically responsible for. That only perpetuates silos that naturally occur in waterfall. We want to break these down in agile.

Just Enough

One of the essential patterns of mature agile testers is called Ruthless KISS. Basically, the idea is we should be LEAN and do just enough. But it has to be the right just enough. We must focus on what is important at that time, in that sprint. However, if we concentrate only on the important testing items for the current sprint, we are still just doing agile. On the other hand, if we help everyone on the team resist gold plating, and actively help and encourage them to do just enough – the right just enough – we are being agile.

 

Another way to handle the just enough that must be done is to trust your team. Testers must trust the developers to do unit testing. We must trust they are doing the right things at the right times and this trust, in turn, minimizes the overlap of what is tested as the code moves from development to test. This is definitely a change in mindset from traditional testing where adversarial relationships between testers and developers used to exist. This trust allows us to do the right just enough. It is truly a change in mindset.

Anyone can do scrum as described in the Scrum Guide. However, being agile requires agile behavior and intent in delivering value. You don’t have to do things by the book. Rather, move to an agile mindset. As you continue your agile journey, strive to reinforce the agile mindset through your actions and interactions.

 

Up next:

• Three Key Agile-Centric Metrics >> Read
• Pair-Coaching in Agile >> Read