“Life is what happens to us while we are making other plans” Allen Saunders, Publishers Syndicate
Agile practices are now several decades old, maturing and taking shape in the last 2 decades and every industry has implemented it in some form or fashion, including Governments. The Agile manifesto was developed in 2001 and was originally written for software development (https://agilemanifesto.org/). The very basic concept of Agile is to deliver solutions iteratively with continuous feedback loops through increased collaboration, experimentation and validation from the live environment. As the internet and devices matured, it became even more imperative to deliver solutions quicker and faster to learn user behavior and reactions before investing more time and money on features that originated in close-door meeting rooms.
Traditional project management
Looking back at traditional project management, we know that it is based on phases, stage-gates — research, gather requirements, plan, execute, test, deliver, and support.
A large part of the time is spent gathering requirements, creating usability matrices, mapping them to specifications and finalizing plans through work breakdown structures, capacity planning and creating baselines — scope, cost, time.
Once all that is set/stamped/frozen, work begins, and eventually the team comes back after a few weeks/months to deliver the original scope.
There is nothing wrong with this.
It is a structured process, allowing managers to have tight controls and measured reporting on projects. For generations, numerous standards have existed and have matured to manage this methodology — it is also called a waterfall method of project management and project delivery — going from phase to phase.
Typically, and coincidentally, organizations that are hierarchical, have long-standing success of project delivery in this methodology. There are several reasons why — one of the main reasons is the need for control at all layers in a hierarchical, centralized organization. Such organizations even have their own frameworks of undertaking projects in the waterfall methodology — their entire operations have been designed and centered around waterfall. If they are spread across geographies this is even more true, where a centralized project management office feels the need for greater control. M&A activity adds additional layers of complexity and post integration challenges are overcome by going back to “what always worked”.
How is Agile different?
Fast forward to the world of Agile, it is quite an opposite mindset. The basic principles of the methodology lies in how projects are delivered. Here is a simple, self-explanatory diagram.
But more importantly and in lines with the theme of this post, from a mindset change, here are the main differences.
- In Agile projects, cost and time is frozen, scope is constantly reprioritized based on early learnings from the live environment
- Collaboration and communication take preference over rigid contracts — scope of work in contracts with vendors / internal departments are fluid and subject to change
- It is more important to test working solutions and learn from the live environment, continuously and iteratively rather than create fully-buttoned up solutions.
- Prioritizing a backlog of tasks takes precedence over creating fully-baked plans and sticking to that plan throughout the duration of the project
- It is more important to interact with each other in teams rather than create strict process and tools to manage how work is done
- Managers in Agile organizations measure teams based on the amount of learnings, the ability for teams to iterate continuously and adapt, rather than stringent KPIs only
We can see how this can scare organizations and managers that rely heavily on processes, numbers and plans. It goes against the very grain of the organizational mindset. This leads us to the next obvious question.
Is Agile better?
I am not saying one is necessarily better than the other.
Some projects require long periods of planning and sticking to the scope no matter what happens. Although, that is becoming rare! And the biggest reason why it is becoming rare, is that world around is changing more rapidly than ever before. So, assumptions made today may not be true tomorrow or even later that same day.
Next, the advent of digital is making in-house processes external as well — basically the customer not only wants to look, smell, feel and place the order, but they actually want to see the sausage being made in the factory and “feel” it getting delivered to them so that when they open the package they can enjoy it even more — connected devices, emerging technologies and intermingled network of industries allow customers to demand this level of transparency.
So, the argument that projects that only impact in-house processes does not have to get learnings from an external environment, is no longer valid. It is therefore critical that any project (internal to the organization or external) be open to changing its scope throughout its lifecycle — from my experience as an Agile coach, this is the biggest fear for organizations that want to move to Agile from a traditional waterfall methodology. Most ask me “how can we do something if the plan is a moving target?”
My 16-year-old son asked me how he can implement Agile in his life!
“It is not possible for students to distinguish between Agile and Waterfall. In fact, we have to kind of do things in waterfall. Like my project assignment — I have to plan, work and then hand it in.”
He does have a point, but this is how he can change (he is actually trying!) — I told him…
“why not write all your thoughts on a piece of paper, take a picture and send it to your teacher to get some early feedback? Then keep iterating, till you have a final product ready.”
The goal here is to iterate, learn as fast as possible and then incorporate the learnings into the next iteration. In the lean startup world, they call it the build-measure-learn loop — but that is another discussion!
In the end, one may argue, that the answer lies in the details, the nuances of a specific project or industry or market, environments etc. But almost always the answer lies in the willingness of organizations to try Agile. And then, some companies are forced to try it because status quo is no longer an option for them.
I am a transformation consultant, an Agile coach and a lean junkie and I spend a lot of my time researching organizational culture. I enjoy dabbling with new technology to solve business problems. In anything I do I try to go about with Agility.
Would love to hear your thoughts on this…