Testing Talking- The impacts to the test eco system going Waterfall to Agile with Leigh Rathbone aka @Villabone

Firstly can you please introduce yourself, explain what you do in your current role, and how you found yourself working in the world of testing?

I’m Leigh Rathbone (@villabone on twitter), I work at Shop Direct. In 1998, April 15th I was sat in my office. Always a day of reflection for me, where I take a bit of time out to think about life. I was Operations Manager at a greyhound track, and with no job to go to, I decided to spin a coin as to whether I should leave or stay. I spun, I left on May 15th. I landed a data input job at a company called Transco, and applied for the graduate scheme, at the ripe old age of 26. I got it, they put me in testing, and I landed my first testing role.

20 years on, I’ve worked at 10 companies, in various testing roles. I’ve also done a tiny bit of project management, and recently at Shop Direct I’ve been part of two exciting transformation programmes, which I’ve thoroughly enjoyed. I’m back in a testing role supporting the test engineers we have in agile teams, and loving every minute of it.

Do you currently follow an Agile or Waterfall way of working at Shop Direct?

We’ve had pockets of agile ways of working over the last 7 – 8 years, but predominately we’ve been a waterfall organisation, until recently. We are on a real journey now, which gathered pace around 12 months ago. We have around 18 squads at the moment which are on their journey, learning the agile mind-set, the ways of agile. It’s a really exciting time to be at Shop Direct, because the right way to learn is to be there at the beginning of the journey, so you see the successes, and the failings, and learn from both. It’s what I call “collecting the battle scars’, or getting ‘battle hardened’.

Why would anyone consider moving from Waterfall to Agile? (Benefits)

These are only my views, and my thoughts, but having had Agile ‘done to me’ in 5 companies now, I think I have the following conclusions as why agile works well:

• Releasing value to your customer quicker. Now this doesn’t mean Agile is quicker than waterfall, what I mean here is from my opinion, the customer is more involved, brought on the journey, receives demo’s of working software, and therefore can feedback quicker as to whether what they are seeing is actually what they want. This is highly motivating for the team serving the customer. Imagine working on something for 9 months, and then told it’s wrong, rather than working on something for 2 weeks, and being told. Which would you prefer?
• It’s more motivating for team members, on many levels.
• For the point mentioned above, releasing value to your customer
• The team feel they are achieving something more often – really motivating. I’ve hard evidence to correlate the happiness of the team going up as they feel they deliver value to their customer.
• The team feel more empowered, so they feel more trusted, and that’s motivating
• Up-skilling can take place if people within the agile team have the right mind-set of sharing, because sharing is caring, right?
• Empathy increasing within the roles as an understanding facing each role is easier to understand, as you witness the pains developers have, Ba’s, UX designers, iDevs – this motivates the team
• The businesses ability to change becomes quicker. What’s important now in the market might not be important in 9 months.
• If done correctly, and focus on agile mind-set, and embedding the principles, it’s easier to attract talent, and keep talent – this motivate the team
• Once the team adapt to the agile ways, I’ve witnessed productivity go up, handoffs to other teams are minimalised, and I’ve seen emails replaced with verbal communication, meaning ‘stuff’ gets done quicker. Probably contradicts my point above about agile not necessarily being quicker than waterfall, but it can be – this motivates the team
• I’ve witnessed innovation and creativity increase. If you surround yourself with people with your capability, you’re usually with likeminded people. Surround yourselves with people who have different skillsets, and think differently, it will breed innovation, and creativity – and yes, you’ve guessed it, it motivates the team

And in turn what may put people off making this transition? (Challenges)

Fear, fear of the unknown. See the picture below. It’s the path people go through when change is thrust upon them.

So the key challenge here, from a company perspective, when moving from waterfall to agile is managing change, winning hearts and minds, taking people on the journey. What I see too often, is when things get tough when introducing change, people revert back to their old way of thinking, and call the new way a failure ….. “It didn’t work for us”, instead of learning from the failures and pushing on.

From a leadership perspective, answer the ‘Why?’ Why are you moving from waterfall to agile? I was presenting at a test conference last year, and I asked the room to show hands as to who had asked the ‘why?’ of their leadership when moving. Two hands went up from about 200. As leaders, instigating a huge change of working waterfall to agile, if you don’t relay the ‘Why’ how can you expect people to get on board?

