The most important part of Agile is education. Ongoing education.

Agile is a widely adopted methodology across the software devevlopment industry. The two main frameworks of Agile are Scrum and Kanban, both similar variants to each other but which both address the same set of problems with software traditional waterfall development, such as slower and more problematic delivery.

They address these problems through more collaboration across disciplines to ensure decisions are made with all relevant viewpoints taken into account, more frequent release cycles to ensure early exposure of the product to the client and the ability to adapt and change course where necessary, and a commercial structure that understands the reality of complex, software development with many integration points by agreeing to either fixed price or fixed scope, but not both.

Agile is also evolving into new, more effective ways of producing software like Lean development, a growing movement which stems from the Toyota Production system which advocates principles such as eliminating waste, amplifing learning, late decision making, fast delivery, team empowering, integrity and a holistic view  of the software being built.

A new vocabulary and set of tools have developed to support these new ways of working. Scrums, Sprints, User Stories, Points, Product Backlogs and Burndown Charts are all incorporated into our dialect and work flow systems have adapted to create, assign and monitor units of work in Agile ways.

The problem is that, in my career, I've seen many projects dubbed 'Agile' and but then suffer from an identity crisis, resulting is issues with production. These projects have been dubbed 'Wagile' or 'Fragile' where they seem to exist in a dyfunctional purgatory between Waterfall and Agile. I call these project 'Yellow Brick Road' projects and have blogged about them here. These kinds of project bear some familiar characteristics.

Some reasons for Agile meltdown include:

There can be only one! Agile master

A company decides to move from waterfall to agile. Their Project Managers have been sent on a two day Scrum Certification course and return, magically transformed into Scrum masters armed with a stack of post it notes and new vocabulary. The project is run waterfall with Agile stuff crowbarred into the project which no one really gets and causes confusion.

The client doesn't understand Agile

The client wants fixed price and fixed scope and they want it delivered at a certain date. Commercially, these three requirements blast Agile out of the water. But because Agile is the way forward, it is loosely followed anyway. Again, this creates unnecessary confusion with the client. This can backfire in the biggest way if there is a misunderstanding about scope i.e. the project is run agile and 'something is delivered' for a certain price but the scope doesn't match up to the client's expectations. In these cases, the deficit need to be negotiated between the supplier and the client which can be damaging to the relationship and the bottom line.

Agile is an excuse not to do stuff 

Agile means no wastage and we can work stuff out as we go, right? That mindset can become a great excuse not to worry about things like detailed requirements gathering, specification and documentation. No project can be successful with  these in place.

Agile is overkill

It is a simple three month CMS build with no major integration requirements. In these cases, one tried and tested iteration of Design, Develop and Test is all the project needs.

To fix for these problems is both simple and complex. It is simple because it can be phrased in one, easy to digest mantra,

Agile can only be successful if everyone understands what it is!

The complexity is making this happen. To make it happen here are some rules to follow:

• Create Agile Evangelists - Make sure you have Agile evangelists in the business who have a good understanding of the software development process. People with a technical background are best suited to this such as Technical Project Managers, Software Development Managers and Technical Directors.
• Have them apply Agile to projects - Train your Agile evangelists but most importantly let them apply Agile to projects and gain practical experience. Feed this experience back into the organisation. 
• Train your whole company on Agile - Get your Agile evangelists to train everyone in the company so that there is a grass roots understanding of what Agile means and create more champions of the methodology. 
• Train your clients on Agile -  Get your Agile evangelists to train your clients on Agile. Make sure they understand the point of Agile and what it means commercially. Make them advocates too.
• Keep it up - Agile needs to be kept afloat throughout the project through constant education, policing, reporting and communication internally and externally. Agile has to cut across the Software Development Life-cycle from start to finish. 

In a nutshell, successful Agile it is all about education. Ongoing education.