I wanted to write about some of the ways application development has changed over the years. In this first article, I will cover the phasing of application development against more traditional delivery approaches such as waterfall and agile. It covers the reasons why you and your application development effort should be adopting a phased approach too and I will follow up with more articles on refining this approach.
There is nothing actually wrong with the waterfall or agile approaches if you have the right environment to make them work. This article is about how to get the requestor’s input during a traditional waterfall project by introducing phases to the overall project. This approach could be used for other types of project and not just application development.
Traditional application development
Anyone that has been involved in application development over the years will no doubt have encountered the waterfall approach where you gather requirements up front and get a product at the end. It is called waterfall as the project will go through several stages but each stage will not commence until the previous stage is finished and signed off.
A lot of teams tried agile development, where you work closely with all stakeholder’s in a project, including the requestor, on a daily basis. It needs a lot of commitment from the requestor getting involved on a daily basis throughout the project. Agile requires that the requestor is part of the ongoing development team for the complete duration of the project. However, that usually it is impractical as the requestor usually has their own job to worry about. It requires the right personalities within the development team that are very experienced in their field and can communicate articulately and briefly.
Traditionally (under the waterfall approach), creating a new application would be a six month or longer project. All of the requirements would be gathered up front, written up and signed off by the requestor. Then these would be converted to a technical specification and given over to a team of programmers. They would work on it for several months and pass on to the internal system tester(s) who would report back all the things they found incorrect. The programming team would then make those corrections and the tester(s) would confirm that the corrections were made (let us ignore that new bugs might then get introduced as I will save Software Testing for another day). The application will then enter the user acceptance testing phase, where the requestor gets to see for the first time what has taken 6 months or more to deliver.
Here’s a diagram showing the stages of the traditional waterfall approach. Quite often this becomes iterative waterfall, for example after release you set about on the analysis for the next version (to fix all the things you got wrong the first time around or make the improvements to the system after the customer has a chance to see it).
OK, let us say that it took 6 months although from experience this could easily have been a year or two for large projects. There is a lot that can happen in 6 months on both sides of the fence. The requestor may not have the same requirements at the end of the project that they did at the start. Business priorities, people, structure and legislation could change within 6 months meaning what is actually delivered may be redundant or it might not be completely relevant to today’s business (even if it is still required).
On the application development side, all of the people involved in producing the application will be making decisions based on their interpretations of the requirements without checking back with the requestor. OK, you may argue that if you had the requestor to call upon for every decision then this wouldn’t need to change but the requestor is usually very busy with their day job and are not going to be available every time you want to make a decision unless you pre-book their time.
Phased waterfall approach
What you can do is get both requestor and customer feedback much earlier in the development by using a phased approach. All projects are split into monthly phases and each phase will have something tangible at the end. This needs to be something that can be checked and signed off by the requestor as it’s usually the only way that a requestor can determine progress and make sure the development effort is on the right track. When I say monthly phases, that should be what you are aiming for but maybe a first phase could be six weeks as there is usually a fair amount of structural work in the first phase.
So how do we take six months or more of application development and split that up into 6 or more phases. That’s what we will cover next but I would like to point out that just because each phase requires something tangible at the end of it, it may not be have to actually go through the release cycle and out to customers. Great if it can as you can gather some good feedback that you can include in subsequent phases but quite often in the early phases you will not have enough built to make it useful and it might actually give the wrong impression to potential customers if you haven’t got most of it right first time.
The following diagram shows the phased approach going through 6 mini-waterfall phases, each approximately a month from start to finish. Using this approach you are getting 6 times as much feedback and as the project evolves it will be more accurately reflect the requestor’s vision.
Actually, that diagram doesn’t really do it justice because each of these mini-waterfalls can overlap. The analysis and design for one phase can take place whilst the previous phase is being developed or tested. By overlapping the phases you will deliver what the requestor wants in less time.
Regardless of whether you overlap phases or not, the first thing to do is to break your whole development project into functionality parts and get these prioritised by the requestor. Some people find “user stories” or “use cases” useful for these but a short description of what the functionality will deliver is all that is really required. Remember to include any background work or structural functionality that the requestor may be unaware of.
These descriptions should ideally be one or two sentences and definitely no more than three. If you have too much description then it probably means that you haven’t split that functionality down enough. The smaller that you can make an item of functionality the better chance you will have at estimating how much development effort it will require. I feel an example will be useful here but it is better suited to dividing project functionality and prioritising and that will be covered separately in another article.
The most important benefit to dividing the project up into phases is that by getting feedback throughout the project several times each month you refine the deliverables to suit changing circumstances. Something is bound to change on the requestor’s side during the development if they have to wait six months or a year for a deliverable.