People often underestimate the next challenge facing companies, space. Space for an agile team to be creative, plan their boards, whiteboard their solutions and brainstorming. It’s so important, the agile teams I’ve seen come together and work best are the teams that have the team space. Lack of whiteboards, monitors, and stand up space can stifle creativity, innovation, and togetherness. This all costs money!

Also in agile ways of thinking, working, tools is important to factor in. Collaborative tools where the team can all collaborate. This is why I think the good old traditional test management tools are dying. They are stand alone, silo tools that only testers access, and use. Tools like Jira, and its suite of plug ins are more collaborative, and inclusive. Companies need to look at tools that organically take off within agile teams, rather than tools being forced on the teams. For example, tools like Trello, Slack, start off usually with a few people using it, showing how collaborative they are, almost underground, then go mainstream in a company once the movement has got too big for the ‘decision makers’ to say no.

The last point I’d make as a challenge to think about is that if you move from waterfall to agile, you have to allow your new team’s time to bed together, and go through the forming, storming, performing, and norming stages. So initially, there may be a perception Agile is more expensive as the velocity will be lower in the first few sprint, estimations will be all over the place, as the team won’t know their true velocity. Companies also underestimate the horizontal teams that support agile squads, like the coaches, environments teams, service / operations, go live teams that will still need to book their time somewhere.

(Maybe I’ve answered the question below here) At the same test conference I mentioned earlier, I gave a keynote on the challenges from a tester’s perspective, of moving from Waterfall to agile. The link is here.

For me the key thing is realising you are asking testers to go from a ‘safety in numbers’ environment (waterfall) to a world where they might be the only tester in the squad. There might be perceptions from other agile team members that the tester knows everything about testing, and all forms of testing, whereas the truth is they don’t. The perception is they know, and are experts in every form of testing within the agile testing quadrants (From Janet Gregory and Lisa Crispin) the truth is they won’t. My opinion is they never will be experts in all the quadrants, and neither should they be. They can be a champion, and ask the questions in the planning, 3 amigo sessions, but there isn’t a human being on the planet who knows everything about testing (Except Chris Thacker!).

Where the tester , and other roles, will have had a management layer protecting them in waterfall, in Agile that dynamics change, and all of sudden, it’s not just skills to test the tester in agile needs, its skills to do actual roles. Like be a test architect, a test manager, test environment lead. They all of a sudden have ownership, responsibility, how scary must that be for someone who had layers of management protecting them previously.

There are things you can do to overcome these challenges, set up a Community of Practice (CoP) where the testers can have a watering hole to return to, to learn, share, upskill, feel they still have a testing identity (Link to my slideshare on CoPs here!).

Also from a testers perspective, it’s the flip side of what I’ve said, they need to relinquish the ‘I’m the tester, I do the testing’ mind-set, and become more of an enabler. Sometimes the right person to test is the developer, or the whole squad, the business / user. Testers challenges in agile is knowing when to enable, who to enable, and why. Tester.

So the company will need to offer support, coaching, and emotional support. The testers will feel very alone, scared, isolated. Support ….. support …. support!

All these challenges can be scary for an organisation to face into, and accept. This sometimes can stop organisations moving from waterfall to agile, they simply don’t know how to tackle the specific challenge I’ve listed, (and there are far more) of peoples roles changing, the skills needed, the mind-sets, the change needed at management levels. In my opinion, it’s really important when trying to move from waterfall to agile, that the top top management, the CEO, stands at the front and states that this is the company mind-set, he / she believes in agile, and explains the why.

What effect will this transition have on different members of the team?
– The Tester – shit, think I answered this above
– The Test Manager

Let’s talk the impact of agile to the Test Manager

The traditional Test Manager role will, and has changed. The following text will make uncomfortable reading for some. I’ve spoken about the impact to the tester in the above section, and it doesn’t take a genius to work out something in the eco-system changes, and it’s at management level. Now that is management level throughout, at developer management level, BA, UX, iDev, and test, the management role changes. How?

• Testers don’t receive their tasks from test managers anymore, or very rarely. The tasks come from the team, as a team, and the Scrum master / delivery manager
• Test reporting changes significantly. The team report issues, defects, quality through different methods in agile.
• The test approach per story is driven and championed by the tester, and agreed and committed to by the team.

