Let’s begin by agreeing that the quest for success starts with the right approach to support project delivery.
As a practitioner in the project, program & portfolio management space for many years now, I have seen different delivery approaches work for different organizations based on project characteristics and organizational needs. Each project need will have a spot on the continuum, from the predictive waterfall approach to an Agile approach.
Meanwhile most of the practitioners I interact with seem to have chosen a side – there are some strong believers of waterfall that stresses meticulous planning and a sequential delivery approach, while others are strong believers of less process heavy, iterative delivery approaches.
I, personally, beg to differ. I believe that both of these approaches have their own strengths and weakness and there can be successful co-existence between these methodologies. Being mostly surrounded by waterfall experts, I have seen a huge gap between traditional project management perspectives and the newer, more Agile approaches.
Most of these gaps stem from limited knowledge on the subject from the opposite side. Specifically, here are some key disconnects that I have encountered over the years
An Agile approach is the extreme opposite of Waterfall approach
Not true.
Even in the most Agile centric environment, many of the Waterfall project management principles are valid even if applied in a different context. These principles might not fall neatly into some of the typical knowledge areas of traditional approaches, such as scope, time and cost management – but there is still a need for striking the right balance between planning, control and agility. All project life cycles include a planning element. What differentiates the life cycle is how much planning is done and when.
For instance, risk management processes, in traditional waterfall project management, are implemented to control & monitor risks. An Agile approach, on the other hand, implements risk management in a broader sense by coaching team members to incorporate risk management principles into the way the work – thereby eliminating some of the risk monitoring aspects found in the waterfall approach. Both approaches have risk management aspects – it is just implemented differently.
Being Agile only impacts the IT departments
Again, not true.
Any methodology (Agile or Waterfall) requires organizational commitment which extends far beyond the IT or Project Management teams. Not to forget, it may require some major shifts in organizational culture to make it work. What makes any delivery approach successful for an organization is the commitment by the organization to make it successful.
It starts with deciding which methodology will be right for the organization; which one will support their current and future goals and which one can bring them closer to meeting their bottom line. It can very well be a hybrid between traditional and contemporary delivery approaches. What needs to follow is the commitment throughout the organization to change their old mindsets, processes & come onboard to support the change.
The point that I am trying to make here is that thinking of any delivery approach as being a silo to a particular department or team is incorrect. It is far broader than that.
You need to make a choice – Agile or Waterfall
Do we really have to? The idea that you either need to follow a methodology by the book – or not at all. is preposterous. The fact is, an organization can choose to design a delivery approach that creates a perfect marriage between plan driven approach and agility which aligns with the organization’s strategy.
Of course, certain changes would call for a traditional waterfall approach, for instance building a house, and some would call out for an Agile approach, for instance building an app to control the temperature of the house. The fact of the matter is that it doesn’t need to be as rigid as some practitioners perceive it to be. The right thing to do is to be focused on delivering a solution in the most efficient way possible rather than being solely hung up a particular methodology and its boundaries.
In conclusion, practitioners from both communities (traditional & Agile) are so focused on promoting the benefits of their own delivery stream that they tend to overlook the idea of co-existence. It doesn’t have to be a black-and-white proposition – it can very well be a mix of the two – you just need to strike the right balance.
I am a strong believer that there is no one right solution for everything and that a peaceful co-existence can exist amongst different perspectives. I also believe that better solutions are yet to come, ones that are not constrained by current boundaries and that are focused on better supporting the diverse and ever-changing demands of the world we live in.
Affiliated Promotions:
Please share!
There are lots of Agile practitioners, coaches and trainers out there claiming to be experts. Some are genuinely skilled while others have a few key certification letters beside their name and yet little to no in depth, real-world experience. Although most have a genuine intent to help and they might actually succeed at it, others might inadvertently do more damage and provide harmful guidance. How can you help them help you?
There are also numerous frameworks, methodologies, and practices that claim they are well suited to help an organization become more Agile. Some of them are simplistic, process-based approaches that may not account for your environment, culture, or specific business needs, while others are more complex and pragmatic. Depending on your situation it can be tricky to know what will work best. How can you find a suitable fit?
There are also many tools and approaches to measure a team’s Agility, the leadership’s alignment with Agile, or the organizational maturity. Some of these simply measure the number of practices (i.e. are you doing Agile), others account for an in depth assessment of cultural factors (i.e are you being Agile), and some are based on scenarios that are idealistic given common real world business challenges.
“
