Wagile is written about on the internet in disparaging way by most agile project management advocates. Waterfall advocates generally don’t write about agile, but that’s beside the point. This brief article is about how, in real life, a combination of agile and waterfall methodologies can work extremely well for an organisation.
Project management methodology in real life
One company we helped, had an interesting dilemma with a bespoke, and critical, business system which needed a good bit of work to fix various perceived failures in it’s performance and capabilities by the business.
The organisation had contracted a third party development company to write the application based on a cloud-based development platform. Unfortunately, that development company decided to exit the UK and left this organisation in a bit of pickle.
As part of our service, we found, interviewed and recommended a replacement organisation who gladly took on the not-inconsiderable risk of learning and then supporting this custom development.
Originally, the application had been built by the developers sat in the client’s offices in a (really bad, but we won’t go into that here) agile setup. The new developers were based around the UK and, while the offer of in-house work initially was available, the client didn’t have the budget for this amount of onsite work nor were they advised by their internal expert that it would even require this level of resourcing.
So, with limited budget, no onsite resource and a commitment from the business that they couldn’t spare the kind of time and resource that a normal agile project requires from the business people, we set to work sculpting a methodology and way of working that would allow the client to move forward.
In a relatively agile way (shhh, don’t tell the client), we tried out various options and variations and we settled on a clearly wagile approach.
The Wagile approach
From the Agile methodology we took:
- Business requirements from the business –
We trained several of the more senior account managers how to capture and document business requirements both from their own teams and also from their external clients.
- Focus on Minimum Useable SubseT (MUST) and prioritisation of needs –
Once documented, the senior account managers would also be responsible for prioritising the requirements with their stakeholders using the MoSCoW method. This worked really well to set expectations and allow better cost control of the development.
- Daily standup calls –
Once work was agreed and underway, daily standup calls were arranged with the developers and the internal system expert (IT). Ideally I’d have had a business ambassador on these calls but the business was unwilling to provide the resource. These calls did work well in the end and an added bonus for both parties was that the new development company got insight and education on how the original application was written as well as being able to feedback and discuss the development work underway.
From the Waterfall methodology we took:
- Requirements documentation –
With the need to get external client agreement for changes, it was not possible to get them involved in any kind of daily call, standups, demos etc. So we adopted the waterfall approach of documenting the requirements. This allowed the external clients to agree to what was going to be delivered and also allowed the development partners to provide clear estimates which then needed to be agreed by the external client.
- POs and signoff –
Along with formal estimates (things got off to a rocky start when an intermediary organisation billed a bunch of extra days without authorisation), one of the initial governance items was that new work would not start without a) a formal estimate and b) a PO from the business. This did slow things down a little however it allowed the beginning of the restoration of trust between IT and the business with the long term plan being that these governance rule be relaxed once trust was restored and both client and development partner were working well together.
- Formal handover to support methodology –
One of the biggest issues in taking on the project was that there was no documentation of ANY KIND for the COMPLETELY BESPOKE application. Let me repeat that: The original development company had not created (let alone provided) tech specs, dev logs, user guides or support documentation. At all… Equally, the client hadn’t insisted on them so we can’t lay all the blame on the developers (cowboys though they most certainly were). The end result being that the client paid more, later and it was difficult and slow going to get the new development partner up to speed sufficiently on the application to be able to support it. We therefore thought it a good idea to include, and insist on, a formal support handover process between the developers and their own support desk to ensure that any changes and new features were supportable from the moment they went live.
As an aside, I went to an event organised by the cloud platform provider and the documentation and support handover issue is one faced by pretty much every organisation I spoke to. There was even a well known insurance company who were there doing a presentation on how amazing it was and how they’d used it to deliver all kinds of super-fast prototypes and new applications. I later caught up with one of the service managers for that same insurance company who hated the innovation team because they always chucked stuff over the live fence to them without supporting documentation, training etc.
It is also important to remember that the work going on here was for a large-ish number of small changes, enhancements and new features. It was acknowledged by the business that should a substantial new piece of work be required then the methodology would swing more towards agile with an onsite team and the usual accoutrements.
I would absolutely like to have included more business involvement in all development activities however it was simply off the cards at the time, though we did manage to improve their involvement so perhaps the trend will continue as they see how effective being involved is in getting what they want quickly and in a form that works for them.
The case for Wagile
Clearly, wagile is not going to work for everyone however, there are a handful of pointers I’d keep an eye out for where wagile might work for you:
- Your agile setup is shocking –
If your organisation has adopted agile but has implemented it terribly, you’re probably already introducing wagile elements. Get an agile coach or external audit of your governance and methodology and be prepared to embrace change (a very agile principle).
- You outsource your development –
Unless you have the resourcing need for a full-time set of developers, testers (and rest of solution development team), agile is going to be very difficult to fully adopt. Even if your outsourced development company uses an agile methodology, you are highly likely to need to manage some elements using a wagile approach.
- The business is too small or too busy to commit the time –
Critical to the success of an agile setup – if your business people can’t commit to being involved in their own solutions, they will have to accept what they get. You can help minimise the damage by bringing a little waterfall into how you capture, feedback and commission development.
- Small changes and enhancements –
As is highlighted in the above story, if you’ve only got lots of small changes and new features to deliver, full agile is probably going to add to your overhead rather than reduce it.
- Need for regular progress and delivery –
If you need to restore a little trust in IT, agile is definitely something you can bring into your methodology. More involvement, ownership of the business problem and needs as well as an open and transparent process means that your stakeholders will begin to understand, appreciate and ultimately trust what we in IT deliver.