That Agile Development? It's just Waterfall in disguise.

This isn’t me but it could be you… Photo by  Talen de St. Croix  on  Unsplash

This isn’t me but it could be you… Photo by Talen de St. Croix on Unsplash

When I worked at IPC Media (now TI Media) they bought a Flash games website called Mousebreaker. Previously owned by two developers who had created football, pool and other highly playable Flash games housed on a site which, if you were being generous, you would call ‘homemade’.  IPC wanted to literally start again with the website so it could swathe in banner advertising, build in the ability to sell Takeovers and basically milk it for as much ad revenue as possible.

The most interesting part for me was that IPC was embarking on its first truly Agile development project. The team was formed of a Project Manager, two developers and myself to create the site from nothing.

We started in the most literally Agile way, we took a blank HTML page and embedded a flash game in the middle. This got us started quickly and it also gave us a kick off that wasn’t mired in  planning documents or brainstorming sessions; it was real code with a real game on a real page. It was also invigorating for me because we weren’t getting bogged down with documentation too much because we were working from the inside out.

I also think that it’s interesting from another point of view, we were focused on the most important aspect of the page first. This way you cannot add anything that distracts away from it because its hierarchy has been established in the minds of everyone that is building or reviewing the site. The game page did get more complicated with hi-score charts and related games but these elements never took over the page because we had cemented the game's position.

We took a similar approach to the category and home pages but these went through numerous re-designs as we reviewed and tested each build after launch. In fact, the homepage was re-designed at least 3 times over the preceding couple of years. But the outcome was clear, we created a game site from scratch in a fraction of the time it would take using techniques we use today.

I think building a site like this works with a very literal Agile technique because it’s relatively simple in its structure and in a more complicated build some additional planning will always be needed, but I'm starting to think that it may be less than we currently do as an industry. Now calling for less planning in an industry that is plagued by ill-thought-out plans might be seen as insane. Identifying the user, their needs and their pain points is still woefully lacking and when stakeholders are thinking of their project this is the planning that needs to be done. When it comes to the build, however, I think it's perfectly valid to pair a developer with a UX designer and get stuck in.

In my first true UX role, back in 2003 designing an e-learning site for the Natural History Museum, we had no concept of producing paper prototypes or any software to create usable wireframes so we built our preliminary test site in HTML. It was then tested with real users and we iterated until we could pass on the layout to the design firm who was tasked with designing the site. But if the designer were there next to us we could have jumped straight in, used the HTML to form the basis of the site and been leaps and bounds ahead of the game.

Now fast forward to what we call Agile now and as far as I can see, apart from some trendy stand up meetings, 3 in a box conversations and liberally sprinkled copies of 'Sprint' lying around, we are basically developing in a Waterfall style again.

Leadership tells the Product Manager what is needed, the PM briefs UX, developers wait for UX to complete their work and in the meantime finish up the last project which needed loads of changes. When UX has gone backwards and forwards discussing theoretical ideas on how to solve the project it gets passed on to development, when they are complete they demo the code and UX feedback saying it's not quite how they envisaged it working, it gets fixed and launches but the users don't behave how we expected and then the iteration cycle starts. It's Waterfall!  

How has this happened?

In many organisations I've worked there hasn't been time to properly engineer an agile setup. It takes time to save time and even when the saved time massively outweighs the effort you put in, sometimes we just need to get shit done. It becomes harder and harder to catch your tail, you kid yourself that a developer muttering that they set up a thing on the server and now they can do a thing whilst your UX designer daydreams about limited edition retro Buffy Pogs that you are doing Agile, you're not. We're doing Ribena Agile, watered-down techniques that essentially result in the delays, miscommunications and poor usability of the dark ages of development.

I think there are two solutions to this problem. The first alleviates the 'we need this now' messages we get from leadership and the second saves lots of time iterating at the end.

1. You always need to be ready.

Don Norman said it so why aren't we doing it? If you never have time for research, you should be doing research all of the time. Be ready when leadership want to launch a project to accelerate one part of your customer base, have the stats and know the user. I see this as part of my role as UX Director, to think ahead about our audience and have 50-75% of the knowledge upfront. This will reduce research time down from weeks to days.

2. Use that knowledge of the user and have the developer and UX staff collaborating directly.

Instead of a meeting at the start of the day where we mention the progress each of the parts of the projects being put together separately we show the progress of the page and the conversation should something like 'we've placed the image gallery in the blank page and myself and UX'er are going to implement 3 types of forward and backward buttons today and test them around the office'. With the different departments directly collaborating progress will be super fast and super iterative and effectively save tons of time.

Of course, things aren't that simple. But I think we should hold sacred the purest form of Agile development and attempt to get as close to that as we possibly can. We can easily do the first part of the problem, we can be constantly researching the industry, we can have up to date personas and benchmarks.

The second part is where we need serious effort to make it happen.

Ed WalkerComment