Why Agile?

Mon, 17 Mar 2008 11:45:00 GMT

Joe Sanderson’s How much per pound? blog provided excellent inspiration for the topic of this blog. Joe relates how you will benefit by collaborating with us using an agile development methodology. This involves working with us to create user stories that articulate your requirements, in business terms, to ensure that the software we deliver is what you need and expect – something that can be more difficult to accomplish that it might seem!

When it comes down to it, insurance software deals with complex business transactions that involve large amounts of data. This alone is a challenge. From our standpoint, we want to keep our solutions configurable, providing you with the advantage of adaptability without having to ask us to re-work our software to meet changing business needs. Now combine this with the fact the while every insurance company feels that they process information in a “standard” way, every company varies in how they actually process business. As configurable as Phoenix is, we’ve never made a sale in a decade and a half without some modification that was considered essential.

In general, software projects that are deemed failures typically can trace issues back to developers either not understanding the requirements (and building something that the users don’t want) or a project team taking on too much at one time – all in the name of creating a “feature rich” application – with significant cost overruns and buggy code because there is too much added, far too quickly. Imagine working on a project where those writing and testing the software did not have a clear idea of what needed to be built, “everything” is a priority, and there are literally dozens of features to be developed. What do you think the odds of success would be? In the software world, this scenario is played out far too often.

One response to this is to use a rigorous “identify and document everything up front” model, known as the waterfall model. This model requires that one phase cannot start until the previous phase is complete. Requirements must be documented first, then estimates provided so that a full project plan can be created, and then – finally – design, coding and testing can begin. Any changes to the initial requirements and plan are put through an equally rigorous “change control” process.

This sounds rationale, and equates software architecture and design with building a house or office building. The problem is that this analogy is by no means accurate. Unlike building construction, developers are building on top of an ever-changing technical foundation, with ever-changing development tools, all aimed at addressing increasingly complex business issues.

Another harsh reality is that business users cannot always express exactly what they want and how they want it, all up front. It’s far easier to visualize a house or building from a blueprint because we see them every day. Solving new business problems in new ways, typically tailored towards business workflows and preferences, is far more difficult to visualize and agree upon up front.

Given all of this, I’m sure that you can appreciate that it is extremely difficult to pin down how long it will take to build out a specific feature, let alone meet an entire project plan! For developers and testers, it is even more difficult to precisely estimate given that the full business understanding is in someone else’s head.

How does agile address these issues? Agile development is all about inserting those who understands the true business need with the project team charged with delivering the software in a meaningful, participative way. In Joe’s example Susan, the business analyst is assigned to an agile development team to deliver a solution. As part of an agile team, Susan not only will help the team understand what needs to be built, but she will actively be involved with prioritizing the work as well. Prioritization another key tenet of agile development: by focusing on the highest-priority items first, agile development ensures that those items considered to provide the most benefit are delivered as early as possible, with quality.

Agile focuses on delivering working, testable software in very short iterations. This provides some meaningful benefits. In the first place, working software is delivered, providing a solid measure of real progress. Since a stakeholder can see the actual software, changes can be requested for subsequent iterations – agile development acknowledges and embraces this level of interaction. A final benefit is that as a stakeholder, you can decide that at a given iteration the software has delivered enough prioritized features to meet your needs and you can elect not to have the team build out the other, lower-priority features.

More on agile in future blogs…

Dave Moran's Software Development Blog

Why Agile?