Over the past few years, more and more organizations have been moving away from traditional project management and towards Agile. What drives this change? Why have large enterprises that used to be very firm about their processes and methodologies, and traditionally practiced the “waterfall” approach, all of a sudden joined the Agile transformation trend?
I believe there are two main factors: a long history of project management challenges and random exposure to information about Agile.
The first factor is easy to explain: name a single organization that does not face project management challenges. Statistically, 2 projects out of 3 are not successful.
Clearly, senior management, who usually operate using “high-level” statistics as opposed to dealing with the root cause analysis of every particular problem, are for looking for some “high-level” decision-making tools for a solution.
This is where the second factor comes into place, with all its pros and cons. The pros are that the managers learn about Agile, its benefits and strengths, and try to apply it to their organization. The cons are that in order to implement Agile, it is not enough to learn about it. It is important to become “personally Agile”. Agile is more than just a methodology – it is a vision, a way of thinking, a lifestyle and even an ideology. Typically, the senior managers defer the ideology to their staff. They are driven by the expected benefits of Agile implementation.
What they don’t understand is that in order to become Agile, an organization needs to go through a very serious transformation, not only in the organizational structure and delivery methodology, but also in people’s minds as well as role and responsibility definitions. In a pure Agile organization, project managers loose a significant portion of monitoring and controlling mechanisms. They also give away most of their formal authority. The decisions are now delegated to the team members, and the PM (or a scrum master) is just an observer and a coach. Teams like this approach because it supports the long-going “leave me alone” working style that many developers prefer when it comes to project management. Basically, decision-making based on professional subject matter expertise overrides decision-making based on project management education and experience. That model does not always work perfectly in real life. Yes, there is a fair amount of professional team members in every organization that are so good at what they do and so responsible when it comes to their daily routine that they can manage their tasks better than a project manager. Moreover, they clearly see task dependencies and understand how their own task may impact the work done by other teammates. But there are many other specialists that are good at what they do, but never want to see the big picture and never thought they would be asked to do such. Those individuals also prefer the “leave me alone” model; however they cannot provide viable commitments or make quality prioritization decisions.
Once the senior managers realize that, they start talking about some “mixed models”, like scaled Agile. Indeed, this helps them to take advantage of Agile’s best practices (value-driven delivery, better risk management, flexibility on project scope, and many others), and at the same time, to preserve the management control by keeping the existing work frame at least at its high level (preserve the “building”, just rearrange the “workspace”). Well, to me, it looks like a more viable model.
Indeed, how often have you seen a successfully established PURE Agile organization?
Dmitry Tsitrinel, PMP®, PMI-ACP®