AGILE / SCRUM is a project management methodology for any bespoke project.
There are two main drivers behind why this is important:
Involving the client in the strategy, planning, and execution (e.g. design, layout, programming, etc) of every project is critical to them taking some ownership of their projects.
Additionally, software systems constantly face re-factoring and maintenance requirements because the world does not sit still.
web browsers keep evolving
operating systems keep evolving
devices and platforms keep upgrading
ideas and feature requirements keep changing
security requirements need to stay ahead of the game
what is best practice today may be obsolete tomorrow
Let's compare the fundamentals of the two competing methodologies:
What Is WATERFALL (and why it usually fails):
- This is what most people would be familiar with when wanting a quote.
- It pins a proposal around a list of assumptions but expects a concrete outcome
- There is an expectation of a fixed price for that result. The reality is the price is just a guess.
- Smaller projects may have success under Waterfall, but increasingly large bespoke projects attract an increasing failure rate.
- As unknowns begin to surface mid-project, variations and rework are required. Getting more budget approvals scares clients and takes time.
Some clients expect newly surfaced unknowns to be included as in scope. This usually ends in one of the following problematic outcomes:
- a stalemate
- a legal issue
- a loss of overall quality of work (the supplier may try to take shortcuts to recover lost hours).
What Is Agile / SCRUM (and why it is more congruent with longer projects):
- This approach accepts the reality that pricing projects is an educated guess. Price cannot be accurately worked out until the issues and requirements are worked through.
- This framework facilitates a continuous improvement paradigm. Projects can be long, complex, full of unknowns or change direction.
- Projects are broken into bite-sized iterative "sprints". This simplifies progress communication, task accountability, review of delivered requests, new and changed requests, and request priority.
- This means that inevitably new requirements or change requests can be added in as part of a continuous deployment of multiple sprints.
- The cost of a sprint is usually decided up front by the agreed hours per sprint and the sprint length (e.g. a 1-week sprint with 40 hours of labour, 2-week sprint with 40 hours of labour etc).
- Sprint length is meant to be locked down during the build so that agreed priorities can be worked through without interference. Some leeway around this might be mutually agreed.
- All works are recorded on a shared ticket board for audit.
- Fees are paid at the conclusion of each sprint (post retrospective review). The project can continue as long as there is agreement and budget for subsequent sprints.
- The client can pause and continue on a sprint by sprint basis as they need to.
The best way to understand the difference is by this diagram:
Why Choose Us?
Most of our new business clients have been referred to us by happy customers.
Our solutions provide our clients with a peace of mind because we spend the time to understand their business, implement in small steps to deliver value quickly, and protect their systems so they can sleep easy at night.
As a business owner, we also understand that you do not have to be tech savvy to know what you want. We only ask you to talk to us so we can understand your issues and begin to solve them together with you.
So contact us today.