To Agile or Not to Agile

Written by Bob McGannon on September 4, 2012. Posted in Articles.

It’s hot, it’s valid and its promise is without question. Agile project approaches are becoming more popular because of the ability to reduce risk (in some cases), and produce business value more quickly. Far from a magic elixir however, only certain projects and project environments are suitable for Agile methodologies. In fact, the first and primary means of success is to have an appropriate “filter” through which projects are evaluated for their “Agile suitability.” Here is a guide to creating an appropriate filter for determining which projects would benefit from the use of Agile processes.

An eager sponsor

Any project is doomed without appropriate sponsorship. Agile projects however present additional opportunities for peril should a sponsor be disengaged in the process.
Agile methodologies require significant dedication from the end customer community as well as the technical team. Time commitments and prioritization of project activities against operational responsibilities for knowledgeable members of the business community are paramount to Agile processes. Sponsors need to be willing to conduct frequent reviews and evaluations of the evolving product that are an integral part of the Agile approach to project management and Agile product development. Without a sponsor that is eager and able to support and participate in this process, the Agile approach will not yield improved results over any other methodology.

An ambitious, knowledgeable and available business representative(s)

The Agile process is purposefully collaborative. Through the nature of the technical development exercise, the development of tools to enable an untested business process, or both, Agile approaches can help an organization bring functionality to fruition quickly and effectively. This quick and effective approach does not come without impacts however. Those impacts fall in the area of the time involved by people who have business experience (and are usually pivotal in the execution of day-to-day operational processes) working extensively with the project’s technical team members.

The primary characteristic that makes Agile methodologies…well…agile…is the methodology is designed to be responsive to immediate and/or evolving needs. Knowledgeable business people need to consistently reassess the product of the project, the business needs at a micro-level, the priority of the functionality needed by the end customer, and are responsible for the business integration of functions into previously developed pieces of work. The bottom line is that the business value comes about more quickly due to a well coordinated effort between technical team members dedicated to the project tasks, working in concert with business team members who are equally dedicated. As a team, the business and technical project members enable the frequent adjustments and evaluations required to develop a product without the pre-requisite documentation and analysis that is customarily performed in “waterfall” project lifecycles. Business people are key – if they are not available and appropriately dedicated and knowledgeable, the premise of utilizing Agile methods fails to deliver.

Minimal time to verify product viability

Agile’s power comes from its ability to produce quickly, adjust consistently to new knowledge and business change, and to accommodate those needed adjustments into the product of the project. Those learnings however only add power to the Agile process when they can be understood, interpreted and absorbed quickly, so they may be incorporated into the project’s product. If the project being considered for Agile methodologies involves a product that will not be used or easily assessed by experienced customer personnel within a short period of time from when it is first developed and put forth for assessment, a base premise for using Agile goes unfulfilled. Agile approaches consistently involve adding pieces of functionality to a solution in short “sprints”; and then testing and integrating that functionality into the cumulative solution. Long periods of time between installation and evaluation would create many drawbacks and the value-add of Agile techniques are then diminished. As the technical team rapidly moves from function to function, the best results come from adjustments and improvements that can be identified quickly and put into the product before technical and business personnel move on to other areas of the project portfolio. In addition, longer periods of time between functional production and assessment of those functions would add considerable amounts of complicated regression testing – adding time and risk to the Agile approach. Agile works best when products can be thoroughly assessed quickly after functionality is produced.

Minimal business exposure if the product produced is broken

Given the appropriate conditions, Agile is extremely effective in the creation of business functionality in a rapid manner. However, as part of this rapid deployment, the Agile team strives to perform the minimal amount of analysis needed to perform any sprint. Given this, it would be high risk to put a piece of functionality into a production environment for rapid integration and analysis if an error in that product would have a substantial impact or would create a “domino effect” of obstacles for the operational business. The nature of Agile, with its tightly integrated knowledge work between technical and business personnel does not present a high risk of creating error-prone products (no more than other methodologies). However, the rapid change with which a product is altered as new functionality is added to Agile products can present business challenges to end users if not appropriately assessed ahead of time.

A willingness to consider a very different approach

Agile is highly iterative, progressively adding pieces to a whole solution. The process involves working through plans for the current “sprint” of functionality production, as well as creating high level plans for the next sprint. Beyond that the plans are only loosely outlined, as a means of maximizing the flexibility of solution development. This is a difficult concept to accept for those in the management team that are expecting to see – and direct – a planning process featuring a Gantt chart which shows what is going to be produced via milestones and by task, over the next 6 to 12 months. Flexibility and the ability to invest in a different work and management approach is necessary for project stakeholders when Agile methods are being considered.

The “DNA” to deal with a bit of ambiguity

As discussed in the prior item, the Agile planning process is an intense rolling wave approach. As priorities are consistently assessed during the course of the project, pieces of functionality may be created and integrated in a different order than originally envisioned. In fact, some pieces of originally envisioned functionality may not be produced at all in deference to other business items that may be deemed more important since the original functions were outlined. Agile actually embraces this flexibility and responsiveness – those desiring a highly linear methodical set of objectives produced in tune with a pre-conceived schedule need not apply.

Agile is smart, savvy and responsive – but it is not a universally applicable approach to satisfying business and certain stakeholder needs. The most successful incorporations of Agile methods into organizations are done with a good up front filter, which includes assessments of the items discussed here, to maximize the probability of success in producing products with an Agile approach.

Don’t forget to leave your comments below.