This is the first in a series of posts on Agile adoption mistakes or anti-patterns based on my experiences on a number of projects both in Australia and in Europe. These anti-patterns cover a broad cross-section of project concerns including method customisation, transition strategy, work breakdown, technical and quality debt as well as teamwork issues. Each anti-pattern is presented in a consistent structure comprising background material, a short experience report, smells that may represent a symptom of the problem, factors that may cause the problem to arise, potential consequences if the problem is allowed to fester and guidance as to what can be done to avoid or resolve the problem. Awareness of these Agile adoption mistakes is expected to assist ScrumMasters, Agile Project Managers and Team Members to avoid falling into these traps and to deal with them effectively if and when they arise.

If you have had a similar experience or have a different perspective on this, please post a comment below.

Background

Like programmers optimising code before they have seen real evidence that they need to, organisations commonly attempt to optimise elements of a methodology before having applied them. Established methods are systems of interrelated practices that work effectively together. Their effectiveness can be severely limited by failure to properly implement key practices that support others.

Experience

Management was highly supportive of the agile method being introduced but believed that it would not work successfully without modifications to the organisation's unique environment and corporate wisdom. Management asked that the complete custom methodology be documented prior to its full application to satisfy ISO 9001 audits.

Smells

• Management beginning an agile transition with a belief that the agile method will need to be substantially tailored.
• Team members suggesting modifications to the process without having first attempted to apply it 'by the book'.
• Efforts to document a custom methodology without first fully implementing the method on which it is based.

Causes

• A deep-seated belief that this organisation works differently to others, that these differences are key to the organisation's success and that implementation of a one-size-fits all method will compromise this.
• Previous experience with highly prescriptive methodologies that require extensive tailoring prior to implementation leads people to expect that they will do the same with Agile methods.
• Management has an interest in developing intellectual property around a custom methodology.

Consequences

• Certain elements of the method being implemented are never properly understood by the organisation as they have never been used.
• The organisation may experience what Kent Beck warns of regarding incomplete implementation of eXtreme Programming i.e. that by implementing 80% of the practices you may realise only about 20% of the benefits.

Guidance

Agile methods emphasis an empirical approach to process improvement. Therefore, apply the agile method 'by the book' for three iterations or until satisfied that it has been adequately explored before inspecting the real world implementation and assessing what adaptations might improve it. Do not change a practice that has not first been genuinely applied along with other related practices such that its benefit can be assessed from real world experience.