Lots of businesses send their team leaders on an agile course, only to have them return and fail to implement anything. It’s no-ones fault. The truth is that being agile isn’t easy, and it’s even harder when you’re an agency.
We spoke to some attendees from the event, ‘Agile for Agencies’ to find out what current problems businesses are facing. They were pretty candid about the problem with agile. One lead UX designer had this to say,
‘It’s easier to work agile when you’re in house, because you can change processes quickly. For me, that’s what it means to be agile. Try something one week, if it doesn’t work, try something else. So, if you want to have a weekly sprint, go for it. If you need to reassess tickets every week, and groom them so you don’t become swamped, then do it. But if that doesn’t work, don’t feel like you have to stick to one way of working.’
When done right, agile can produce magnificent results. I’m in awe of the work done by Us Too, the agency behind the game Monument Valley. They were able to harness a flat structure so perfectly, that they produce games within their own teams. But this example is sadly rare, because in my view, agile is broken.
In the agile community, there’s a constant battle for purity. Are you adopting agile perfectly? Are you a charlatan? There’s an inherent irony here. Agile should not be a one size fits all methodology. It only works in some places. True agility is using what works, where it works, when it works. We’re not being agile about agile.
There’s a superiority of ‘agile’ that also needs to be dispelled. It’s a wonderful system when used pragmatically. But when implemented incorrectly, failed agile projects cause more mess than any other sort of project. So, what’s wrong with agile?
One size doesn’t fit all.
Waterfall systems, fixed prices and fixed deadlines are what some clients need. Accept this, please. Some clients cannot work agile. And forcing agile on these types of project is a fool’s errand. Real agility comes from seeking out what works, and finding ways to solve problems in teams, even if that means keeping some legacy systems.
Equally, don’t fall into the trap of buying an agile tool, and walking away. Don’t create a structure around your tool, instead look for a tool that fits your process. Tools are useful, but in some cases a spreadsheet and a good process can achieve more. Just like ‘agile’ as a buzzword isn’t the solution to your business woes, so the latest ‘tool’ isn’t either.
In a fixed price environment for instance agile as a dogma holds that you should be able to change your mind, your estimation and your process as you go along. By all means, I agree with swapping things in the backlog, but the problem lies in estimation. Estimation for change should not be free, and changing project focus needs a control.
Agile is associated with great teams at Facebook and Twitter. And so it has become something leaders see as a silver bullet. It’s the new ‘thing’ that will supposedly cut costs and delays. But this has led to widespread botched implementations of agile. Leadership that won’t properly invest, or management that want everyone else to be in a flat structure, apart from management itself. Leaders are part of the problem, and need to learn to work differently too.
If we look closely at implementation, the impact can be huge if done correctly. Spotify developed an entirely agile way of setting up the company structure. Using ‘squads’ - autonomous multi-skill teams responsible for one business area, and ‘guilds’ - horizontal single-skill teams that share good practise, Spotify was able to develop a new business structure. The squads are able to act with full functionality, while the guilds meet regularly to share knowledge and techniques.
Agile isn’t all bad. When done well, for example at Just Eat, in certain government branches or at Spotify, leadership was transformed from the top down. If agile is a broken concept, let’s look now at how it can be fixed. And as a note, the regular event, ‘Agile for Agencies’ we co-host might interest you too.
Source
Published at pmmagazine.net with the consent of the author