An Agile Viability Filter

It’s hot, it’s valid and its promise is without question. Agile project approaches are becoming more popular. The ability to potentially reduce risk and produce business value more quickly makes it an attractive option. Far from a magic elixir however, only certain projects and project environments are suitable for agile methodologies. In fact, the first and most important key to project success is to have an appropriate “business filter” through which projects are evaluated for their “agile suitability.” Here is a guide to creating such a filter for determining which of YOUR projects would benefit from the use of agile processes.

An eager business/sponsor

Any project is doomed without appropriate sponsorship and the willingness to dedicate knowledgeable, savvy people to steward it. Agile methodologies require significant dedication from business experts as well as the technical team. The challenge is that those same business experts are also fully loaded with the day-to-day issues of the business. To be successful, a sustainable balance has to be achieved in order to make time committed to the project a priority. This is critical to agile processes. Project sponsors need to be willing to take critical resources out of the day to day operational world and dedicate them as needed to the project from beginning to end. In addition, sponsors need to be willing to conduct frequent reviews and evaluations of the evolving product. These reviews are an integral part of the agile approach. Without an engaged an agile savvy sponsor, commitment from critical business experts & clients that are eager and able to support and participate in this process, the agile approach will not yield improved results over any other methodology. In fact, without that business commitment, using an agile method will actually make things worse. Risk being the value for the business is delayed, the benefit not fully realised and the overall business confidence in your ability to deliver reduced.

The expert partnership – a pairing of business and technological experts

The agile process is purposefully and richly collaborative. Capitalising on the nature of a highly iterative development process, enable an organization to quickly try out new and untested business process. Another benefit of an agile approach is it can help an organization bring functionality to fruition quickly and effectively. This quick and effective approach does not come without costs however. Those impacts fall in the area of the time involved by business experts working extensively with expert technical team members. Here’s why that is so vital…

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 constantly and consistently reassess the “product” of the project. This is a delicate balance between the business needs at a micro-level, and the priority of the functionality needed by the end customer. In addition, they are responsible for the business integration of new functions into previously developed pieces of work. The bottom line is that business value comes about more quickly due to a well coordinated effort between technical team members who are dedicated to the project tasks and integrating the solution quickly, working in concert with business team members who are equally dedicated. As a team, the expert 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 more traditional “waterfall” project lifecycles. These highly capable pairings of business and technical people are key – if they are not appropriately knowledgeable and available for the duration of the project, the premise of utilising agile methods fails to deliver.

The need for speed – and end users to benefit from it!

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 can be incorporated into the project’s product. Agile approaches consistently involve adding pieces of functionality to a solution in short “sprints”. Then quickly testing and integrating that functionality into the cumulative solution. Long periods of time between installation and evaluation create many drawbacks; the value-add of agile techniques are then diminished. As the business and technical experts rapidly move from function to function, the best results come from adjustments and improvements that can be identified quickly and put into the product before the team moves on to other areas of the project. In addition, longer periods of time between functional production and assessment of those functions add considerable amounts of complicated testing – adding time and risk to the Agile approach. Agile works best when products can be thoroughly assessed quickly after functionality is produced.

A commitment from management for the duration of the project

A very common management mantra is “begin with the end in mind.” When it comes to agile projects that is a good thinking, especially for management. Earlier, we discussed the need to have a consistent expert partnership for the duration of the project. Just as important is having management with a consistent vision, providing support and endorsing the products being produced by the project team. Changes to direction or an overall vision by sponsoring management can totally derail the entire premise for engaging in an agile project in the first place. Before committing to support an agile project, key management stakeholders and sponsor(s) should evaluate their current and future commitments. If a single person cannot serve as a sponsor continuously, multiple key stakeholders can support and drive the project, however they should work diligently to ensure they are all focused on the same objectives and will not provide conflicting direction to the project team

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 tasks 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 envisioned functionality envisioned early on may not be produced at all in deference to other business items that may be deemed more important. 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.