The Ultimate Fighting Championship was recently in town. I was amused to read an article debating whether Brazilian jiu-jitsu or Muay Thai was the superior martial art technique. While not knowledgeable about the relative merits of varying martial art styles, I am still certain that I know the answer, and that is: both.

The art of determining which strategy to deploy is knowing under what circumstances it works best, and conversely when it is ineffective. This applies equally to software methodology. Beyond the buzz of Agile, there are genuine advantages that it brings to the table. However to really push home the advantage, agile proponents need to be, well, agile. In some situations it pays to blend agile with other approaches.

There are plenty of articles that talk about how to most effectively execute Agile. As such, this discussion does not focus on execution techniques and disciplines, but rather only on the scale of Agile applicability, and whether it should be adapted. It should be noted however that there is no one best technique or execution methodology - it should be agile to respond to the situation.

Appropriateness of strategy

While I generally prefer avoiding an argument in the negative, there are instances where this is easier to do. Below are situations where the benefits of Agile can be compromised.

1. No business sponsorship

For Agile to be effective it is critical that the business is actively involved. A common mistake is to assume this is an IT software methodology that governs only an IT outcome. Agile requires not only business participation, but also business ownership. This does not mean the business needs to start off as experts, but rather a willing disposition to embrace the approach. In fairness this is true for any methodology and goes against project practise, rather than agile.

Compensating factors

Practically none; however there is an opportunity to educate. This does pre-suppose an amenable business community (which would normally spell a willingness to sponsor in the first place).

2. Central command and control environment

Generally Agile works best under a federated autonomous environment where decisions can be made independently and quickly. Many businesses are strong on the empowerment rhetoric; if this does not translate into projects being able to rapidly engage involved business participants empowered to make decisions, benefits associated with Agile are blunted.

Reasons that may cause this can include organisations with little maturity in internal software development, coupled with a lack of flexibility or willingness to change. Suspicions stemming from prior perceived failures can also contribute.

Compensating factors

The benefit of Agile is agility. When key decisions have to be referred back to mother ship for ratification this benefit is denied. The only way this restriction can be compensated is if this is part of the maturation with command and control progressively relaxed. This may happen as a business grows in familiarity and comfort with Agile. Unfortunately often what happens is that the unfamiliarity of early visible artefacts produced by an Agile initiative serve to stimulate even more business concern which in turn promotes even greater instincts of control. Ironically this becomes self-fulfilling in the business concerns are realised, often more because of business response than Agile. In such an environment, stakeholder engagement involving training and expectation management becomes the imperative.

Where this is as a result of prior hangovers any methodology will suffer so change management becomes the key; albeit more pronounced with Agile. Where this does not yield traction, staff rotation is required.

3. Low business maturity and flexibility

This does not refer to the longevity of the business or a lack of industry experience, but rather a lack of maturity in willingly adopting new or unfamiliar practices. Agile takes organisations into unfamiliar territory - the less comfortable a business is in this scenario, the less likely it is to stay its course.

Compensating factors

Change agents can be employed, so long as there is a receptive community. Change agents would typically combat this situation with education, training and the typical arsenal, however this is unlikley to do the trick. Seeing is believing, so the only real difference is experience. Get internal agents from within the business and help them become evangels. Selection is key - they have to be both respected and adaptable.

4. Multiple development locations

One of Agile's mantra is `interaction over process'. For this to be effective there is little room for ambiguity; misinterpretation; and poor communication. Despite modern trends, research has shown that these risk factors are mitigated through worker proximity.

Compensating factors

There are numerous examples where Agile has been successfully employed using multiple development locations, indicating there are effective mechanisms to overcome this. These boil down to 3 factors: communication; communication; and, communication.

5. Well defined business model or problem being solved

Agile is an adaptive model that evolves to meet the need of the environment. As such, it is suited to situations that are dynamic in which functionally rich features can be developed, demonstrated and iteratively amended as needed. These benefits are negated when the solution is well understood by business folk who can adequately describe the requirements that are unlikely to change.

In a waterfall process the controls that relate to predictive management are set to high e.g. up-front analysis and design, pre-planning, documentation, formal delegation etc. In an Agile project the focus is on responsiveness to support incremental delivery and the controls that support this are set to high e.g. check-point development (test-driven implementation), direct communication, collaboration, emergent analysis and design etc. As the Agile process becomes more responsive there is less need for predictive techniques.

Compensating factors

Probably none. While probably rare, if there are static business problems that are well understood, a blend integrating traditional waterfall aspects may well be advised.

6. Large sized development team

With any process that relies on interaction, the larger the points of interaction the more complex and hence potentially more compromised this becomes. Numerous studies have been done on team size thresholds - the number beyond which informal process need to be replaced with formalised and controlled procedures. At this point bureaucracy sets in and agility is compromised. While somewhat arbitrary, my view is that a development team greater than 27 lies in this camp.

Compensating factors

The larger the team the more vital communications become - for example, having multiple daily scrums. However, no matter how much increased verbal interaction attempts to compensate, larger teams may well demand some form of written communication (i.e. the dreaded documentation).

7. Low level skill of developers

For agile to work it relies on the continuous production of software that can be assessed, used, altered, or, indeed discarded. If it is constantly the later and the later is due to low quality development; or, if visible constructs take too long to develop it compromises the value of agile as well as reducing confidence of stakeholders in the methodology to the point that their fears become self-fulfilling.

Compensating factors

There is no getting away from the need of having skilled developers. You will need a least a core group who can buddy up the lesser experienced.

If any one of these situations presents itself it is recommended that Agile is blended to incorporate more traditional approaches, specifically using one of the compensation methods described above. If 3 or more are present, it is questionable whether the balance should be tilted towards more traditional continuum. This is not to say that elements of the discipline such as daily scrums should be sacrificed, but rather that the essence of the approach should be more akin to waterfall. The suggestion appears to be that Agile is absolute with no opportunity to vary it to address the prevailing context. If this were true, the boundaries of applicability would be very narrow. Fortunately it is not. A project can be viewed as a machine, in which requirements (in their many forms) are fed in, and the output is the working system. The project manager has at his disposal a number of controls that can be varied in order to tune the machine and optimise its performance. Some of these are Agile, others less so. Most of all however, be agile