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

Function heads have a complex agenda: multiple business customers; demonstrating the value-add function of your area to supported units; the need to continuously evolve and align to dynamic and fast changing business strategies ; the ongoing scrutiny of costs; and, ongoing judgment of the delivery.

The exclusion zone

Perhaps an overplayed term, but each business has a DNA that should not be tampered with. Functions and areas that are critical to the execution of a business model are generally not good candidates suitable for external sourcing. While these are obvious, unfortunately business is seldom binary in right and wrong decisions. Rather it is typically complex play a multitude of factors such as managing trade-offs; timing; environmental factors; and business culture.

The grey zone

Upon reflection, many executives are surprised how crucial certain functions are to the value-add of a business. For example, mortgage origination processing has often appeared to be an obvious candidate given its appearance of process uniformity; common processes and industry standards; fluctuating volumes and scale benefits; and, guise of being a large back office function. While this is all valid, consider the trade-offs associated with such a move. You lose control over a function that if it goes wrong can result in material credit, operational and reputational risk. Credit risk may appear to be the greatest exposure, however a combination of controls and commercial agreements (supplier and third party) can usually mitigate against this. Operational and reputational risks however are thornier. Mortgage origination issues can quickly escalate beyond customer grievances. Systemic issues can draw the eye of regulators and competitors; incur breach costs; and, result in expensive recovery costs.

This is not to say that outsourcing such functions should be avoided, but rather to suggest a proceed with caution approach, ensuring appropriate controls are in place. Additionally, certain selective functions may well be conducive to outsourcing within an overall value-add process.

Contender attributes and considerations

There are a number of scenarios in which external service provision may make sense.

A business may be able to gain access to scale economies that are not possible given the extent of internal operations. The consideration is that your business will become one of many clients and as such leverage over the supplier becomes relative.

You may identify areas of specialist expertise that you require to execute your programme, the demand for which is one-off or unpredictable. External service providers can provide access to this specialist skill, but ensure that you are an important enough client to be able to procure the true experts when you need them.

You may also want to outsource activities that are routine or commodity, so as to concentrate your scarce resources on higher-value add activities. The danger here is that you outsource a commodity skill today that becomes a valuable skill tomorrow. Ensure that you have adequately considered alternative future scenarios before you make such a move.

Do the numbers

As an extension to the scale, specialist or focus opportunities listed above, a business may be able to yield a lower service cost proposition through outsourcing. Given the trade-offs, the business needs to be rock solid. When factoring in costs, it is important to look at the total cost of the transaction in addition to the direct costs. Broadly this includes:

• The business impact costs associated with any top line turnover dent due to outsourcing
• The transition cost as no successful outsourcing function occurs over night
• Management overhead in establishing and maintaining the arrangement
• Peripheral support costs such as legal

Doing it!

In order to drive true benefit from an external relationship, you need to have a solid understanding of the area to be outsourced. Where a poorly understood problem area is resourced away, the power lies squarely with the service provider and the likelihood of benefits being passed on is lessened.

Factor set-up costs into the case for sourcing. Often a resource-intensive exercise is required to clean your data, develop interfaces, and design processes and procedures so that the external provider can deliver an efficient service.

If these processes are not well constructed, the overhead in managing the provider will increase, with detrimental impacts on responsiveness. You should not expect benefits to flow immediately.

Finally, maintain functional ownership Outsourcing of a function does not abdicate responsibility of performance. This seems obvious, but how often have you heard quality problems being blamed on the supplier?