AGILE / SCRUM project management is a essential for any larger bespoke project.
Managing and developing larger or bespoke (custom built) applications is only possible with an approach that allows for fluid organic change. Fixed price quotes inevitably fail at a certain project size. Most people know what the WATERFALL / TRADITIONAL / PREDICTIVE approach is but they may not know about the SCRUM / AGILE approach.
Let's compare the fundamentals of these two competing development methodologies:
TRADITIONAL / PREDICTIVE / WATERFALL APPROACH:
- People are familiar with getting a quote with a fixed price and timeframe.
- This approach builds a price around assumptions and unknowns but expects a concrete outcome for a set price.
- Smaller projects with fixed, defined or a well known set of requirements can have some success under Waterfall, but increasingly large bespoke projects attract an increasing failure rate.
- The obscured reality is that the price is really just a guess based on hours or perceived value.
- As unknowns begin to surface mid-project, there is a constant requirement for variations, requotes and often rework.
Some clients expect newly discovered unknowns to be included as in scope which 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).
AGILE / SCRUM APPROACH:
- This approach is more congruent with longer term and bespoke projects, especially those projects which are inventing something new as no product exists that can be bought off the shelf.
- The assumption is that pricing larger projects is an (un)educated guess which cannot be accurately be predicted until the issues and requirements are worked through. This involves actually doing the work.
- As such this approaches fosters a continuous improvement paradigm. Projects can be long, complex, full of unknowns or change direction, but works to improve and evolve over time.
- Projects get 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 over 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 more features.
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.