Agile beyond project management?

Since the approach has been so successful in managing complex projects, naturally there are interests to see whether Agile methodology can be used beyond project management, such as for application in organisational operation domain. The attraction is multiplied as the business landscape is increasingly affected by VUCA (volatile, uncertain, complex, ambiguous) environment.

Before we go beyond, let’s go through some fundamentals of Agile in the area it was originally meant to flourish, project management.

I’ve experienced several variations of project management methods throughout four companies that I worked at. Which one is the best? It depends, really. However, if we strictly limit the scope to game industry, in which I worked for about a decade, definitely Agile is a more appropriate approach.

As opposed to the “Waterfall” project management, where the value is delivered fully only at the end of the project, Agile is focusing on delivering value incrementally, by constant short iterations. Each iteration resulting in working product, hence the risk of failure is actually decreasing over time.

When is a good time to use Agile? PMI (Project Management Institute) and Agile Alliance came up with the following diagram based on Ralph D. Stacey complexity model (PMI, Agile Alliance, Agile Practice Guide, 2017, p. 14).

Not all projects are created equal. At least in the nature of the complexity. For something predictable and sequential (in the lower left of the diagram above), like construction project, for example, waterfall method will serve very well. We cannot place the ceiling of a building before its foundation. In this kind of scenario, it will be counter productive to use Agile.

BUT… as the uncertainty in the project increases, the likelihood of changes, wasted work, and rework also increases, which is costly and time consuming. Here is where AGILE methodology is suitable.
The team can explore the requirements iteratively and produce frequent incremental deliveries. This way the team can adapt to changes more easily.

Characteristics of these approaches:

1. Short feedback loops
2. Frequent adaptation of process
3. Re-prioritization
4. Regularly updated plans and
5. Frequent delivery

Naturally, those work perfectly for projects that involve new tools, processes, technology, methods or materials. In order to do that, usually the projects have:

• Unclear or not yet known requirements
• High degree of uncertainty in the methods used
• Final goal that has yet to be determined
• High rates of change
• Needs to do research and development

Those kind of projects fall nicely in the Complicated and Complex regions of the diagram.

There are limits to the applicability of the iterative and incremental approaches. As the complexity reaches the Chaotic region of the diagram, there are too many variables and the level of uncertainty is too high even for Agile to handle. Some components need to be fixed in order for the project to be manageable.

Speaking about variables and constants, we have to look at the Triple Constraints of project management. Under Waterfall, scope is deemed as fixed at the start of a project, something that must be locked down. Ironically, scope is rarely locked down (due to scope creep, newly discovered requirements, etc.), affecting Time and Cost in the process. When projects are delayed and over budget, key stakeholders are not happy.

Agile is trying to look at it from a completely different perspective and flipping the triangle. In Agile the Time and the Cost are fixed, while the Scope is allowed to be flexible. Agile approaches specifically embrace changes and use them to make better-informed decisions and more useful deliverable. However, it is only possible by enforcing the concept of re-prioritization.

As the scope changes, all stakeholders must understand that since Time and Cost are fixed, targets must be re-prioritized in order to deliver the highest possible value with the constraints given. This may look simple, yet it can be a major shift of paradigm, especially for the key stakeholders.

Back to my experience in different working places and projects, the application of Agile project management resulted in varying degrees of success. There were projects that can be delivered on time on budget, but there were projects that kept on missing deadlines and the schedule had to be extended by two to three times the original plan. It shows that Agile, as alluring and promising as it is, still is not a one size fits all solution. It has to be tailored and customized according mostly to the readiness of the stakeholders (team members, key stakeholders, everyone affected by the project). Nonetheless, if done right, it has proven time and again to be a powerful approach to run a project.

Now back to business operations management, how can Agile fit into it?

At first, it may seem counter intuitive. Project by definition has a specific end and goals, as opposed to operations that go on and on as long as the organization exists. However, if we take a step back and observe Agile as a whole, the key concept is all about flexibility, efficiency, and transparency. Those are qualities that definitely can be adopted by any business operations. A better question is probably whether the form of Agile to manage a project is the same as the form to manage an operation. Then there is another concern where Agile might be confused with Lean. While there are many overlapping qualities, the two are not the same. Perhaps it is more useful to look at it this way: Lean aims to remove wastage, while Agile can be deployed to find a way to do so.

To illustrate further, for an operation to be running smoothly, there should be some degrees of stability, else, there can be confusion that ends up in loss of productivity. Production line will be a mess if it kept on being disrupted in such a high frequency even if for the sake of improvement. On the other hand, there is no such thing as permanent perfection. As technology evolves and business landscape changes, there must be adjustment on the way operation is being run. In order to improve process, a parallel endeavor can be performed independently without disrupting the operation. Only after a new improvement is completed, then it is injected into the operation to augment or replace the existing process.

It is crucial to have a clear distinction between the process and the improvements. The lack of clear distinction between the two is akin of driving a train while the track is being laid down while also figuring out how to actually lay down the railway track. Not only it is counter productive, it may also be dangerous.

The application of Agile for business operation has been studied by people way more qualified than I and published in highly credible publications. Some of the good ones are:

• Embracing Agile, Harvard Business Review – great coverage on the pitfalls and danger of inappropriate use of Agile
• The Five Trademarks of Agile Organizations, McKinsey & Company
• Applying Agile Practices to Business Teams, Tech at GSA

In the end of the day, a tool is only as good as the person using it. As powerful as it is, Agile is no different.