Agility to succeed

On February 11 2001, a group of 17 software developers met at a resort in Utah to exchange their views on new delivery models. Over the previous decade, most of them had been working on frameworks, all of which had in common a lightweight process and a firm contempt for any documentation-driven delivery model. 

The waterfall method was the primary target of their reform. In waterfall, all the requirements are validated, detailed, discussed and designed beforehand – an effort considered unnecessary, unproductive and frustrating for the team. 

These ‘organisational anarchists’, as they called themselves, probably did not imagine that the principles of their Agile Manifesto would have started a small revolution at the very heart of project management. 

The proposition was clear: instead of immediately detailing all of the requirements and basing both the plan and the contract on a series of assumptions that would turn out to be inadequate at best, delivery teams were invited to embrace an iterative, fast-paced and much more flexible approach. 

Contrary to common belief, the Agile Manifesto did not per se promote a new project management methodology, as it was just a (powerful) vision statement. The manifesto only set a common ground between the frameworks, which were already describing a new landscape and suggesting that a new dynamic between clients and suppliers was possible. 

Tired of taking upon themselves the burden of every loss and extra cost, many suppliers started exploring the possibility of replacing the traditional waterfall delivery with alternative methodologies. Scrum, one of the most articulated agile frameworks, was offering some valuable features. 

Agile refuses to analyse requirements beforehand – and thus declines to provide an initial certainty. This will probably always scare any stakeholder trying to understand whether or not they can show results to the board with the budget that they are granted. Scrum, however, sounds slightly more reassuring, with its ceremonies, planning session, commitment to delivering some stories within a pre-defined period, degree of predictability offered by story points, and velocity. 

In the blink of an eye, ‘agile’ popped up in contract wording, and people were asked to comply with its predicaments. As promising as it all sounds, just a few years later we started reading about how agile was a mere utopia, and scrum not practicable. After just a few rounds, it seems we went from hero to zero. Undoubtedly something went wrong, but nobody wants to believe that the problem was agile. 

Understanding agile

From a practical point of view, the first issue is that, most of the time, clients do not understand agile. Everybody seems too eager to sell it to spend more than a second considering what clients believe they are buying. Why should anybody be concerned? Who does not understand nowadays what agile is, right? Wrong. 

Many people have a general understanding of what scrum is, but only a few understand the end-to-end of its flow. If even the insiders that are supposedly working scrum do not follow many of its prescriptions, I would not be surprised if most clients ignore even the basis of agile deliveries. 

While pursuing a model under which we share the responsibility for failures with customers, we actually failed to explain to them what their rights and obligations are under that model. Educating the client is at least as important as training every team member to use an agile framework. Customers instinctively try to return to the safe place where the supplier commits to a date and takes full responsibility for it. They must then be constantly reminded that the feeling of uncertainty that predominates in agile deliveries is a small price to pay for a much broader control over priorities and scope.

We can also agree that any preparation or training is futile if the service agreement or contract does not protect the agile delivery, because, rest assured, knowing the rules of the game will not make clients respect them. Herein lies the second problem. 

Contractual terms

Consolidating the contractual terms and delivery model is one of the early challenges that many project managers have to face when starting an agile project. For decades, the primary condition for every project to succeed, whatever the methodology, has been for the contract to respect the ‘iron triangle’, whose corners are scope, cost and time. 

If we want to protect the quality of a project, we cannot alter any angle without affecting the others. You cannot reduce the time without increasing the cost or diminishing the scope. Likewise, you cannot expand the scope without also raising the cost and probably also the time.

Agile, if it is to be effective, is even more demanding, as we can ensure the quality of the deliverables only if one of the triangle’s corners is fixed and the remaining two are flexible. 

In an agile world, the scope is like a living organism continuously evolving in reply to market inputs, users’ feedback and strategic choices. If time to market is still a leading driver, agile frameworks provide access to the core of the assembly line and enable the business to drive production much more closely than most other methodologies.

Given these premises, it will not be difficult to imagine that estimating an agile project is probably the greatest challenge for any project manager. Stakeholders cannot cope with the absolute uncertainty – and nobody blames them for that. Therefore, it is not uncommon for project managers to be asked to provide a target date for the target scope, an estimate of what kind of effort clients need to be expecting. 

The ‘agile way’ of doing this is to gather the key stakeholders for a series of brainstorming sessions. Multiple exercises, and a level of gamification, usually help identify the user’s persona and needs. User stories – whereby the who, what and why become clear – can help narrow these needs down.

At this point, it may come as a surprise to learn that the project manager is considered part of the problem when it comes to adopting agile. It is not unheard of for organisations to remove project managers from the picture and just plug in an agile team with its scrum master. 

The problem is that scrum requires discipline but, at the same time, mostly ignores project governance. It would be extremely naive for anybody to think that the scrum roles are sufficient for a project, as scrum does not specify who is meant to manage issues, risks, senior stakeholders and expectations. 

The reality is that scrum master is a role, project manager a job title, and thus a 1:1 mapping does not apply. The debate is still open on how we should redistribute the responsibilities of the project manager across the agile team, and the answer is not unequivocal. 

The scrum master and product owner could probably cover most of the activities typically carried out by a project manager. However, the role of the product owner seems to be falling more and more often into the client’s domain, creating the need for a different profile – that we intentionally keep calling project manager – to handle the project governance.

Setting the record straight

Agile landed among the project management landscape and was regarded as the answer to the common problems plaguing most of the deliveries. 

The real misunderstanding lies in the fact that agile frameworks are designed as problem-finding, rather than problem-solving, tools. Agile is no magic wand, but it allows an early identification – and therefore resolution – of issues. Setting this expectation right is the key to a healthy relationship with agile. 

This blog first appeared as an article in the Autumn edition of  Project Journal and is authored by Mirko Grewing.