<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=266211600481844&amp;ev=PageView&amp;noscript=1">

Do Agile Projects for Custom Software Cost More?

Oct 7, 2014 custom software Dennis Junk

Scrum_imageWhen people first hear how agile methodologies for IT projects work, they assume it boils down to prioritizing custom functionality over budget and scheduling concerns. In other words, they think you have to pay a lot more and wait a lot longer if you want to make sure your technology solution works exactly the way you want it to. But this thinking fails to take into account the complexity and unpredictability of IT projects. According to a 2010 survey by the Standish Group, 24% of IT projects are either cancelled before completion or result in solutions that are never used; 44% go over budget, past deadline, or don’t work properly; and only 32% succeed. 

Agile methodologies like Scrum are designed, not just to create highly customized solutions, but mainly to avoid all the most common issues leading to project failure. When you factor in the cost of failed projects multiplied by the rate of failure, you can see why agile is really the most cost-effective strategy (assuming it’s used correctly).

The Scrum Methodology 

Scrum is the most effective and most widely used agile methodology for custom software development. A 2012 survey by Gartner Research showed that one of the biggest factors behind project failure is the size of the project. This makes sense because the bigger and more complex a project is the harder it is to anticipate obstacles and complications. What Scrum does is break projects down into more manageable units called sprints, each of which will be undertaken by a small, focused team working on a fixed timescale (usually two weeks). These teams aim to have a deliverable at the end of each sprint. So, instead of one big and unwieldy project taken on by a huge number of developers, you have small teams working on well-defined tasks. If something goes wrong or needs to be adjusted, the damage is limited to one of these smaller units of the overall project. 

Traditional methodologies rely heavily on upfront requirements-gathering. The resulting requirements document then becomes the basis for the design, which in turn informs all the development phases. What this means is that the project team members using these older methods only interact with stakeholders and end users twice, at the kickoff and delivery stages, and the project gets tackled in one concentrated push. Scrum, on the other hand, is much more collaborative and proceeds through multiple iterations.

Providing an Estimate 

Agile Discovery is the initial process of meeting with project stakeholders to develop a vision of what all the application needs to be able to do. In other words, this is when all the application’s features are laid out.

Sizing involves assigning points to each of the application’s features based on the complexity, risk, and effort it will take to develop. A ballpark estimate is created based on the total points assigned for the product’s feature list. This ballpark includes the projected number of sprints it will take to create the product (based on the resources that are anticipated to be assigned to the team).

Business leaders may be reluctant to sign off on a project based on a ballpark estimate, fearing that the parameters could end up shifting and the application could thus end up costing much more than expected. But with Scrum you’re only signing a contract for each sprint, which means you’ll be able to keep a close eye on how the project is progressing—and you can call it to a halt if things start getting out of control.   

A General Overview of Scrum

There’s a lot more to agile methodology, and Scrum in particular, than can be condensed into a single blog post. But here are some of the key elements:

User stories emerge out of the Agile Discovery phase and the discussion of the features the application needs to have. The stories are hypothetical scenarios describing how the new technology will be used in a real work setting. At the beginning of the project, stakeholders and end users come up with a story for each function and role that the solution will eventually incorporate. 

The discovery will result in a Product Backlog, which is comprised of all the user stories and serves as a working plan for the project.

Planning Meetings bring the developers and the stakeholders from the client company together to prioritize user stories, create sprint backlogs, and define acceptance criteria for the features developed in each sprint. 

Sprint Review Meetings occur after the developers have executed the sprints, and they involve demos of the progress made during each sprint. This gives stakeholders the opportunity to provide feedback on the individual elements of the project, and that feedback gets incorporated into ongoing revisions to the Product Backlog. 

Then the steps are repeated: a new sprint backlog is created and executed, more reviews take place, and feedback is incorporated. The key point here is that the product is delivered for evaluation throughout the process. Since the later sprints build on the success of the ones that come before them, this approach offers multiple opportunities for stakeholders to test and provide feedback on the various parts of the project, so any issues can be identified before all the effort that goes into the later stages is wasted.

Scrum relies on collaboration and iteration to ensure that the solution that ultimately gets delivered is aligned with what the stakeholders envisioned. Scrum is effective because it takes into account how difficult it is to know and describe exactly what you want unless you have a chance to see something that’s close to what you want but not quite it. By drastically reducing the likelihood that the project will result in a solution that doesn’t work or doesn’t get used, Scrum, if applied correctly, actually saves many businesses money.

But the most important way that Scrum ends up controlling costs is that it breaks down large, complex projects into manageable units. Unforeseen complications are easily contained, can be addressed early, and thus have limited impact on the rest of the project. In this way, the potential for the project to descend into chaos—going over budget, past deadline, or resulting in an unusable product—is brought under control.

The bottom line is that if agile methodologies like Scrum are applied properly, projects have a good chance of costing less than they would if you were using other methods.   

Choosing a Custom Software Vendor in the Age of Scrum

Posted in: custom software

Topics: custom software