Following 1000’s of hours of time invested in discovering what does and doesn’t work to reduce risk in software projects and I wanted to consolidate our findings in to a short blog post in the hope that I would save others the same pain. This post also touches on agile, however it’s important to understand that an agile approach to software development highlights project management issues – it does not resolve them.
Before diving in to advocate Agile software development, let’s review a traditional method of project management unwittingly requested by most of Atlas’ customers – Waterfall.
Waterfall as an approach to project management isn’t unique in the world of software development; the Waterfall methodology was established in the 50’s and is used successfully across a range of industries including the military, space development and health care. Such industries are tightly controlled, regulated environments where decisions are made by experts and people’s lives depend on decisions being right first time. There isn’t a great deal of “Whoops, that didn’t work – hide the dead bodies and let’s try this another way”.
This diagram provides an excellent visual of a typical Waterfall project. Notice that it’s impossible to return to the start once implementation begins, and herein lies the ultimate problem with waterfall. The majority of the application development projects undertaken in 2012 will be started, and funded, by people who do not understand the complexities involved in writing software and do not know all of their requirements upfront. No matter how many software requirement gathering techniques we use to extract software requirements, if the product owner doesn’t know what they don’t know, they cannot provide the correct information. This is not their fault, it’s just a fact.
So let’s imagine that the software development team ignores the above issues because the customer is waving a big fat cheque book at them. They gather requirements as best they can and hurl themselves down the waterfall using a functional specification the size of a bible as a floating device. The customer is stood by the waterfall watching and she’s hyped. She’s positive that between them they’ve nailed down all the requirements and then BOOM, they hit the bottom of the waterfall and begin to drown. Turns out the functional specification had holes in it, and no amount of paddling is going to help. Furthermore the customer has seen a preview of the application and they have a bunch of changes they wish to make.
With the pressure of a fixed deadline, and fixed budget too, the development team now find themselves having to paddle harder to meet the deadline. They produce a sub-optimal application that exactly meets the customer’s specification but could have been so much better if only a more iterative approach had been taken.
So agile, that’s the way forward right? Well agile is equally as dangerous if not carried out properly, and certainly isn’t a panacea to all of the problems outlined here. To work properly agile still requires an overall plan, and plans for each iteration must still be laid down before development begins. An agile development methodology does ensure that software development is a collaboration effort and shares the risk across both parties more evenly. In other words, the software development team may still hurl themselves down the river but in this instance the customer is in the boat helping to paddle.
We transitioned the majority of our projects from waterfall to agile in 2011 and I intend to ensure that where possible we use agile going forward. I’ll go in to more detail about how we handle planning for agile in a separate blog post but in the meantime here’s a number of agile tips and tricks we’ve used to ensure that all of our projects regardless of size and risk stand the best chance of being delivered on time and on budget:
- If we’re approached by a customer who wishes to create an application and this is their first web application or they’re entering a new industry I strongly recommend that they create a minimum viable product first. Trying to create an application with all manner of bells and whistles is unnecessarily expensive, and usually a disaster in the making.
- On occasion I recommend the creation of a proof of concept. This is especially useful if one or more areas of the overall application requirement are high risk due to technical complexity or reliance on a third party system.
- On from point 2; if we do create a proof of concept we show it to as many people as humanly possible before continuing. If the application is internal, show it to your staff. If you’re looking to sell the application, show it to as many of your potential customers as possible before proceeding. Yes this takes time, yes this feel onerous, but it’s less expensive to discover early on that you’re heading down the wrong path.
- If a proof of concept is overkill, I always recommend that we create wireframes (Balsamiq is our tool of choice unless a HTML prototype makes more sense). Even the most simple wireframes will ignite a product owner’s imagination and make them think about detail they might previously have overlooked. Given that a picture says a 1000 words I make sure that wireframes form the part of our iteration plans as they are difficult to misinterpret and therefore minimise ambiguity.
- We use our client portal to aid transparency. In particular I make sure that customers can track what we’re working on as part of the current iteration. We add any potential issues to the portal for discussion as soon as we encounter them rather than waiting for the next meeting.
- Speaking of meetings – we insist that the key product stakeholders attend all end of sprint meetings to provide feedback. We’re so adamant about this point that we include this requirement in our agile development contract.
- We won’t ever get bogged down in onerous contractual discussions. Software development is a collaborative effort with shared risks and our software development agreement reflects this approach. Rather than discussing contracts in detail I’d much rather focus on getting your application built.
With or without agile the above techniques have saved us 1000’s hours of wasted development. Please feel free to comment below with any other approaches you’ve used to keep your project afloat.