Back in 2010 we were asked to create a complex web application; something that hadn’t been done before. Something that we didn’t know was even possible. In fact it turned out that no one – anywhere – really knew if it was possible. The project involved merging user content with video and serving it back to the user in near real-time. A bit like the Swedish Hero campaign but not in Flash and not a one off campaign – something for the e-card market.
It was a big project for us at the time and the numbers involved left me a little star struck. It was a really exciting project too, potentially a ‘breakthrough’ project for a small agency such as ours. And in some ways it did turn out to be breakthrough, just not in the way I was anticipating.
‘Full service agency’? More like ‘No service agency’
This is the part of the story where I start to wince a little at my own naïvety. The project, although for a startup, was sub-contracted to us by a fairly well known ‘full-service agency’. It turns out that it’s generally more appropriate to replace the word ‘full’ with ‘no’ or the word ‘service’ with ‘sales’ but like I said, I was naïve. Said agency set about spending £15K of the startup’s money on ‘requirements gathering and specification’ so they could finalise the ‘estimate’. Actually what they really meant was getting us to spend a pointless month pushing stuff around Axure and endlessly debating the on-page copy of a hypothetical website. That’s the very definition of fiddling while Rome burns.
In the meantime, they refused to fund a small prototyping activity (I was asking for a few thousand pounds out of a £120K or so budget). I wanted us to test a couple of ideas we had about the technology. They hated the idea that a prototype might be disposable and not a tangible ‘deliverable’. And yet they spent £15K on wireframes as a ‘deliverable’. Excuse me while I clear my throat…
Red flags flying at full mast
There’s one last fly in the ointment. At the end of the wireframing activity, even though no prototyping had been done, I signed on the dotted line of a fixed price contract and agreed to deliver based on a fixed specification. We had no idea how to overcome the main technical challenges and there was no evidence anywhere that it had been done before, yet I still agreed to a fixed price, waterfall delivery.
The death march
Suffice to say the next four months were a hard slog but I’m still proud of a couple of things. First and foremost, we managed to build a technical solution that solved a pretty complex problem and secondly, the efforts and commitment of the team were second to none. In the face of adversity, the team rolled up their sleeves and we got things done when they would have been within their rights to have held their hands up and said ‘stuff this, I’m out of here’ at any point.
But the positives end there because there were some pretty brutal moments for us in the months of development, not least including:
- Unable to adapt to change: changes had to go back to Axure, specifications had to be written, costs had to be estimated, the whole process was inefficient and ineffective. We ground to a halt.
- Contractual arguments rather than collaboration: because we were sub contracted, changes were a battle of wills. The company we dealt with treated them as either affronts to their profit margin or an opportunity to make more profit depending on how they interpreted the change. Both situations resulted in friction for us, for the client or for both. Compromise – to the detriment of the outcome – was always the result.
- Poor quality software: the later we worked, the more hours we did, the more corners we cut and the more bugs and technical debt we created. Quality hit an all time low on certain components where the same bugs returned time and time again after being ‘resolved’.
- Sub standard user experience: implementing complex interactions defined within Axure wireframes for imaginary users that we’d had no exposure to was never going to end well. Nor was spending the entire budget BEFORE a single end-user had experienced the product.
The anti-agile pattern
For those familiar with the Agile manifesto, you’ll probably recognise the 4 points above are in direct conflict with the 4 main tenets of Agile development. Uncannily so. I didn’t deliberately intend it this way but it’s reassuring in so much that the problems we had in isolation are common enough across the industry that they inspired Kent Beck et al to discuss a better way of building software.
The anti-lean pattern
We finished the product eventually. It launched. It failed. No one wanted to use the service. We’d broken the number one rule and built something no one wanted with all the money. And that’s painful because once we got it in front of users, even the few that we had, we were able to understand what they did want. It would have required what we call a ‘pivot’ but there were opportunities to explore. Unfortunately we’d spent all the money, or if you watch Silicon Valley ‘run out of runway’. It’s really frustrating to get to the point where you have confidence in the direction your product should take only to realise your journey is over.
A better way
Once the dust had settled, our lead developer Rob Squires, desperate not to repeat the disappointment, suggested we look at ‘Agile’ after he attended a Meetup called ‘Agile Evangelists’. I had to get over the fact the Meetup was organised by a recruitment firm whose staff would lurk around in the background but generally the Meetup was good – it had some decent speakers and the room was filled with like-minded people, at varying points in their journey to discover a better way of developing software, with very similar stories to my own about how they came to discover Agile.
Just the beginning
I don’t believe the problems we encountered are isolated to our experiences. You could argue that I should have known better, but smarter people than myself have fallen into the same trap. This project was our ‘breakthrough’ project though, it resulted in the most significant change we’ve ever made, culminating in our ability to build a successful real-time trading platform used by traders all over the world – in only six months. Hopefully some of this journey resonates and maybe inspires other to change for the better.
One word of caution: the realisation that there’s a better way of developing software is only the beginning of a very long journey in which you should never stop learning and never stop changing. We’ve been through numerous iterations of our Agile approach; refining it, and in the case of moving to Kanban, pivoting on our approach. The moment you think you’ve nailed it is the moment at which you’re most likely to be presented a new challenge that you’ll need to adapt to. That’s just the way it is.
“Never settle. Never. Ever. Not even once.”
Manifesto of the Passionate Creative Worker