It Halloween! As it’s this time of year, we thought we’d consider the ‘evil’ ways that agile practices, principles and tools can sometimes be misused. This was inspired by a recent conversation we had with a client. It transpired that a team who had been using agile for a few years were doing so really badly. They were alienating other teams and jeopardising the success of a large delivery. It was less zombie scrum and more nightmare agile! This got us thinking about some of the more ghoulish behaviours we’ve seen from both agile teams and leaders.

1. You’ll get it when you get it!

This particular behaviour is one we see a lot, and there are generally two main causes; 1. The team doesn’t have the sufficient capability or support to plan what they are going to do, and 2. The leadership use data against teams.

We all know the value ‘Responding to change over following a plan’ but this is not instead of following a plan. Often, business partners will get frustrated with teams where the organisation has moved from very heavy weight planning to seemingly no plan at all. We have been party to countless planning sessions, retrospectives and showcases where teams have said’ That’s not the way agile works – it’s all about value so you’ll get it when you get it!’

This should not be a defensible position. The responsibility that comes to teams with empowerment means that they must support the operational business with lightweight and adaptive planning that help meet commercial obligations, sales targets and anything else that keeps the lights on.

Similarly, we have facepalmed many times in leadership coaching sessions where the teams primary desire is to track team or departmental progress through velocity or something similar. For obvious reasons, we would never suggest this, however the main pitfall leaders make is trying to compare the velocity between 2 or more teams and not look at the overall value delivered to users and customers. Of course, chasing this metric often leaves teams feeling like they have less say in how they do their work and breaks trust between them and leadership. This paves the way for a more defensive response to ‘When are we going to get product 1’ and ultimately can lead to some of the issues above.

It’s the responsibility of all concerned to not shy away from difficult conversations. Do not determine how teams progress and successes will be tracked – ask the team how they can best show this. Don’t use lack of knowledge about data to not attempt planning – educate those around you about adaptive planning practices, build smaller increments and amass data to help you make better decisions.

2. Teams ‘empowered’ to fail

We love a good empowered team – it’s a thing of great joy and beauty to watch talented people come together with a sense of purpose and all the support they need to deliver value. After all, one of the core principles is to ‘trust them (the team) to get the job done’ and organisations like Spotify stake their reputation on decentralised decision making within empowered teams. But just saying that a team is empowered does not make them so.

As organisations move beyond doing simple robotic agile, many start out in a position where teams are ‘granted’ their empowerment, but without discussing what this means in terms of the support, tools and the direction they need. In fact, the only thing this means is that the team is ‘empowered to fail’. We don’t mean in the positive ‘fail fast and learn’ way, we mean in the ‘That’s the team’s problem’ way.

Yes, empowered teams can end up being a dumping ground of half-baked ideas and unsolvable problems. To work effectively, these teams need more ongoing support than ‘regular’ teams. You will need to set a direction that’s more detailed than ‘Build us a new platform’. You will have to facilitate conversations within teams and between teams. You might still have to make some decisions for them as well, especially in the early days. Empowered teams are the result of an ongoing process of learning, adaptive boundaries and trust building. It is not a binary state. Leaders need to be an ever-present and constant source of support and compassion to bring about this change.

3. ‘Spying’ ceremonies

Each team will have their own ceremonies that help them create short feedback loops for their products and their practices. Crucially, the teams should determine their own combination of ceremonies that best suit the work they are doing, as well as their own level of learning.

However, one of the more insidious things we see is hijacking or spying in team ceremonies. It’s insidious because it erodes trust within an organisation and between leaders and teams very quickly. It’s not uncommon that we see someone like a CEO or CTO who ‘wants to see agile in action’ turning up at a team stand up. Usually, they are unfamiliar with agile and so start talking to the team during the ceremony, turning it into an uncomfortable standing conversation. Sometimes, they can overreact to the amount of information they hear. They interpret it as the team having loads of issues and set hares racing trying to ‘help’. It’s great if you have leaders who want to find out more about agile and the way you work specifically. Take them for a coffee and suggest they have their own stand up.

Another bad behaviour we see is the hijacking of the showcase or product demo. This is usually by someone who isn’t overly keen on becoming agile and is looking for ways to undermine the work agile teams are doing. As soon as the demo ends and the ‘Any questions/ comments’ section begins, they are guaranteed to dissect every detail and poke at every possible issue in front of an audience. In fact, everything aside from giving some constructive feedback.

This is a real challenge as showcase hijacking or spying can do some real damage to teams depending on who else is at the ceremony. It’s important to encourage participants who add value, but to dissuade those who are not. Talk to these hijackers outside of the ceremony to explain your practices and longer-term vision. They might become better at giving you feedback. If not, un-invite them! This does not mean they can’t have a separate viewing of the work, it might just be better to make this less public.

That’s our three evils of agile. If you’ve recognised these behaviours in your organisation, remember that the practices are not evil – it’s the intention behind them. If you’ve recognised these behaviours in yourself, it’s not our intention to offend! Keep in mind that the teams and individuals involved with practices that frustrate and puzzle you are doing so with the best of intentions. Try chatting with these practitioners to share your concerns and find another way forward. We hope you have a happy Halloween and share with us your evils of agile….