It’s good to keep an open mind about software development methodologies.

However, there is clear evidence that an Agile methodology in particular is most valuable when it comes to the scoping process: the exercise that sets every successful software project into motion.

Project scoping is a real strength of ours at illumo digital. To sum it up, I’d say it’s about asking the right questions of the business need and user expectation to map-out a journey to a fit-for-purpose, viable ‘product’. The process demands more skill than it might appear, but like pretty much anything else to do with business consulting; at the end of the day it’s common sense.

The last thing you want is to get bogged down before you’ve even started

The project scoping process begins as soon as an organisation has identified the need for technology to help overcome its business challenges.

The need to sit down and articulate these challenges, the motivation for seeking a solution, and the various requirements of the company and its software users, is often highly cathartic to a business leader as well as extremely helpful to the development team. All have an understandable eagerness to move swiftly into implementation.

Adopting an Agile approach to scoping takes account of this expediency, but that doesn’t mean that important questions can be overlooked. In any case, there is no benefit to short-circuiting the scoping process altogether.

Agile is a means to efficiently extract high-level needs, rather than immediately detailed requirements, and to formulate a flexible framework for action.

The problems with eliciting highly detailed requirements from the outset are:

• It wastes time. This could be in the form of reams of potential software features that are planned but are eventually discarded as a fuller appreciation of the project context emerges. Wasted time in the development process could mean deferring cost efficiencies or losing competitive advantage.
• It doesn’t help budgetary forecasting. Insisting upon a line-by-line cost summary of software work in advance is no guarantee to getting the software you need, in the timescale you need it. You have to flag serious doubts of the kind of software development company who would enter into a project on this basis, and how long it would take before they dispute their contract or developers become demotivated. Software projects naturally require a certain amount of flexibility, hence the success of Agile methodologies.
• Organisations can’t accurately define what they want upfront. This is the reality of going into a software project with preconceived ideas of the finished product: they will inevitably change in the end. No amount of wisdom, market insight or knowledge of user preferences and behaviour can alter this fact.

Agile means you can never carve a project scope in stone

Starting a journey without knowing the precise route and destination will seem a strange experience, but it’s far better than watching paralysed as your expectation for certainty crumbles before your eyes. Any experienced software developer would urge you to consider: Why on earth would you want to carve a complete project scope in stone from the outset anyway?

Whether its market dynamics, technology opportunities, customer habits or user perceptions – you can count on change happening. This is the guiding principle behind adopting an Agile approach to the scoping process.

Other project methodologies aren’t completely rigid of course. Each invoke change control processes to take account of new requirements. However, these tend to be heavily proceduralised, and obstruct the critical path of the project while every change permutation is determined.

The distinctions are best understood when exploring the dreaded issue of project creep.

Minimise the impact of Project Creep

Nobody wins when project creep sets in. In a sequential methodology like Waterfall, the impact of project creep can be seismic, resulting in unplanned staff costs, project delays and wasted/duplicated effort, not to mention a complete drop in morale.

In Agile, the same inevitable catalysts for project creep have significantly smaller effects.

• Changes to things we haven’t started thinking about yet. Agile promotes a very focused attitude to development, where we accept that the future stages we haven’t arrived at yet don’t warrant a huge amount of detail until they’re next in line. This can be hugely disruptive in other methodologies where every detail has been scoped in advance. With Agile, the organisation has greater flexibility to take advantage of the latest requirements, while developers are protected from any fickleness on the part of the client.
• Like-for-like work swaps. Forget about requirement A and have requirement Z instead? This is potentially a problem in some methodologies, but not in Agile. The caveat is that the work requires roughly the same amount of effort and hasn’t already been completed. Swapping in new requirements for completed ones that nobody wants anymore is still – sadly – a case of project creep. Likewise, swapping something little for something large.
• Contingency allowance. As US Secretary of Defence, Donald Rumsfeld, famously warned the world, “there are known unknowns and there are unknown unknowns”. Agile supports the notion of a contingency ‘fund’ of time available to deal with genuine curveballs, without unnecessarily disrupting the project. Other methodologies don’t.

Agile approaches can be employed to conduct the software scoping process in a methodical yet dynamic way, resulting in the best-aligned solutions and shortest safe delivery times.

From the outset, the trick is avoiding assumptions and tech-talk so that the whole project team can see the woods for the trees and agree the optimum starting point without unnecessary delay.

As the project progresses, its Agile scoping principles ensure that change is absorbed positively. As long as everyone does their jobs correctly, the important focus will remain on meeting business objectives and maintaining high code quality standards. Other than through meticulous documentation, the details of how that all came about won’t really matter.

Download your free ebook –  5 steps to a successful software start-up.

Don’t be one of the 90% of startups that fail. Get funding and get set up right.