Over the past few years Agile methods have enjoyed increasing popularity; it is clear that Agile development is today hitting the mainstream. Regardless, Agile is proving to be an approach that businesses can leverage to ensure they derive the best business value from their development projects. Agile has polarized the software industry: Many people swear that Agile is the best way to develop software, but there are also many people who say it doesn't work. The truth, of course, falls between the two extremes and depends very much on the situation you are in.

So how do you decide if an Agile development approach is the right choice for you? The best place to start is to look at the problems that can be solved by applying Agile practices, and see how many of them you are experiencing in your organization. The more that apply to you, the more benefit you can realize by transitioning to Agile.

agile addresses common business problems

Based on SPC's experience improving the effectiveness, productivity, and buisiness alignment of hundred's of software organizations, the following common problems can be resolved by adopting Agile methods:

Business needs change faster than development can respond. Many businesses (but not all) operate in markets where the ability to respond to changes in market conditions is critical to success. Getting a leg up on the competition, quickly resolving customer problems, responding to changes in regulations. Agile methodologies structure projects so that working software is delivered in small increments every 2-4 weeks. This provides frequent and regular opportunities for the project team to shift direction when they need to, and minimizes the investment in a lot of upfront work that won't be delivered after all.

Too much time elapsed between initial customer request and delivery of business value. In traditional software development methodologies a fully working system is not available until the end of the development project. While this approach can makes sense from a technical point of view, it can result in several months (or even years) before the system can be used to generate value for the parent business. In Agile development, because the software is maintained in working order each iteration, the delivery of business value is not an all or nothing event. Between iterations, if the business decides that there is enough usable functionality if the current system increment it is entirely feasible to deploy this subset of the total feature set for immediate business use. Business value accumalates earlier, resulting in higher Return on Investment and shorter payback periods.

Systems as delivered fall short of customer needs and/or expectations. Often development projects begin by gathering and documenting the customer's requirements for the system. These may be lengthy textual documents, or complex UML models. Either way it can be difficult to see if they have correctly captured the customer's intent. Then, over several months (or years) the requirements are interpreted by the development team and implemented in software. Typically the system falls short of customer expectations due to innaccuracies in the requirements and erroneous assumptions made by the developers. In contrast, Agile development emphasizes frequent (daily is preferred) interaction between the developers and the customer so that the customer can see what is being developed and correct any misunderstandings or faulty assumptions before they occur. Any problems that actually get into the code can be caught when the software is demoed at the end of each iteration and fixed right away.

Quality problems in released software. Usually this is due to test cycles being squeezed and development rushed because projects try to incorporate last-minute requirements/design changes. In the rush to fit it all in bugs slip through and are not discovered until the software is in production use. Agile addresses this problem in two ways. First, quality is built into the development process. At the end of each 2-4 week iteration all the features implemented is expected to be in usable, working order. Second, incoporating change is an integral part of the Agile planning process, which allows Agile projects to accomodate new demands and adjust commitments based on current business priorities.

Failing to deliver projects as per commitments. A common problem for software teams, that projects frequently take longer or cost more than initially planned. This is also one of the causes of relationship problems between development and the business. It can occur for multiple reasons: the development team is too optimistic in its estimates; risks and other contingencies aren't adequately accounted for in the project plan; requirements aren't clear intially and turn out to be much larger than expected. Agile practices resolves this problem in a planning process that makes commitments based on the measured capacity of the development team. Short term commitments are fixed on an iteration-by-iteration basis. Long term commitments are made based on current information, but are refined continuously (by development and the business together) as new information becomes available.

Strained, arms-length relationships between business and development. A common situation where finger pointing and blame games ensue when project outcomes aren't as desired. This is symptomatic of poor collaboration between development and the business, and often neither party is willing or interested in understanding the other's priorities and problems. Agile hits this one head on! Agile projects are delivered by cross-functional teams in which development and business people work together every day. Developers are expected to understand the business priorities that dictate the content and order of the feature set. Business people are expected to recognize the technical and work capacity constraints the developers are working under. Each party respects the integrity and professionalism of the other. All are pulling together towards a common vision and goals.

How does your situation compare? The more of these problems that apply to you, the more benefit you can realize by transitioning to Agile:

• Deliver business value when it is needed
• Build stronger relationships between development and its business partners
• Implicitly drive development projects by business priorities
• Quickly develop high quality systems
• Provide frequent visibility into project progress
• Heighten team morale and collaboration

Want to know more?

• If you have a thorny business issue or Agile question you need answered fill out our on-line enquiry form.
• If you're unsure if your Agile Development approach is working for you as it should or could -- Take our quick 12-question needs assessment or read up on what you need to do to deliver on the Agile promise.
• If you're unsure if an Agile approach meets your needs, read up on the problems Agile can solve for you.
• To learn more, we encourage you to contact an SPC representative. They understand our services from your perspective. You will get an honest picture without the hype. There's no risk, no obligation, and plenty of ways to see if SPC is right for you.

Our goal is to ensure our clients have the right process, technology and skills to deliver lasting change to their development organization. Discover why SPC is right for you.

get spc working for you

Learn more about how SPC's consulting services can optimize your Agile Development practices.