Using an Agile Approach to Scope Software Projects
Using an Agile Approach to Scope Software Projects
User demands are constantly changing, and thus so are project requirements. Learn how Agile can help you keep up with these changes.
Join the DZone community and get the full member experience.Join For Free
The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
How to Apply Agile Principles to Set Development on the Right Path
Software development methodologies are often religiously observed. But we think you stand to lose out by arbitrarily closing yourself off to alternatives. That being said, when it comes to the software scoping process, the best tool for the job is Agile. Why? Because it’s proven time and time again to provide an effective and efficient framework for propelling new software initiatives forward.
Helastel takes project scoping very seriously indeed and the results of doing that speak for themselves. It boils down to posing the right questions about what the business requires while gaining a 360 degree understanding of user perspectives, to plot a pathway to the optimum end 'product.' Here's why an Agile methodology lends itself so well to supporting that process.
Choice of Software Scoping Methodology Is Crucial
The religious zeal with which some developers and project teams observe one software development methodology over all others can be a questionable practice. By instead employing a horses-for-courses strategy of choosing the best from the broad range of alternatives, organizations stand to gain significantly more than if they blockade the potential value of an innovative or disruptive new approach.
This argument continues to ring true for all projects I'm involved with, except in one crucial area. When it comes to the initial software scoping process — the exercise that aims to plot a successful course for the entire project to follow — Agile is the only show in town, and I'm happy to call myself a zealot for its cause.
What Is Software Scoping?
At its core, good software scoping boils down to a consultative questioning and listening process. This is more than standard client-supplier chitchat, or collecting a documented wish list of demands. It will be intensive and purposeful.
Effective software scoping will:
- Establish the deepest project requirements, both in terms of business need and user expectations.
- Agree on the objectives that will deliver the most meaningful change.
- Lay the groundwork for reducing friction in subsequent development processes.
- Document the critical success factors with outline budget and timescales.
Agile is the best methodology and toolset for software scoping because it has proven time and again to deliver a highly efficient and productive framework for giving software initiatives the correct impetus. This carries through to a universal understanding of project needs both from the outset and as they evolve, plotting the most direct route to the optimum end product.
In a nutshell, an Agile methodology is well suited to supporting that process because it encourages you to establish high-level requirements first, and finer details later.
As soon as an organization acknowledges the need for technology to solve its business challenge(s), the project scoping stopwatch begins.
In the tumult that follows, eagerness to proceed quickly can get the better of even the steadiest of project planners. Striking the right balance is key because nobody wants to risk cutting corners, yet the desire to get on and convert energy and best intentions into tangible activity is often overwhelming.
Agile principles instill a crucial level of discipline at this early stage, supporting the need to complete a full interrogation of project goals, without overburdening the scope with too much unnecessary detail.
Facilitating a Great Engagement
Parallel to the discovery of project scope, which is common to all software development initiatives, this initial stage also represents an important getting to know you time between external software developers/development companies and the clients. It can prove doubly useful to engage all stakeholders in scoping sessions that delve far beyond technology parameters and underlying workflows and into long-term business strategy. Business managers are frequently surprised at the level of detail they are invited to share and are relieved to learn that they aren't expected to be software experts. Great engagements occur when the client feels liberated by this process, and not threatened by hard lines of questioning that examine the reasons behind seeking a solution, and test assumptions that they thought would be blindly accepted at face value.
As stated, none of this exploration need complicate the collation of high-level requirements. An Agile approach facilitates this best of both worlds. It is a flexible, action-oriented means to coaxing high-level needs from the organization without getting the development team bogged down in too much detail before the project delivery phase has even kicked off in earnest.
The drawbacks of a highly detailed initial scope
Electing to fuel-up on highly detailed requirements from the very beginning of a project is to reject the lean, efficient principles of Agile methodology. Drawbacks include:
- Consuming valuable time and unnecessarily creating delay. Compiling exhaustive lists of potential software features at the scoping stage is a classic error that invariably wastes time as specific work items are subsequently canceled or overhauled later in the development process. This amounts to a deferral of key business objectives, slowing the realization of money-saving efficiencies, eroding ROI projections, and even compromising the timely arrival of new revenue-generating products and services to the extent that they lose competitive advantage.
- A disappointing lack of budgetary clarity. The pursuit of detailed work items, fully costed, scheduled, and agreed upon up front, may sound like an accountant's dream, but experienced software development project managers know that delivering on this is a futile endeavor. Developers should be able to use their hard-won experience to produce feasible budgetary expectations, but not so far as to stray from the dynamic virtues of their Agile methodology. Fruitful software projects logically demand an open-minded scoping approach in combination with a certain amount of flexibility.
- The fact that organizations aren't good at knowing what they need. Why bother scoping a project if you already know the result? Part of the value of engaging qualified software developers is the independent advice and consultancy expertise that teases out requirements that organizations never knew they had. Project goalposts move all the time, and no amount of crystal-ball gazing into changing market forces, user tastes, or other factors will alter that fact. Organizations seeking software development know-how need to have faith in the Agile project scoping processes they are led down and learn to operate outside rigid parameters.
Adapting to Change
It may feel counter-intuitive, but embarking on a journey without first knowing every twist and turn of the route is the best way to progress any software project. Change is inevitable and will undermine the best-laid plans. It's far better to be fluid and go with the flow than to constantly revise your expectations in response to rapidly evolving market conditions, new technologies, changes in customer behavior, and other factors.
The good news is that Agile approaches aren't going to box your project scope into a corner like other software development methodologies might.
You know that change is going to happen, so be equipped to capitalize on the opportunities. This is where Agile really steps up to the plate, absorbing the potentially ruinous impact of change by incorporating it at the scoping stage and throughout the rest of the project. On the one hand, Agile stops you from burning your project into tablets of stone, while on the other it minimizes the dreaded project creep.
Preventing Project Creep
Project creep is the seemingly relentless inflation of work requirements that take hold soon after a project has begun. Try as you might to guard against its worst ravages, the optimal way of dealing with it is through effective change control processes.
This is where other, more sequential, software development methodologies fail to cope. A Waterfall approach, for example, is heavily formalized and procedure-driven, rather than truly adaptive. Here, the introduction of change can obstruct the critical path of the project, resulting in delays, duplicated efforts, a drop in team morale, and an abundance of unplanned costs.
An Agile approach, contrastingly, will accommodate change more easily, diminishing the risk of project creep. This is accomplished by:
- Not being distracted beyond the immediate horizon.
- Like-for-like workload swapping.
- Contingency tolerance.
Not Being Distracted Beyond the Immediate Horizon
Agile encourages the development team to have a focused attitude, accepting that future stages yet to commence are critically important but don't yet warrant lots of attention. In fact, a developer's personal understanding of future stages in a project will remain loosely defined for as long as practicable for the very reason that this allows sudden changes to scope to be nondisruptive. This principle cushions the team from the distraction of changing requirements and — dare I say it — fickle clients. The whole enterprise is, therefore, able to leverage the full potential of the latest technology, as well as being fully in tune with market and user needs.
Like-for-Like Workload Swapping
A common occurrence in projects is the last-minute desire to abandon requirement X while simultaneously prioritizing the creation of a new requirement, Y. This adaption of live requirements would be hugely disruptive in a more rigid methodology, putting the project back weeks, but the impact is less so for Agile. The only proviso is that the volumes of endeavor needed to complete the two tasks are broadly equal.
The ability to absorb change and swap out chunks of work has its limits. Sometimes all these Agile-permitted tricks are exhausted and you face the challenge of conjuring time up from nowhere. This problem has inspired the idea of an emergency fund of time that, when all else fails, can be dipped into to deal with genuine curveballs so that project timelines stay on track. Tolerances can be built into each development Sprint and reset accordingly, rather than as a total allowance of time for the whole project which might get eaten up faster than expected.
Applying Agile approaches to undertake software scoping in a structured yet dynamic way leads to high-quality solutions delivered rapidly and closely aligned to business objectives.
That doesn't make it easy to accomplish. Agile is not a methodology that makes software projects entirely easy or straightforward. Measuring the effort equivalence of tasks in advance can be tricky, regardless of how those tasks are prioritized and organized. Assumptions can still creep in, too, along with unexpected challenges — both in the build and the effort it takes to stay on top of Sprints and project management. The benefit of experience and a carefully considered approach are critical success factors.
Right from the beginning, Agile principles can support the process of determining requirements at a high level, leaving unnecessarily granular detail behind. This lays the groundwork for absorbing change positively, without slowing down the project or incurring additional expense.
Scoping software projects the Agile way means developers can concentrate more of their time creating fantastic code, and business stakeholders have peace of mind that their organization is taking full advantage of the latest digital opportunities.
Published at DZone with permission of Christina Lynch . See the original article here.
Opinions expressed by DZone contributors are their own.