The negative language of Agile

Agile has become the default working method for teams, but is it creating relationship issues, building blame culture and causing stress?

Are you listening to your colleagues?

In July 2017 I hosted a workshop session at UXBristol titled Empathy for teams. Based on a simple mindfulness activity, groups learn how to listen to their surroundings, create visual soundscapes and discover that what they hear and what the rest of the team hear may not be the same.

For a long time, I struggled to communicate with my colleagues about what was being said by our clients during meetings. I would hear certain words used, observe body language and walk away from a meeting with a low ebb.

I believed I was detecting micro-interactions within the words they chose, when they said them, the inflection on certain statements that meant I was detecting they weren't happy, or that something else was happening behind the scenes that meant our project was about to hit a rough patch.

It didn't matter how I tried to explain what I had heard, everyone else felt they'd heard something very different. Kim Slade, founder of Unknown Epic told me about a mindfulness activity based on drawing soundscapes. I took this and introduced it to teams with great results.

Speaking to Matthew Holley, an attendee at the UX Bristol workshop, Matthew commented, that he had been sceptical at the start of the session but by the end of it was thinking how to do the same with his team. 

His main issue, was that everything he had experienced so far relating to Agile working had blame culture and negative statements baked in.

And he's right.

Agile terminology builds blame culture


Speaking to Matthew Holley, an attendee at the UX Bristol workshop, Matthew commented, that he had been sceptical at the start of the session but by the end of it was thinking how to do the same with his team. 

His main issue, was that everything he had experienced so far relating to Agile working had blame culture and negative statements baked in.

And he's right.

Think about your last stand up for a moment.

All of these questions are built around accusatory statements - what is your excuse?

The Backlog

What seems like a logical way of storing all the ideas, things we could update, new initiatives from the business, quickly becomes the never ending list of things we will never get around to doing.

It has an owner, because without one it is deemed as unwieldy. It has to be groomed, implying that what anyone has put into it is being entered incorrectly, lacks sufficient detail or doesn't fit the format set.

Items in the backlog need to be put into an order of importance, before getting sliced up to say what should be completed in the next sprint.

We have Tasks that should be small and distinct. Stories that are a collection of tasks, and Epics that are so incomprehensible we acknowledge they need to be broken down into constituent parts.

All of this sounds very bad indeed.

Blockers

The worst aspect of Agile is the concept of blockers. Something that has to be done before you can progress with your assigned task.

Most of the time, a blocker is caused by another team member not having a thing ready that you're task is reliant on. There is no other way of looking at the phrase "any blockers" during a stand up and not hear it as either you are holding everyone up, or you are not doing your job.

I've been in businesses where certain individuals in a team are made into seemingly a joke about how their work never gets marked as done on the board from one day to the next, one week to the next and so on.

I'm not sure whether anyone realises how that makes that person feel. There's obviously something going that means whatever they do either doesn't fit into the sprint model that is in place, or they are in need of help and maybe afraid to ask because they've been made laughing stock.

Dependancies from outside the team

It isn't always people within our team of course that cause a blocker. Just as a frequent is a 3rd party.

All this does is create us Vs. them attitudes that are unjust, because those 3rd parties are not part of our team and trying to work at this velocity.

Blockers are the single most damaging aspect of Agile in businesses today.

Can we change Agile language for the better?

I wrote earlier this year about killing phases in projects. Part of this comes from years of working in agencies where the model was based on a tight scope of work that gets trimmed and trimmed until it fits the budget. Anything that doesn't fit in the budget gets moved into phase 2. 

Phase 2, never came - and will never - come.

Agile was meant to resolve part of this pain because it fostered a concept of continual development, the concept of build measure learn. I fear that instead it is being used as the whip to crack the hides of cattle.

We could start with our stand ups.

Finally, allow everyone to be heard, keep it short and listen.

The larger the standup group the more it becomes obvious that everyone brings their thing to the group, waits their turn to speak and is switched off for the rest of it.

Listening is the most important part of the stand up. You might be able to make that first goal (what would make your colleague happy today) become a reality. A great technique for making sure everyone is in listen mode is to have an object that is passed around to the person who is speaking.

At Digital Catapult Brighton, we had a juggling ball which was pass around during our stand ups, and our mastermind sessions.

It took a little while for some people to learn how to listen, and not be visibly focussed on asking for the ball so they could interject, but once you've got into the flow it really makes a difference to what everyone hears.


Thoughts from Andy Parker published 25th September 2017