Distorted agility

The Agile methodology, through its different frameworks (XP, scrum, kanban, etc.), holds many promises.

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

The great strength of agility lies in the incremental delivery of functionality whose customer feedback will allow adjustment as development progresses. By moving from a waterfall-type tunnel effect to continuous delivery, the client co-constructs the final solution. Excellent way, therefore, to ensure satisfaction of a product that we are partially creditable of its completion.

The Waterfall method

Before agility, the Waterfall method was the most widespread one in project management. Simple to understand, it consists of emphasising the preparatory phase so that the implementation which follows only has to follow a path so marked that the execution and the result deviate only slightly from the plan.

An example of a waterfall managed project could be the construction of a car as follows: we take the driver’s need, we design all the plans according to the driver’s dream car then we send the car into production to the factory. Once the car is produced, it is tested to ensure that it works properly and delivered to the customer. Finally, we will take care of maintaining the car throughout its lifespan with the customer.

The Waterfall method also presents some constraints:

• the preparation phase being substantial, the arrival of changes along the way is impactful.
• the risk of the non-alignment of needs. As the requirement is only collected at the start of the project, its development is tunnel-based, costly and even more so if the result achieved miss the requirements.

With our car example, here’s what could be failing:

• plans do not reflect a technical reality achievable in the factory.
• test cycles show technical or design failures that require backpedaling to previous stages.
• the customer wanted a city car and not an SUV.

The agile alternative

Agility, unlike the waterfall method, integrates customer needs throughout the development of the project. The initial phase of need analysis is shorter. The deliverables are also shipped more quickly, barely functional and gain consistency as iterations progress. The interest lies in taking feedback from customers and their needs in order to adjust as you go. This makes possible to optimize the entire production by providing exactly what is expected each time, no more no less.

The customer wants a car. The need is taken and synthesized, the teams begin to think about the design. The first drafts are presented to the client who specifies his expectations. The carcass is sent for assembly and the customer validates the structure. Now, the engine is added but upon inspection, the customer wants a more modest engine: the engine is changed. Ultimately, the customer obtains a completely assembled and functional car.

Limits

However, this promise is subject to the reality of the market and business. If deliveries have become periodic, it is also linked to the financing of the projects that has been staggered, subject to proof of satisfaction.

Many companies distribute periodic budgets to their projects/departments. Their amount is based on previous, future or expected results. This also allows these budgets to be adjusted and not to have to tie up large sums of money (sometimes) unnecessarily.

And from then on, this condition of satisfaction is transformed into a quest for approval. And this is where the shift can occur. We move away from the rational, and from the proposal to complete the project in the right order, to focus on the “wow”. If the stakeholder sees things that he likes, he validates. It doesn’t matter if it makes no sense in the production of the project, or worse, it doesn’t matter if it slows down/disrupts its smooth progress. And as the stakeholder is often involved, directly or indirectly, in the project budget, it is vital that he propagates a positive opinion.

Positions of those who distribute the budgets are ejectable, one another. Credibility and longevity therefore depend on betting on the good horses.

And agility is thus twisted. The door is wide open for the project manager to approach the PO with a new idea that will impress the stakeholders. Would the very vision of the project be compromised? No matter, now that the project manager knows that agility “welcomes” change. And then difficult for the PO to fight back with rational arguments because we must remember a second reality, the project manager very often has hierarchical ascendancy over it.

Who has never heard a PO declaring a “NEW RULE!” ?

Not all environments operate like this and cases where governance plays it alone are not the norm. But the more room there is for politics in business, the more agility becomes a weapon in this house of cards.