Watch out for an agile hangover!
Agility has become THE watchword for most businesses looking to upgrade their organisation to a more horizontal and collaborative model. As a result, agility has taken a central role in project management.
It appeals to young engineers and project managers, attracted by the promises this method gives a glimpse of. But it’s still sometimes misused, often for the wrong reasons and/or under the wrong conditions. All too often, clients confuse agility and iteration, at the risk of seeing their project take a wrong turn or grind to a halt along the way.
Businesses faced with Canada Dry agility syndrome
Agility is the word on everyone’s lips. We hear things like “our organisation has to be more agile”, and “we have to adopt a more agile approach” every day… BUT, at the risk of disappointing many a project manager, a lot of businesses today aren’t agile. Some might call it “Canada Dry agility” syndrome. It’s got the same colour, taste and shape as agility, but it’s not what it seems. With agility as the end goal, processes are often rushed, and definitions poorly established, causing misunderstandings and confusion from day 1 of the project. The situation runs the risk of quickly deteriorating, driven by the growing frustration of staff drowning in poorly-organised or poorly-led workshops, information irrelevant to their business line, or a much too broad scope of action. The teams don’t understand each other anymore, whereas the aim of agility is to create a common frame of reference for use in project management. Cash continues to be poured in as the teams work on poorly-coordinated, and consequently time-consuming, tasks.
Agility or iteration: you have to choose one… and stick to it!
Every project must start with an essential and crucial stage: asking the client what methodology they want to use. Even though a project combining iteration and agility might still be able to see the light of day by making specific changes, any difference between the methodology used by the client in-house and the methods deployed by the service provider to manage the project will jeopardise the whole affair. If you didn’t manage to or didn’t know how to have this conversation upfront and are now faced with this situation, there are several stages ahead of you to slice through this Gordian knot, starting with the most radical:
- Becoming aware of it. If neither the organisation nor the service provider are mature enough to do so, an agile coaching consultant is a good option when given even the slightest sign of going off track. If they arrive at the start of the project, they can put the right processes and methods in place to avoid this situation. If the project has already begun, they can help to raise awareness.
- Stopping the project. A necessary and natural step after awareness, stopping the project saves the teams involved time and can prevent a longer-term economic disaster.
- Make a decision and stick to it. Once the project is on stand-by, you need to work fast to reorient it and redefine the management principles. For this stage, you should consider your client as a partner, drawing up a new roadmap together and making it as relevant as possible.
Agility and iteration: different criteria!
Agility must meet a genuine business need. If a business identifies a genuine client-side agility need but the client isn’t organised or mature enough to execute an Agile methodology, checking the prerequisites must form an integral part of the start-up phase, even if that means delaying the launch. These prerequisites include:
- The involvement of a genuine client-side Product Owner with real decision-making authority and knowledge of their organisation and the related business lines.
- An Agile-qualified Scrum Master and project manager with experience of successfully setting up at least one project. If this condition cannot be met, an Agile coach must be appointed.
- A contract covering the agile specifics (organisational and financial).
- A clear, informative and unambiguous kick-off meeting attended by all the participants and decision-makers.
- Support including, if necessary, a separately-defined consulting budget.
This does not in any case mean that the iterative methodology is dead, and it would be a mistake to try to switch a full fixed-charge project to the Agile methodology. In this scenario, a clearly-defined iterative model would undoubtedly deliver better results. The Agile methodology must meet a genuine business need. For example, a big-budget client sent us a simple set of specifications, boiled down to one basic idea: “I want to sell my products at the end of the year”. In this scenario, it’s highly likely that the implementation of an agile methodology (meeting the prerequisites) could meet both the project and client needs. Measurement and setup of prerequisites on both sides is essential. If these two worlds clash during a project, it can prove explosive and cause significant financial and interpersonal damage. The teams need to speak the same agile language to move forward.