Why being agile doesn’t make you Agile.

As a smaller agency, we’d always fancied ourselves as agile. But it was when we discovered we could also be Agile that things really changed – and not just our appreciation of the importance of capital letters. Managing partner Fergus Adam explains how Dare West learned to love the Agile development process.
DareWestAgileProcess

 

We’ve always been small – able to flex and change the way we work to deal with whatever issues and situations we had to. And it worked pretty well for us… right up to the point when it didn’t.

Digital projects are fiendishly difficult to manage. Every function you need to add leads to greater complexity, more possible ways to do things, and a higher risk of things going wrong.

That was us about a year ago. Even using the latest prototyping and online sharing tools we started to find that, as projects got bigger, it was all too easy for small issues to quickly become big problems. Suddenly it was hard to make a profit because we’d got ourselves into a situation where we were managing all the risk of a project – just before going live.

We needed to change how we worked. And, about a year after this realisation, we have. It’s been bloody difficult. There have been some rocky moments along the way, but we have a way of working that is really making a difference to what we produce.

The core attraction of Agile was frontloading risk. We were pitching everything on the big firework moment. That moment that builds up in a flurry of late nights and arguments, and the inevitable ‘if something can go wrong, it will’ moment. Instead, it would surely be better to lump the risk into the front-end planning, then focus on small increments – delivering bits to the client as you went. Perhaps even launching when it wasn’t completely ready. It all sounded very appealing.

Putting it into practice was hard. Twenty years of trying to change consumer behaviour didn’t really prepare me for how hard changing the way your team works can be. 

Instrumental was Henrik Kniberg’s book Scrum and XP from the Trenches. If you’re looking at your process, this is a must read.

So, off we went and we started working the development team in this way. High fives all round. But it wasn’t really working very well. UX, design and the dev team were not joined up. That’s putting it politely. There was very nearly a fight at one point. 

The solution presented itself when reading about tractors. John Deer put in place Agile as a way of developing new product launches. This grew organically from small IT projects into a company-wide adoption. If they could use it to develop tractors, perhaps, just perhaps, if we adopted it fully, it might help us develop software… the thing it was actually invented for. Pretty obvious in hindsight.

Embracing the methodology wholeheartedly across the business has had a massive impact. And convinced me you are either Agile or not. I recently heard about someone extolling the virtues of WAgile!? Waterfall + Agile, apparently = WAgile. Sounds a bit like our (lower case) agile approach of old.

Also vital was having the right tools. There are three main ones I think.

Central to this process is the humble, not very technical, Post-it. Super Sticky ones are a must – thanks 3M. And a wall. Or several. At the task-level you can’t beat the physical interaction with Post-its and a wall. It’s easier to make sure a stand-up is actually a stand-up in front of a wall. And it’s hugely satisfying for everyone – watching your Post-its march across the board during the two-week Sprint. Our agency is now awash with them. And thankfully, and without a briefing, the cleaners seem to get that they are important and leave them alone.

Next was a tool that allowed us to do a lot of stuff. It’s fine to have the task level on Post-its, but organising everything to get to that point needed a more technical solution. We wanted to standardise and manage User Stories; assign them to (and manage their priority within) Sprints; view and update their status; capture and report poker scores and the task planned detail. We needed to be able to collaborate on and comment on User Stories in a place that keeps that manageable – NOT via email! Lastly, we needed to be able to make all this completely visible to clients. Wrike has been a revelation. It does all this and more. We’ve recently added automatically generated reports. Once created, they’re a live view of progress on a job, removing the overhead of creating client status reports. And dashboards allow each member of the team to view stuff that’s relevant to them. Thank you, Wrike!

Number three is a willingness to change. One of the most valuable things about Agile is the constant opportunity for learning and improvement.  The easiest bit to fall out of the habit of, is reviewing what’s working and what’s not in an end-of-Sprint review. But it’s probably the most important bit (along with a willingness to tear up what you’re doing if it’s not working and try something new).

The team are now working together brilliantly. Our UX, design and test teams are building solutions in collaboration with developers and QA up to the point they are approved, tasked, planned, and head into the development Sprint. Then they’re out the other end as fully formed and tested bits of functionality ready for review by our client and customers for brands as diverse as Good Energy, Places for People Leisure, Starbucks and the institute of imagination.

It’s exciting to be a part of it and watch it happen. And I think it works because we’re creatures that rely on immediate feedback to help us develop and make us happy. Mihaly Csikszentmihalyi stressed this in his groundbreaking book Flow: The Psychology of Happiness. Bringing a bit of this to our jobs can only be a positive.

And we have a Sprint retrospective tomorrow … so this may all have to be re-written.