Stuck on a delivery method?
There have been many blogs debating the theory of which methodology to choose to run an initiative but few I have seen have considered the practical real life challenges and behaviours which need negating. For example, agile allows you to embrace failure and cut your losses, but explaining to a board you spent two weeks on 3x contract development resource to find out the
requirements have now changed and the feature is not needed is never anyone’s favoured way to spend an hour. So, we have some little tips to help put some perspective on things.
Agile favours experimentation, changing requirements and fast paced environments. Done well, software will be shipped regularly and this pace enables boldness and encourages staff to be confident and creative.
Waterfall has had a bad rep, and it’s true a lot of projects do end up failing. Projects are often shrouded by the time, cost, scope and focus has a tendency to drift to the how rather than the why. For example, you may want to improve customer satisfaction by driving automation, how? by implementing a new billing system. And you will have heard countless times that the importance is getting the product live, but by the time ‘go live’ comes around few people remember what it was meant to do in the first place. But waterfall’s structure has many strengths.
How to decide
The foremost thought you must think of when you want to choose is the people, who’s delivering the product, is it internal resource, contractors or a 3rd party, what delivery method are they used to. Secondly, is the product, is it a commodity, for example, is it a pre-built system which mainly needs configuration rather than development of a new app from the ground up.
The people - Internal and external delivery teams. Using agile with 3rd parties is difficult, as a business you will likely favour fixed price, this is really difficult to align with agile principles,who base work packets on strict time defined sprints. If you’re using in-house resources, it’s easier to digest a 80hrs development time has been wasted by moving requirements rather than adding another X amount of thousands to the project purchase order. You also get the benefit of whatever the development resource has learned over that time will stay with the company.
Tip 1. Internal resource agile is good a choice. But, only choose agile if all parties are familiar with the process and the ground rules are laid out at the beginning. Although a 3rd party might be set-up to deliver in sprints, some of their practices might not follow all agile principles due to constraints of a contractual relationship based on scope and cost.
The product - if you’re creating your own product, by all means go for agile, as mentioned before it favours experimentation and your customers are likely to change their minds and then change their minds back again, so it favours agile. If you’re buying a product, such as a CRM, Billing system, there is little development needed, the scope if fairly clear and fixed then go for a waterfall methodology. Scope if fixed and the majority of the effort is not to get a system to meet the current processes as by accepting a pre-built you are conceding to learning a new set of processes the system was built to carry out.
Tip 2. Starting from scratch, not sure of the end result then, go for agile. But if the end result is a pre-built system Waterfall can be the quickest way.
Waterfall Tip. It doesn’t have to be a big bang, products can still be delivered in piecemeal and don’t fall in the trap of trying to estimate it all up front. Even described in the PRINCE2 handbook, this should be done, phase by phase, when details become clear as the project progresses.
Agile Tip: Not everything has to be agile, since it was created for software development, it can be limited to a software development methodology and the remainder of the initiative can follow a different framework. Additional to this, some of the agile principles can be adopted throughout, getting face to face to between user and deliverer will be advantageous in various situations.
Look at the people and the product, are they internal or external, is it a brand new development or pre-built
Don’t fall in the trap of trying to estimate everything at the start
Mixed methodologies can be used
Regardless of methodology, don't lose sight of the purpose…..benefits, benefits, benefits and repeat.
If you want to find out more about what we do and how we can help contact Jack at