So what happens to the Test Manager?
• Coaching: Well, the above 3 points don’t happen overnight. There’s a coaching role to be had for sure to help the agile team reach these three points, especially around the last two points. The testers in my experience, need coaching and support to enable them to grow
• Support on approach: A tester doesn’t go from waterfall on a Friday, to being totally up to speed on a Monday under an agile flag. They will still need someone to go to for help and advice on the test approach for a story or a sprint.
• Upskilling: They still need support in upskilling in order to understand the agile testing quadrants, and then upskill further to do what they are capable within the agile quadrants.
• 3rd party assurance: Very few companies deal with just an agile team to deliver value, 3rd parties are predominately used by all companies, so the assurance of quality coming from them, that maybe previously the Test Manager was too snowed under answering all those emails, running all those test reports, can become a real area test managers add value
• Integration: If your tech landscape is large, integration of agile teams deliverables, 2nd and 3rd party deliverables will still need integration testing
• The future: The most important value add a test manager can do, is keep looking at the future, the future roadmap for tech in general, and trends within tech, and the roadmap of the company. Someone still needs to be looking ahead to ask what future testing skills, tools, the squads will need. My experience shows that once a tester goes into an agile squad, they lose this, if ever they had it. Its heads down and focus on 2 week deliverables. So self-development for a test manager is essential, have a finger on the pulse of what’s coming
• External testing: Again, maybe too bogged down on answering those emails, being the guardian of quality, now is a time the test manager can unleash a real testing weapon that’s been under their noses all the time, internal crowdsourcing. A test manager can work with the squads, and see what other testing can be enabled that probably wasn’t explored before now.

As a test manager, you should go on the front foot, think about how you can add value to your company, and do it now. Think big, start small, start now. Example, if the CIO came to your desk and said they had a secret project that they’ve kept under NDA, and its integrating their website with Alexa, and now the prototype is ready to test tomorrow, what would your answer be. If you are self-developing, learning these new technologies, thinking about how you’d test them, you’re already on the front foot. Download the Alexa developer kit and have play and a mooch. Get on that front foot

Following the shift from a Test Department to a Test Community, what knock on effect may this have on recruitment?

So the one obvious impact is that your requirements, volumes of test manager vacancies will reduce. Now these are the higher earners for recruiters, and where you make your margins as recruiters. In turn what this might mean, is recruitment firms looking at their % cut on testers in order to make ends meet.

You may need to make yourself aware of the difference between a test coach, and a test manager, and the skillsets required for both, and how to weed out who is best at what regarding your candidates.

The role of the testers is, and will change. The expectations from employers will be that testers are not just a functional tester, or a performance tester, an exploratory tester, or an automated tester. My thoughts are that employers will need testers to be able to pull out a toolbox, and use the right testing technique, the right tool, at the right time. Be able to enable the right people, be the testing SME, and maybe not the doer. So the skills and traits needed are more variable. Traits I look for are;

• Curiosity
• Self-development skills
• Sharing those self-development leanrnings
• Team player
• Passion
• Adaptability

Adaptability I hear you cry?????? Yep, in my opinion, being a good user of a certain tool is good, but where agile teams are self-governing, self-organising, some agile teams are given freedom in what tools to use. Take automation as an example. I think the ability to understand automation frameworks, adapt to the tool of the teams choice is more powerful that being a rock star in one tool.

So recruiters are going to have their work cut out. Spotting the charlatans might become easier, or harder, I don’t know. When I deal with recruiters for testing, I like the recruiters to be have a really really good understanding of testing, otherwise how will you spot the blaggers. You’ll get the wool pulled over your eyes too easily and therefore give me poor quality candidates!

Finally, what does it mean to be a truly Agile Tester?

Wow, tough question, as I’m not 100% sure myself what truly agile looks like. I think for me a tester that adds value in agile does most if not all of these:

• Champions the testing within the squad, doesn’t mean they know how to do all the testing
• Enables the right person to do the right testing, at the right time (inside and outside the squad)
• Has a great toolbox that allows them to use their skills and tools at the right times
• Takes their learnings from self-development to other testers, and adds value to the CoP
• Always looks for improvements to their mind-set, their learnings, their testing
• Takes time out to recharge
• Drives conversations at early stages around testing, and proactively challenges if they feel they’ve been missed off important discussions
• Gives valuable, timely feedback to squad members
• Is an ambassador for testing within the squad, the test community internally, and external to the company
• Takes ownership of challenges within the team
• Encourages debate, healthy conflict, and respects everyone’s views
• Is……. A ….. bloody ….. great ….. tester

For any Testing news, follow @Gabbibility on Twitter!