Agile Principles in Action

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.

White Paper

You might also find our 'Agile vs SCRUM' white paper useful to read. nFocus can underpin agile in a variety of ways. Having worked with hundreds of organisations we understand the changes necessary to ensure testing and quality assurance achieve business objectives. Download the white paper to find out the benefits.