The pitfalls of Agile approaches

Although they can sometimes seem simple to implement, it’s not always so easy to take advantage of Agile methods. So here’s a list of common mistakes to avoid in order to ease your transition.

Putting the Agile Manifesto aside

The Agile Manifesto contains the essence of Agility in terms of values ​​and principles. Reading it and meditating on its content allows us to better understand and implement Agile approaches. It is important to always keep its content in mind. The application of the manifesto allows us to reap the full benefits of Agile approaches.

Starting on a bad contractual basis

Contractualization is often seen as an obstacle to using an Agile approach, in particular as part of a customer/supplier contract setting fixed deadline, budget and scope. However, Agile methodologies must provide a response to the client’s legitimate expectations: namely respecting a budget and a date for obtaining a requested product.

Several solutions exist, from the classic flat rate with a principle of barter by exchange of equivalent value requests, to a flat rate for each iteration. Other more creative solutions offer “win-win” contractual arrangements. However, without a sound contractual basis it is difficult to provide the flexibility that a client can expect.

Expecting too much from Scrum

Scrum is obviously the most used Agile methodology. However, it doesn’t offer much in terms of design and development. To be satisfied with Scrum is not enough; we should be interested in other methods such as XP or Kanban for example.

It’s also important to remember — even if things are changing — that the Scrum Master certification does not certify much if it is not accompanied by an individual endeavour. It does not, in any way, certify the capacity for implementation, and not even always the good understanding of the Scrum method by the certified.

Communicating in a limited way

Old habits die hard. In the context of an Agile approach, bridging the gap separating the professional and the technical sides is necessary. Keeping old reflexes (communication by email, geographically isolated teams, counter mode, etc.) can prove to be very expensive. Face-to-face conversation is to be preferred whenever possible and reasonable.

Neglecting rigor

When “shopping” for Agile methodologies, it is tempting to retain fun and easy to implement practices at the expense of the ones requiring certain discipline. Rigor is an integral part of Agile methods, whether on the part of developers (Tests, refactoring, simplicity, continuous integration, preparing client demonstrations, etc.) or on the part of the person responsible for complying  with the Agile process and its rules.

Adopting an unsustainable pace

A respected team (trust), involved, emancipated (through more empowerment) and subject to a sustainable work pace will offer its best in terms of productivity. Conversely, in the long term, an unsustainable pace (under pressure) generally leads to quality and productivity deterioration.

Keeping old habits

We all naturally resist change, sometimes even unconsciously. We must be aware of our old reflexes needing to be put aside such as compartmentalization, sticking to the initial plan rather than adapting, thinking of the “contract”, etc.

Forming overly specialized teams

Whenever possible, team members or at least some of them should be able to work on several different features. This approach is nothing less than risk management. In the event of sick leave combined with a critical bug in production or the integration of an important functionality, the risk of criticality is covered.

In addition, to design a solution or investigate a problem, two (or more) competent brains on a subject are better than one. This “multi-skill” can notably be acquired through the use of pair programming, code review or even through a rotation system. The goal is to reach the notion of “collective ownership of the code.”