By David Helme – Digital Transformation and Development Manager.
In an organisation, business departments or clients often identify problems and make recommendations on how to resolve the challenge. Converting those ideas to a working solution that involves IT technology can be challenging for none IT people.
Once a high level solution is identified a business unit is often unsure as how to plan and execute a project, especially an IT project. There are a couple of mainstream approaches to executing such IT projects and they are usually grouped into two categories:
- Waterfall projects
- Agile projects
Waterfall projects are the traditional approach where all requirements gathering is done upfront, a blueprint document is created and given to a team to design, build, test and deploy. This approach is suitable for projects where the requirements do not change and are known upfront, and where the solution must be delivered in a single release. An example of a waterfall project is a payroll solution, or an extreme instance, an air traffic control system.
With the waterfall approach, it is only after all requirements have been built, that the business gets to see any of the results, usually during testing. The issue is that only at this testing phase, which is possibly 6 months into a project, can any feedback be given as to whether the implementation team are on the right track and whether any requirements were overlooked or have changed.
This often results in big delays or project failures. In other words the waterfall approach may be viewed as a large risk and be slow in producing a return on investment, especially if this method is unsuitable for the application trying to be developed.
There are ways to improve the waterfall approach, for example staggering implementation, thus allowing testing and feedback at smaller time intervals. However, this only allows business to see if the implementation team are on the right track after completely implementing a part of the bigger project.
In short there is often not enough interaction between business and the implementation team and the waterfall approach takes too long to have anything to show for the work being done. This is where agile projects come in.
The idea of an agile project is to have very close collaboration between the business and the implementation team, and very small timescales between when the business is able to see progress and give feedback. The general approach is to be able to show business the progress and obtain feedback within one to two weeks. These implementation and feedback cycles are called sprints. This regular communication between the business and the implementation team can quickly help guide the project and make corrections or changes, thus being agile and able to adapt.
If the project is going in the wrong direction, this is known within two weeks and not discovered six months down the line, as is typically the case with waterfall projects. Businesses see the return of their investment quickly and regularly. Because agile is a new approach to some organisations, business users may not be used to the agile methodology and it can be a big mind shift to allow for a successful project.
With the agile approach businesses need to decide what is the minimum viable solution (what the system must deliver as a minimum without all the bells and whistles), and then what additional functionality make sense after that. In other words, get the basics working and being used in a live situation, and then keep adding functionality over time based on user feedback and evolving functionality, in order to meet new business challenges.
Many organisations go wrong when they think that an agile approach means no blueprinting and that requirements are made on the fly as the project progresses. This results in requirements not being thought through and parts of the implementation being redone several times.
The correct approach is to have a general planning session at the start of the project, like a mini blueprint to get the framework and general requirements agreed to, then the exact details gathered every two weeks. So the implementation results are shown every two weeks, then based on the feedback, new requirements are planned and then implemented for the next two weeks.
A waterfall approach to application development is good when the requirements a clearly known upfront, have to be delivered in one phase, don’t change much during the project and don’t require much interaction between the implementation teams and the business.
The agile project methodology is better suited for when rapid feedback and a flexible approach is needed, when requirements are subject to change, or not fully fleshed out. A good analogy is that you want to travel from London to Birmingham (that’s your minimal viable product), but you will decide which transport method you will take, subject to changing travel conditions, as you go. You may start by taking the train, but a strike could cause you to drive part of the way and then catch a bus near the end of your journey. You get to your destination but not the way you had originally thought of.
With the agile methodology, the risk of project failure is far less than using the waterfall approach. Issues are identified much earlier in the implementation phase, allowing for corrections and a faster return on investment. Agile also allows business to “discover” the best solution as the project progresses without the need for expensive change controls. With projects usually taking weeks rather than months, innovation can become part of an organisation’s culture.