Agile By Necessity

We don’t tend to think of Agile as a risk mitigation approach to projects, but in many ways that is what it is — when the solution is unclear, or the requirements are difficult to define at the outset, we reduce the risk of getting those requirements wrong by using an approach that builds flexibility into the process.

   

Traditional project management focuses on building a plan and then executing that plan as effectively and efficiently as possible. While variances from the plan are expected, there is a focus on trying to minimize those variances and recover from them as quickly as can be achieved. However, there’s a fundamental problem with that approach; it presupposes that the plan is reasonably accurate and that any variations are likely to be relatively minor. What happens if the plan is completely unrealistic from the start?

The easy answer to that question is to suggest it’s a case of bad planning and that there needs to be more work put in to developing a realistic plan. Sometimes that’s true, but sometimes plans change for reasons completely beyond the team’s control. Let’s consider situations where risks become real that could not reasonably have been managed for. A recent example is the series of hurricanes that hit the Caribbean and a number of states in the U.S. this year. While hurricanes are a reality of living in those areas, the likelihood is that most projects that were underway in those areas had not planned for a significant disruption to resources, infrastructure, etc.

Clearly these natural disasters were far more serious than simply delaying projects — the loss of life and destruction to property is tragic. But they are extreme examples of events that can derail projects. In this article I want to consider how Agile approaches might be able to support these projects to be less impacted by such disruption.

Agile as risk mitigation

Let’s start by focusing on something far more mundane than hurricanes. Let’s suppose that in planning a project we have identified one or two areas that are higher risk than others. There may be a dependency on a single resource who has the required expertise, there may be a vendor involved who has a track record of problems with their delivery, or there may be a work package that is extremely complex and where the outcome is uncertain. Historically within waterfall projects we would attempt to schedule that work first and fill in everything else around it, and that may work, but it generally only reduces the risk or identifies whether the risk will trigger earlier, it doesn’t do much to manage it. For example, if we schedule the problematic vendor’s work earlier and they have problems all that has happened is we triggered the risk sooner. We may try and manage the vendor more aggressively during the process, but that’s guaranteeing higher project costs, probably not strengthening the relationship with the vendor, and potentially having no impact on the likelihood of problems occurring.

If instead we take a different approach and simply say that instead of scheduling the work early in the project or assigning greater governance and oversight, we are going to remove much of that structured plan we incent a different outcome. Suppose the vendor is simply told they need to have completed their work by a certain date and that the output must meet certain criteria — functional and performance specifications. This effectively puts the vendor in charge of a ‘mini Agile’ project where they can own the delivery. We wouldn’t necessarily call it Agile if the vendor doesn’t see that as their core approach, and we don’t dictate that they have to do anything different than a pure waterfall plan internally, but we are using an Agile approach to manage the project’s risk.

There is of course a trade-off for the vendor – the date they are given is likely earlier than in a structured, high governance, waterfall plan, but they trade that time for control. They may also be asked to trade the specifications of the end product – the stated functionality and performance may be higher than what is actually required, but we don’t tell the vendor that. This builds in a reserve for the project in the event the vendor falls short, and is a further risk mitigation approach. We also reduce the costs to the project by implementing a requirement for less oversight, and that money can be reinvested into other areas that are likely to be more responsive to further expenditure.

Agile risk recovery

Those same Agile principles can apply when a project is trying to recover from a triggered risk, especially a highly disruptive event that will go beyond the expectations of traditional contingency plans. In these scenarios the project may find that the plan is essentially destroyed, the only way to progress is to think beyond a highly structured, single threaded approach – an environment of Agile by necessity if you will. Let’s think back to our hurricanes. In the heart of the destruction zones all projects that were underway prior to the disaster are on hold, the focus is on recovery starting with restoring the basic essentials while distributing emergency relief. There’s no plan for that, and when we try to apply standard practices and approaches things go badly wrong. There are any number of stories around the problems experienced with Hurricane Katrina in New Orleans a decade ago where relief shelters were sitting idle in storage lots because the people tasked with moving them hadn’t been cleared through the standard approval processes.

Instead, if the people who find themselves in positions of responsibility in such situations – either the mayor of a community that has been hit by a hurricane or the project manager whose entire team has been struck down with a mystery illness, are able to understand and apply some Agile principles and practices the work can still move forward. For example:

  • Define the outcomes that need to be achieved. In a disaster situation this will be redefined regularly as interim goals are met – it will start with rescue efforts, then getting clean water and medical supplies in, restoring power, communications and physical infrastructure recovery, etc. Unlike our example with a vendor above, the goals we set here will initially be less than we might ideally want because we need to do ‘something’ as quickly as possible.
  • Provide complete freedom to deliver those outcomes. If we task individuals or groups with delivering the required outcomes we must also trust their judgment to deliver those outcomes in the way they see fit. Not every situation will be so extreme that every standard or duty of care can be forgotten, that’s a judgement call, but we must allow the people doing the work to operate with as much flexibility as possible to allow them to achieve their outcomes as rapidly as possible (speed may not always be the primary factor, but it will be in most scenarios).
  • Provide rapid feedback to allow for adjustments. Agile is built on the premise of getting something into the hands of customers early and getting their feedback in a timely manner to allow for improvements. In these Agile by necessity situations the feedback is more likely to be a reassessment or reprioritization of the most pressing needs so efforts can be redirected to areas that are now the most critical —  effectively a very rapid backlog reprioritization.

What must be avoided in these situations is the need to have to learn any approaches or methodologies, the focus must be solely on the required outcomes. As a result, we may not refer to any of this work as Agile, that may cause unnecessary anxiety among people who think they need to know what Agile is and some of the principles. The oversight and control functions should contain some Agile expertise but in dealing with the people who are on the ground and solving problems the Agile concepts should be translated into ‘normal’ language. In a less dramatic scenario, if a PM has lost their team to sickness then any emergency replacements shouldn’t have to worry about Agile terminology or process, but the project manager should be managing using those concepts ‘translated’ into requests the replacement team can recognize and respond to.

Conclusions

Thankfully, true emergency situations such as those caused by this year’s Atlantic hurricane season are rare, but every project manager has handled situations that felt dire at different times. In at least some of those situations, the ability to bypass traditional project methodologies and add some Agile approaches will have not only improved the project’s ability to deliver — in turn improving the contingency performance — it would also have reduced the stress and concerns faced by the project manager and team

Source: www.projectmanagement.com

Stevbros delivers project management training worldwide, our courses have proven their worldwide acceptance and reputation by being the choice of project management professionals in 168 countries.

Share in