*The art picture provided by Zenaviv project. The artist - Himal Bikmal, the art title - 'Calm Before the Storm'.

Managing a project using Agile methodology has become the latest in project fashion. Agile has a compelling argument: faster delivery of products, rapid turnaround on changes, minimal documentation. It is no surprise that many project managers are leaving behind the old traditional ways of managing projects and embracing the Agile route. However, using an Agile methodology is no guarantee of success. If you have adopted an Agile approach for your project and it is still beset by problems, here are the eight most likely reasons for why your project is failing:

You’ve interpreted ‘minimal’ documentation to mean ‘no’ documentation

Agile was invented by a group of software, technology and IT industry experts in the late 1980’s. It was invented to address the common problems faced by IT projects using traditional methods of project management. Part of the manifesto written by that group of experts was:

Working software over comprehensive documentation

This has often been misinterpreted as no documentation by many practitioners. However, it is a flawed assumption that Agile equates to zero documentation. All projects must be reviewed on a case by case basis and sometimes documentation is essential to the development of a project. The real interpretation of this statement was about keeping documentation succinct and relevant, rather than hundreds of pages of clumsy, wordy text.

You are out of step with the rest of your organization

In order for Agile to work, or any other project approach for that matter, it needs to be embraced by the organization as a whole. To secure resources, time and funding, the organization must understand Agile and understand the benefit. If you are implementing an Agile project in an organization that typically uses traditional approaches, it is likely you will be met with some resistant along the way. This resistant may be enough to cause your entire project to fail. To run Agile successfully, it is advisable to roll it out across the organization, even if that is on a trial basis.

You have a limited budget

Running an Agile project requires some flexibility. You might decide to build your prototype, and the customer may ask for numerous changes that you need to incorporate. This is an accepted part of running an Agile project but it is not something everyone feels comfortable doing. This is especially true in the case of a fixed budget. It is difficult to set a fixed budget for an Agile project because it limits the amount of changes you can carry out and you may end up with an end result that is not satisfactory for the money paid. If money is tight, Agile may not be the best choice of approach.

You are producing a product that does not react well to change

Agile, unlike traditional project methodologies, embraces change. A product can be built as prototype and then changed repeatedly until it is fit for purpose. This is ideal for software projects where a change may simply mean a few new lines of code. However, if you are dealing with a house build, for example, there is little you can do to change the design of a building once the foundations have been laid. Sometimes a product needs a lot of upfront design and large upfront investment. If this is the case, a traditional methodology may be best.

Your team does not understand what Agile methodology means

Agile projects embrace teamwork. It is in the antithesis of the ‘management’ approach to projects, whereby a team is given clear instruction on what to do. In an Agile project, the emphasis is on collaboration. This only works if the team understands this and is willing to take part. Many team members may welcome the idea of being more involved in the project. However, if you are dealing with team members who prefer detailed written instructions, you may come across some resistance.

agile projects embrace teamwork

You haven’t adopted a proper Agile methodology

Agile is the umbrella term for many methodologies, for example, Scrum, XP (Extreme Programming). Agile will give you a set of principles to abide by. It can perhaps be thought of as the philosophy governing the project approach. However, in order to make practical steps to carry out an Agile project, it is also important to have a specific framework. The best advice is to get full formal training in an agile methodology prior to starting work on your project. This will give you proper guidance, tools, methods and tips to ensure that it is implemented on the project successfully.

You are trying to combine Agile and traditional methodology in the same project

There is a school of thought that it is possible to combine traditional project approaches with more modern Agile methodologies. However, to do this successfully requires a great deal of knowledge and experience in both. If you are attempting to combine the two without giving it proper consideration, you may find tension between the different approaches that pulls your project in different directions. If in doubt, stick to one approach.

You chose Agile to get your project completed faster

Agile is the fashionable methodology and when done successfully, practitioners will talk enthusiastically about the speed and nimbleness with which a project was completed. It is tempting as an outsider to listen to these wonderful stories and become enthralled in the idea that Agile is a magic bullet: that it will allow you to get that complicated project done in the speedy timeframe you’ve been given. However, this is not the case. Agile is fundamentally about having flexibility in your project: flexing time, money and the scope of the work. Simply using it to try and give you a shortcut is not going to work.


Applied intelligently, Agile can give a project and an organization a competitive edge. It is liked by teams and it is embraced by many customers. However, it is not without its drawbacks. If you are finding that your Agile project is not living up to expectations, check these eight points. You may find that there is an underlying reason for why you have encountered difficulty in your project.