It’s 2006 and I’m sat in a large meeting room at the start of a system demonstration — what I’d now call a ‘Show & Tell’. About 20 staff are waiting to see part of a new web based (.Net) application being built to replace a client server solution. The new product has been developed using an ‘agile’ approach (FDD). This was new approach for the organisation and there was a mixture excitement and trepidation about the demo.
The business people on the project team led the demo, walking through a feature set in the system. It all worked, but the people in the room, actual end users, where not impressed. Hesitantly at first, but with growing irritation, they pointed out how the system didn’t reflect the actual process or user need. It rapidly became apparent that a product that the team had thought was close to ‘shippable’ was in fact a long way from that.
It was one of the most dispiriting and frustrating meetings I have attended (and that’s saying something). Wasn’t Agile supposed avoid these sort of situations. In fact things had never gone that badly wrong using our previous RAD/JAD prototyping based approach. So how had we needed up such a mess?
Well for a start we hadn’t really started with user needs. The project was centrally driven and the ‘users’ on the project team weren’t end-users, they were central policy team staff who had limited experience doing the job the system was supposed to support. Furthermore, they weren’t empowered product owners, frequently having to refer back to more senior staff who held the vision of the new product, which was to support new ways of working. In effect they were being proxies both for product owner and the end user. They were doing their best, but it was an impossible ask.
The project had adopted some agile practices; stand-ups, feature backlogs rather than detailed functional specifications. But it also had more waterfall like practices, with long phases and big releases planned. The latter meant it took a long time for it to become apparent that the project was in real difficulty. There was some justification for the release schedule. Migrating from client server to web incrementally, while providing a good user experience, is a tricky challenge. What is an MVP in the context of replacing an existing system rather than greenfield development? There is no simple answer, but seeking regular feedback and ensuring increments were shippable would have helped avoid that car crash of that meeting.
Eventually the project was cancelled with an official write off of £1m.
I’d like to say we learned our lessons. We went back to RAD/JAD for a while. The next major agile venture was led by a consultancy who claimed agile expertise. Yet, we ended up in a very similar meeting with the consultancy essentially blaming agile for the project being in crisis. We took it in-house and completed the project, late.
The moral of all this? Well, there is no silver bullet, any approach agile or waterfall can be applied badly. Setting out on a major mission critical project with a method few people had any experience of probably wasn’t a great idea.
More fundamentally I think the project lacked discipline. Agile can become an excuse for a lack of rigour, a laziness of execution. In fact I think agile frameworks require more discipline of approach that more rigid approaches like SSADM.
The project gave (fr)agile a bad name within the organisation that has lasted years. Perhaps the real lesson is that implementing agile without an agile mindset is doomed to fail.