Why does agile fail?

There is more than one company out there that has tried to “go agile” but have ultimately failed and gone away with the impression that “agile just doesn’t work” or “agile’s great but just not for us”.  You also have the situation where you have a company that has been working in an agile manner and then agile breaks down.

So why do people fail to successfully implement agile practices? what are the common reasons that are cited? who is to blame?  In this post I’m going to cover some of the factors I’ve seen that can cause an agile adoption to fail, I’m not going to offer any suggestions on how to combat the various reasons but you could consider this a list of symptoms that could indicate problems if you want to implement agile in your organisation.

Reasons for failure

• Culture – organisation sees no need to change
• Control – management want to control what people do
• Wrong focus - focusing on perceived value of a project plan
• Buy in – people implementing don’t care about the process not invested in what they are doing
• Pseudo experts – people who “believe” they know all about agile when they have limited knowledge
• Clients – fixed term contracts, non-agile customers, square peg round hole

Culture

What makes up the culture of a company? The culture comes from the people who work there, their attitudes towards the work, the processes that they follow day to day and the work that they do; their behaviour at work is driven by what they achieve and how they are treated dependent upon whether they succeed or fail with the tasks they undertake.

An organisation will tend to hire and retain people that want/like to work the way the organisation works this in turn reinforces the culture which has the side effect of making change even more difficult to introduce.

Culture is, IMHO, the biggest cause of failure of agile adoptions, if you are working in an organisation that has a closed mind-set that does not easily accept change or attempt new things you will struggle to get any traction for the agile practices you want to implement even if these practices could very well help the organisation grow and succeed.

In this situation is very unlikely that anything you can do will actually make a difference and nothing short of an epiphany from the higher managers or a company crisis will make the organisation consider the “radical” approaches outlined in agile practices.

Control

In a waterfall based project control usually sits with a manager and/or a project manager which leads to developers being told what task they will work on and sometimes even how long they have to complete it.

When trying to adopt agile this type of control is a direct opposite to practices you want to start using where the developers work out what they can achieve and it is this tension between developer and manager that can cause even existing agile practices to fail.  A developer knows that within the organisation authority sits with the manager and if the manager starts telling them what to work on unless their is a person, or people, able to tell that manager to stop then agile practices can very quickly breakdown.

The role of a Programme/Project manager is a strange dichotomy in that although they usually don’t have any authority over individuals they have ultimate responsibility for successful delivery of a project. This can lead to a desire to actually control what happens on a project which in turn can lead to issues as they try to assert control over what the team does and tell them when they should deliver, again going against agile principles & practices.

Wrong focus

If the organisation is operating in a waterfall manner it believes it can predict the future and can therefore determine every aspect of a project before it begins. This leads to the expectation that any estimates given by the people involved in a project will be hit, effectively making them commitments not estimates, and so create project plans showing milestones and completion dates based on these “estimates”.

This type of organisation tends to focus on the wrong thing as it is more concerned with the project plan, or cost of the project, rather than any perceived value of what is being produced; often it is only at the end of the project when the software is complete that the actual value of that software is considered.

This is the antithesis of agile where it should be about delivery of value to the customer rather than following a plan for the sake of it, striving to ensure that the organisation is, wherever possible, deriving value for the organisation as the project progresses rather than just at the end.

Buy in

Agile is a collaborative effort, you need the developers, managers, PO’s, etc all wanting to work together looking to deliver value to the business, but to achieve this people need to have “brought in” to the concepts and principles behind agile.

If you don’t have this buy in from all the various people involved then your agile implementation may be ultimately doomed to failure. It may well work for 6 months or a year but all it takes is for one or two of the people involved who are passionate about agile to move on and the rot starts and before long the practices are either just being followed cargo cult style with the people who are left not knowing why they are doing something, or they are dropped completely.

Pseudo Experts

A pseudo expert is a person that has worked in a an agile environment before, has attended a talk or read a book on agile, they usually haven’t been deeply involved in all aspects of agile (if any at all) rather they believe they have a deep understanding allowing them to direct others in adoption of agile principle & practices.

However, their limited knowledge of the principles & practices can lead to problems when faced with the normal day-to-day challenges an agile team faces as when the pseudo expert doesn’t have a solution to a problem then at best the “expert” consults their books on what to do or at worst makes it up.

Frequently with the pseudo experts if they have had some success with their agile implementation they develop a closed mind believing that they know all about agile which leads to an inability to change producing a further barrier to being able to actually adopt agile.

Clients

When developing software both internal and external clients usually want to know exactly what they are getting and when they are going to be getting it, it is the classic iron triangle.

For external clients this is a little more understandable as they are paying money to a 3rd party to create software for them; historically in a waterfall project external clients have had very little direct involvement apart from at certain “milestones” so seek to assert more control over the project through the contract which can lead to focusing on the plan rather than the value (wrong focus).  There are very few companies which happily transition from purchasing software with a set deliverable to a situation in which they believe that they may not get all the features/functionality that they want.

Internal clients should be easier to convince that agile will deliver more value for them but if they have to get budget approval for the work to be done then you will often find an internal client acting like an external client and wanting guarantees over what they will have delivered. Whilst frustrating this is more a symptom of a dysfunctional organisation which places more emphasis on cost than value, again the wrong focus, than the actual internal clients.

Summary

These are some of the most common symptoms that I’ve come across and you may see one or more of these in your organisation, if you are unlucky you may see all of them, it doesn’t mean you that your organisation can’t become agile but you need to be prepared to face and overcome these challenges.