The Risks In Agile Development

In software, we rarely have meaningful requirements. Even if we do, the only measure of success that matters is whether our solution solves the customer’s shifting idea of what their problem is.

There has been some confusion with what agile actually is. It is often referred to as a methodology, whereas, as conceived back in the late 90s and brought to fruition in the Snowbird meeting in 2001, it is a set of values or principles.These principles are straightforward, four of which are:

• The highest priority being to satisfy the customer through early and continuous delivery of valuable software
• Welcoming changing requirements and harnessing change for the customer’s competitive advantage
• Deliver working software frequently, from a couple of weeks, to a couple of months, with a preference to the shorter timescale
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done

Is Agile implementation Agile enough?

However concept is invariably easier than delivery, and a way of translating the concepts into concrete deliverables has proved to be challenging. In the real world, procedures and frameworks are often put in place to make the concept deliverable, but the question remains, and here is the first risk; have the values been lost in the implementation?

It has been suggested by Dave Thomas (founding director of the Agile Alliance), Jurriaan Kamer (founder of Agile CIO) et al. that agile has departed from its original concept: Kamer argues that agile is being used as a panacea and with a pre-existing mindset of a need to exert control over processes. It is difficult for organisations to resist the comfortable mindset of measurable outcomes which can be managed; comfort comes from a stable platform and efficiency. For them change is to be avoided, but it is clear that welcoming changing requirements and harnessing change is one of the most important agile principles. The real agile organisations are those that are constantly changing. Kamer argues that in order to become really agile a suitable environment should be initiated by the organisation so that individuals, who are trusted with autonomous action, can thrive and reach full potential. He considers that this does not just apply to Scrum but to the wider organisational structure including budgeting, governance etc.

Agile is about managing uncertainty through learning and discovery, not by trying to predict. It is a movement of the thought process away from a top down model such as ‘Waterfall’ where everyone works through a set sequence towards the outcome in defined hierarchical roles, to exactly the reverse where the outcome is in the realms of uncertainty, and uncertainty is embraced. The answer to the natural question - how can you manage uncertainty is that it is managed by experimentation.

some common risks in implementation

There is an argument that with agile processes like Scrum and XP, once you have defined the processes you have limited your agility. In order for agile to work, the concept has to be taken on board rather than unthinking obedience to the ‘accepted’ methodologies such as Scrum. Implemented properly Scrum can, and has, worked as a methodology. But that is not to say that its blind implementation is agile. Agile in its true form is quite a concept to grasp, and people are often not given the time or training necessary to take it all on board, which is the second risk.

A third risk can be seen in a number of companies where the standard process of ‘so called’ agile adoption becomes a model where ‘agile’ is really a wrapper for a hybrid Waterfall/Scrum. Here agile iteration takes place, in Scrum, in the analysis/development/testing part of the organisation, but before this happens Waterfall kicks in. This produces a top-down workflow of a budget proposal, estimates of cost and time scales, then the system and software design, implementation and unit testing, integration and system testing then has to take place before going out to users. The users may then find that it wasn’t what they wanted in the first place. The whole process can take an inordinate length of time before you get to the point where you find that the idea you had at the beginning wasn’t the right idea.

A fourth risk is delayed delivery. One of the problems in organisations is delivery times; when important parts of the product have to wait for less important parts in order to be batched up together. This slows delivery time and adds to project cost. The agile solution is small batches which makes for quick response times. As Jez Humble (co-author of Continuous Delivery) says, working in smaller batches can change the economics of the software delivery process and create short feedback loops which enables quality to be built in. This also produces continuous delivery, and with continuous delivery you get rid of the Waterfall baggage.

Small is beautiful

The agile solution is a lean approach where waste is minimised so that changes can be made without massive financial implications to the development company. The agile way is to take small steps to your goal. As Dave Thomas sums it up; if you want to be agile you only have to do three things and then loop. The first thing is to understand where you are, the second thing is to take a small step to where you want to be, and the third thing is to evaluate what happened; and then you continuously repeat the process. In order to make the small step easily reversible you have to chose a path which can easily be reversed. Therefore when faced with choices of roughly the same value chose the one that makes future change easier.

The Agile Way

 If you want to employ agile values and principles you must have goals which are easily measurable, and then take an experimental approach to achieving those goals. Start with an intermediate goal or goals and try different approaches to reach them. If a few of those approaches don’t work, not too much time and effort have been wasted, but if you succeed you can take the next step. This incremental approach equates to an agile mindset of using change. For this to work people have to be given autonomy to work their way to the next step. This is totally different to the Waterfall culture where small parts of the overall goal are broken down and assigned to people. Then those people bring their bits and try to make it all fit together.

To make agile work on processes you have to take an experimental approach to process improvement, and keep trying to improve.