Chat with us, powered by LiveChat
';

When, not if, to use Agile project management approaches

Agile is a hot topic at the moment. Agile approaches in software-intense developments are of increasing interest to fast-paced, organisations. It’s impacting project management and project managers.

Currently, the response to Agile varies. Some have embraced it wholeheartedly and have extended its use well beyond its original remit. Some have found it doesn’t work for everything. Regulatory-driven projects – even IT ones – don’t succeed with Agile’s “80% complete” scenario. Neither is it well suited to those projects where the requirements are well known and are not volatile.

That suggests that we’re not going to lose traditional project management approaches, even in IT. The debate needs to be when it is appropriate to use Agile, and how to recognise when it is not. One way to take this discussion forward is to look at what needs to be in place to make an Agile approach successful. Once that’s understood, when these conditions do not prevail, it will be better to invoke other approaches.

There are three factors to consider.

STAKEHOLDER ENGAGEMENT

A feature of project managing an Agile environment is that the focus is not on the scope, but on value delivered. This alters things. Change – the much-dreaded scope creep – is no longer regarded as a failure. Indeed, change is viewed as the positive consequence of having learned something and avoiding the mistake of doing something that is not wanted.

To be able to focus on value there has to be much greater and much closer involvement with the stakeholders. As one manager told us, “The Agile approach invites business ownership at a level never experienced before, and narrows the gap between requirement and solution.”
Of course, it also means that the stakeholders can no longer anticipate that they will have delivered a predetermined set of products – the solution is now in the hands of the developers. The sponsor and stakeholders are going to have to be able to live with that. So:

  • They have to be comfortable with the Agile way of working.
  • The timings for engagement with the developers have to match the rhythm of delivery to keep the fast pace going.
  • The team members need to be, and the key stakeholders really ought to be, co-located. The level of interaction more frequent and more demanding.
  • The stakeholders need a clear understanding of what they value most and be able to communicate this to the development team.
  • If these conditions cannot be fulfilled, running it as an Agile project is not going to be a happy experience.

TYPE OF REQUIREMENT

The other factor to consider is the type of requirement. The table below sets out the possibilities.

Table

FOCUS FROM SCOPE TO VALUE DELIVERED

The change of focus from scope to value delivered, also impacts on the questions the project manager must ask. Now, we need to worry about:

  • How closely does the next release meet the stakeholder expectations? Is the effort being put in demonstrably returning value, as recognised by the stakeholders?
  • Is the level of motivation and collaboration within the team sufficient to drive forward and overcome obstacles?
  • What can be done to ensure everyone turns up for every meeting, (or perhaps more realistically, how to deal with absenteeism from meetings?)
  • Who has the final say when the agendas of the stakeholders differ? Who is more important; the business sponsor or the product owner?

Tomorrow...

Ultimately, project managers, at least in IT, will need to be able to move between Agile and traditional approaches as appropriate. Evangelists on either side, the all-or-nothing brigade, will be moved aside. No horse wins every race.

Tomorrow is going to be different: approaches will adapt and evolve, responding to and reflecting the changing business and technical environment. Dinosaurs die, and so do risk-unaware youngsters. What thrives is the enduring thread of doing the right thing right.

logo