<img alt="" src="https://secure.wauk1care.com/164394.png" style="display:none;">

The Benefits of Agile: Redefining Success - Part 4

Posted by Renée Elizabeth Mineart on 1/09/2020

Today we welcome back our guest author Renee Mineart, for the final piece in her series on 'Redefining Success'. If you’ve just come across this series, I would encourage you to start at the beginning, so here are links to the previous posts:

Part 1: What to do when Version 1.0 hits the proverbial fan

Part 2: Hey, let’s Talk about how we Talk

Part 3: Don't be a Mob Boss: A Safe Environment for Failure

the benefits of agile

In this post, I’d like to delve into the heart of the topic and look at the benefits of Agile Testing and how to redefine and deliver a successful, failed project. 

If I were to sum it up in a sentence, it would be something like, “Use Agile Methodology.” But of course, why use only three words when 1,000 is more fun?

Changing or improving your process isn’t always easy and doesn’t always solve the problem, at least not in isolation. Sometimes you must take more drastic steps and reassign staff. This isn’t always enjoyable, but sometimes necessary. An ITIL trainer once told me that if you can’t change your people, change your people.

Sometimes, you need to do a bit of everything; small tweaks here - larger changes there, in order to get the desired result. The project I’m working on now has largely played out that way. There’s been a change in staff, a change in methodology and a whole new approach to development, testing and delivery.

In short, we’ve gone from a Waterfall approach to using Agile, with interlocking three-week sprint cycles. We’ve defined a high-level roadmap that drives our sprints and are simultaneously improving communication. Of course, we’ve pivoted people into different roles where they can be most effective. But there is one other change we are doing which is going to have a huge impact, although I don’t think anybody quite realises it yet. We are subtly but significantly, changing how we engage with our user base.

In the previous iteration of the project, we would have a user group meeting with 15-20 people in attendance, 30-40 development points to review along with 20 or more actions that should have been carried out by said user group and 60 minutes in which to review it all.

Sometimes, the first 15 minutes would be taken up discussing just one or two points, leaving us with 45 minutes to cover the rest. Inevitably, that one item you were desperate to ask about, number 23 on the list, would get brought up in the last 10 minutes of the meeting. But with just 10 minutes left and everyone already checking their watches, no one wanted to spend more than a few seconds per item. So, it’s easier to just nod your head in agreement instead of saying, ‘oh, wait, actually there’s a problem with that.’ So, no one did.

I don’t mean to speak badly about those meetings or how they were run. There was just a lot of pressure to deal with a long list of items outside of meetings and not much time in meetings to discuss them as a group.

Here are some of the things we are changing to improve that engagement with our users:

One, we are reducing the size of the user group. The previous group often had 2 or 3 people from the same team while some teams weren’t represented at all. We are going out of our way to make sure teams that weren’t very involved before, have a voice in the current development.

This action is a lot more important than it sounds on the surface. Often if you are struggling to get people to engage with you to adopt something new, it is because it feels to them like it’s being forced upon them. They aren’t part of the change or the decision-making process. Give someone a voice, make them a part of the process and they are more likely to get behind it. Those that don’t, will often bring reasons why, which can be turned into items to improve. Sometimes the naysayers are your best bug hunters. They will rejoice at finding a mistake and pointing it out to you without apology. Which is what you want in a tester.

Two, because we are using the Agile Methodology instead of a Waterfall approach, we are dealing with fewer development items in each user group meeting. Instead of 30-40 changes, we are making 3 to 6, with a few bug fixes thrown in. This means we can spend enough time on each item and give everyone the chance to discuss it.

Three, we are asking our user group to do less. Previously, the user group was responsible for guiding the development team, carrying out UAT and disseminating information back out to their teams. But as the teams weren’t equally represented and because some members never felt comfortable, or had the time to teach the rest of their team about the upcoming changes, the information our customers got was often patchy.

By centralising responsibility for all comms going out and ensuring everything is delivered through webinars, videos and step-by-step instructions, we can ensure everyone receives the training and updated information they need. If an individual or team is struggling, we can divert resources to address their specific issues to ensure no one gets left behind. Take the lessons we learned from that and apply it to the larger community. We can do all of this without making the members of our user group feel pressured into doing something outside their comfort zone.

These changes have formed our new definition of success. Previously, success was all about delivering one massive development project that would change how our IT department used the software as well as about 20,000 individual customers.

Success is now defined by delivering a handful of changes every few weeks and is much more focused on good communication. We are not only listening to our users, but ensuring they have a voice and the time to use that voice. Yes, we have a high-level roadmap that guides our path but diverting off the path a little doesn’t mean failure. Because we are working on smaller changes, adapting the changes is more dynamic and fluid. In other words, we can make an adjustment without crashing the entire project.

To tie this all together, please always remember that things break. In fact, everything eventually breaks. A big part of being successful in delivering projects, or in life in general, is not to get hung up on what broke. We need to review the cause of the breakage, improve our communication, make appropriate changes where needed and learn from the whole experience so that we can move on to success the next time.A How-To Guide For Test Planning


Topics: Benefits of Agile, softwaretesting, communication

nFocus Blog

Welcome to the nFocus software testing blog. As thought leaders and technical innovators, we created this blog to distil our thoughts, ideas and musings on improving software quality.

Fill out the form below to receive future communications from nFocus including our latest:

  • Blog articles
  • White Papers
  • and plenty more!

Follow us

Follow us on LinkedIn to see our latest content!

Subscribe Here!

Recent Posts

Posts by Topic

see all

Posts by Topic

see all