The background

I’ve been working under the agile principles during the last 4-5 years. I was used to work under the waterfall principles and methodologies, so I must admit that at the beginning it wasn’t easy. It was quite hard to forget about long-term plans, detailed designs and organizational hierarchies, however after a few time I discovered some enlightening facts that made me love the four agile principles from the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

In fact, during this time I’ve been in several situations in which I’ve been able to apply both side of every principle and undoubtedly I’d rather the agile way. However, I only have a narrow view of the world’s overall software development state. So I’ve thought that maybe the agile way is not the panacea, that’s why I decided to do some research on the agile success ratio.

The reality

Once I convinced myself that perhaps agile was not so cool and good as it seemed to be I started digging into the Internet looking for some references. After a few searches I reached some interesting articles like the following:

• Agile theory vs practice
• 8 reasons why agile projects fail
• 12 failure modes agile transformation
• 5 reasons why agile fails and how to fix it

In fact, it’s a list of 20+ reasons why agile fail, and many of them come from some of the software market renowned sources like Thoughtworks, so I thought that maybe agile was not so great as I experienced. Moreover, if one does a deeper analysis it is easy to detect some common patterns on agile failure:

• Fail by people: In this pattern agile fails because of the people. Perhaps our people is not properly trained to embrace agile or maybe we have some reluctant members in our teams, whatever the case may we are not ready to embrace agile and this is difficult to solve meanwhile we have a project in hands.
• Fail by organization: This is the next level of failure. In this case our people is somehow prepared but, the company environment is not. Maybe the top management does not promote agile (or at least tolerate its existence) or perhaps our organization structure is not agile friendly (physically dispersed team members, non-agile company values, etc), in any of these cases we shall remove these obstacles before starting a real project with agile, or the success of the project will be affected.
• Fail by communication: This is the third level of failure. Once we have removed the people and organization obstacles we are able to start being agile but, what happens if we are not ready to communicate with our team members in an adequate manner? On the other hand, what will happen if we or our customer is not prepared to work in a continuous flow of feedback? Both situations will negatively impact the success of our agile transformation.

By the way, I think there are a couple of situations that must be considered when we talk about agile failure:

• Fail by contract: The first extra bonus level of the failure (and the more obscure). From my point of view, this failure mainly applies when agile is used to deliver a service instead of a product so, what will happen if everybody is ready to embrace agile, our organization is also prepared and all the stakeholders are willing to be agile but we haven’t checked our contracts? Maybe everything ends fine but if something goes wrong everybody will be checking the agreed contracts in order to decide who pays the bills and, arrived to this situation, we’ll have inherently failed as no value has been delivered.
• Fail by concept: Has it sense to deliver a software in an agile manner when the specifications are clearly defined from the beginning? For instance, has it sense to be agile while developing an airbag controlling software? or a plane autopilot software? Maybe it has sense, but from my point of view we can deliver the same value without agile, so it’s up to us to decide whether to change or not.

My own conclusion

From my point of view agile solves the most of the problems in software development and frankly it does software development more human. However, we must take into account that it is not smooth and easy to embrace than one can initially imagine, so we must do a good analysis of how we’ll embrace it in order to be agile doing agile 🙂