Agile changed my life. It was a working methodology I was fascinated in, as I worked on projects in an old-fashioned Waterfall way and I heard, read and was privy to a lot of discussions on great digital work achieved through agile practice.

As Traffic Manager at After Digital, I manage the planning, scheduling and overall delivery of the team and products we build. We face many challenges on a daily basis; big bugs that need to be addressed as soon as possible, long-term roadmap items, bespoke requests, setting and resetting priorities, strategy planning… the list goes on! Our work is fast-paced and can be hugely challenging at times (part of why I love it so much), but agile helps us all to collaborate more effectively as a team and keep it all moving forwards together.

Scrum-Images1

Agile can go wrong though. And, when it does, your team can swiftly plummet, alongside your work. This can happen in a number of ways, one of the most common I've seen is people lacking clear protocol for dealing with challenges. This causes people to avoid having conversations about them and, ultimately, resolving issues. I can't shout enough about how pivotal communication is to good agile work. And, not just agile, communication is the key to all great work. 

In the beginning

People leave training excited (providing the training was good of course) and boom you're ready to start being agile. Maybe the whole team aren't totally on board yet, but they are willing to try. You might have a few that are thinking "this will never work". That’s all good, change isn't for everyone and there's still the occasional misconception that agile is just a buzzword which doesn't reflect their roles and can't be adopted. Everyone's different and not everyone will just change because someone says they should (in fact, if everyone agrees to a major change and there is not concern — I'd panic!).

Then, the bad day happens — an individual, team or organisation goes from believing agile can work to believing it’s a farce. It happens quickly, and often quietly. But a good Scrum Master sees it and it's never nice. One team member becomes negative with the feeling that management doesn’t care. They then pass this feeling onto another team member, followed by another, then the team feels this infection of negativity and before you know it, your team have lost faith in agile and fall flat, looking for change, leaving or reverting back to old habits, while cursing the name 'agile'.

There's never just one cause. Any organisation-wide initiative requires transparency for it to succeed. It also requires considering how you want to behave and act when things don’t align with your goal.

A scrum team is supposed to commit to work based on what they believe they can complete in an iteration. If they are committing to work that they know they can’t achieve, then there is a problem. It is a common problem and is just one reason why some people believe “agile and scrum are bad.” Some believe this is just a different way to get people to work nights and weekends, since “they” committed to getting the work done. Of course, agile also talks about a sustainable pace — nights and weekends are not sustainable (in fact, they usually result in less productivity). The key ingredient in a good agile team is simple for me, COMMUNICATION. You can have a great team, skills, the best tools and everything else, but poor communication will always make it go wrong.

Who do we blame?

There are so many options:

      • The Team: Blaming the team seems like a solid approach. I mean, they are the ones doing the work and if they are too weak to speak up, then they get what they deserve. No?!
      • Blame the Managers: Blaming them is another terrific option. Why not blame the big guns ‘in charge’. They are obviously pressuring the team and are a bunch of clowns with big egos that do not understand real work or the pressures we 'everyday folks' feel. 
      • Blame the Scrum Master: Always a top contender! If only the Scrum Master would have told us, then we would be able to address the issue. They must have saw the issue coming a mile off and did nothing about it. What an idiot!
      • Blame the training: This is my favourite. I mean, great target. These geeky agile coaches floating around, talking about agile like it's the best thing since sliced bread. It's all a lot of rubbish. How can training change anything. 
      • Blame the Culture: Another popular one. It must be the company culture. It’s just the kind of place we work. It’s just like that here and agile will never work. This is such a great one as we do not have to point out a person or even group of people, we can just more or less say the whole place stinks and cross our arms resolved to the fact forever.

Blame whoever you want, it will not change the reality that blame is just a way of letting go of power. If it is someone else’s fault, then you should just sit down and wait for someone else to fix it. Wait for someone that might have the answer. Or worse, disengage from agile and all the work the team had adopted, and, in turn, from the team itself.

What can you do?

What are your organisation’s goals? Do they want to actually use agile to deliver more value? To compete more effectively in the market? To adopt innovation and creativity? To create an organisation where people enjoy working? To deliver products in a specific and transparent way?

If you are aiming for these ideas, communication is key to making it work — HAVE THE CONVERSATION.

What you want to aim for in the conversation is to find out what everyone wants to do when something like this occurs. Then write the ideas down in a plan to circulate with the team and create a protocol to address these issues.

  • Ask: If the team feels like they are forced to commit to something that is impossible, how will they want to act? What will they want to do?
  • Ask: If management believes the team is not being honest about what they can get done, how will they want to act? What will they want to do?
  • Ask: If the Scrum Master sees an issue developing that no one is sharing, how will they be? How will they act? What will they do?

Go crazy with frustration and throw that agile book, maybe even a colleague out the window...? That might be what they initially want to do. But what will they do when they think about it for a moment? What would be productive to move forward? If their aspiration is to throw things, well, it’s not a total loss, at least you know where you are and what you need to work on. Let's try to keep throwing to a minimum though.

Have these conversations and agree on your protocol. You can obviously ask more questions, but the core of the questions is to identify the behaviour you want to model and to consider how you want to be when an issues comes up. If you have never discussed how you will address these when they come up (or some variation does) your chances of successfully dealing with them decreases and your risks increase.

If you attempt to have these conversations or even talk about having them and people start freaking out, you are probably on to something.

The work we do is challenging, fast moving and we're not wallflowers or people who quietly sit in lazy rooms where you can hear a pin drop. We're in a field of immense innovation, creativity, ever-evolving tools, products and technology. Cross-functional teams should be talking to each other, sharing ideas, even constantly debating best practice. This is how our team works, and I wouldn't change it for the world.