Which are the agile project management's disruptive features?

Some years ago, an expert program manager told me that agile project management was like sex seen by teenagers. Everybody keep saying that he does it, just a few really do it, and almost anyone does it properly.

I do not know if this was a sentence of her own, or if she had read it somewhere. I can recall that such a judgment, at the time, had seemed to me a little bit too harsh. This before I got involved more deeply in agile methodologies. Now I think that she had been far too indulgent. 

In my experience, what many professionals seem to identify with agile methodologies are just iterative planning, light (or evanescent) documentation, and no strict prescriptions.

These beliefs are wrong. The listed characteristics do not exhaustively describe nor define agile project management. What these so-called agile advocates preach is flexibility, not agility and believe me, flexibility is the wardrobe of hell.

Iterative planning is a part of agile project management, but it also used in many methodologies and frameworks that have nothing in common with agile.

Documentation is so important in agile project management that it is mentioned in the agile manifesto. At the same time, a too cumbersome quantity of documents could be to the detriment of any project managed in whatsoever way.    

Many agile project management methodologies are extremely prescriptive and rigid. As an example, Scrum, one of the most known agile methodology used in software projects, prescribes the team to perform a stand-up meeting each day, like first thing in the morning. Not exactly flexible, do not you agree?

So, what are the characteristics of agile project management, that are disruptive, if compared to standard project management methodologies and framework?

The iron triangle

A project is normally subject to multiple constraints, of which the most famous are Time, Cost, and Scope.

Time, Cost, and Scope make up the so-called “Iron Triangle” and are used, and sometimes abused, as indicators of a project’s success. 

Personally, I believe that more constraints should be included and taken into account, in evaluating a project’s performances. Maybe this argument will be the subject of a future post. Nonetheless, Times, Cost, and Scope are a well-known trilogy in project management and often the only three tools that a project manager can leverage to control a project. 

The Iron Triangle can be deformed to accommodate for project changes or execution deviations from the referenced baselines.

In traditional project management, it is usual to modify Time and Cost as a first choice. Contracts define Scope strictly, and a change in Scope may result in endless and painful negotiations and litigations. 

Therefore, the situation is “fixed” Scope and “variable” Time and Cost. 

Agile methodologies choose an opposite approach.

Therefore, the situation is “fixed” Time, “fixed” Cost, and “variable” Scope.

Commas remind us that this is just one possible approach, that fixed and variable are not strict, and that changes in certain situations can affect all the given constraints.

Let me push this a little further. Agile methodologies are based on the concept of a variable Scope.

Changes in scope are the way in which agile methodologies try to maximize value for the customers, in response to projects’ uncertainty and ever-changing environments.

Scope creep

Changes in scope are the way in which agile methodologies try to maximize value for the customers, in response to projects’ uncertainty and ever-changing environments.

So is Agile project management the glorification of the ever-despised Scope Creep?

No. It is not.  It is not because Agile project management implies a change in perspective.

The scope does not change. The Scope evolves. 

Of course, the scope cannot be left growing out of control; Scope evolution must be continuously monitored and controlled, to ensure that it will provide the greatest value to the customer’s needs. 

To achieve this objective, it is imperative that 

• Customers actively participate in feature prioritizations with the team. Customer must be continuously and extensively involved in the project.
• Planning is iterative and frequent (2/4 weeks).

Servant leader and team accountability

The figure of the project manager is a little bit different in agile methodologies. The project manager assumes the role of a servant leader, who protects the team from interrupts and distractions, always trying to ease the team’s efforts, removing obstacles and solving problems.

The project manager is not the key decision maker since decision are made at the team level, and the whole group shares accountability for them. Some Agile methodology even refuse the term “project manager”. 

The team, not the project manager, is accountable for success or failure.

Relationships building within team members and the team and the customers are at the very core of every agile methodology.

Self-organizing team

From the two previous sections, it follows that an agile team must be self-organized.  

No manager say what each member have to do, nor when he/she has to do it. The team shares any organizational decision, with the project manager as a supervisor.

Obviously, there is the need to have good processes and practices in place, to avoid that this great possibility could lead to anarchy.

People

Not everyone has the characteristics needed to fit in an Agile team, so the construction and the development of a proper Agile team are quite difficult tasks.

We do not need superstars, we do not need people that want to emerge above the others, we just need comparable performers, with real and authentic aptitude to team playing.

A project, in Agile methodologies, is seen as a whole effort made by the team. Any member of the team can participate in any work package (even if agile practitioners do not love this term) and work on any deliverable.

Consequently, so-called “T people” must compose an agile team. 

That is to say, we need people highly qualified in a particular area, but capable (and willing) to participate in work packages even outside their specialization zone.

Conclusions

In this post, we have presented the characteristics that, as far as I am concerned, characterize Agile project management. 

Agile project management is not a silver bullet; it is well suited just for some kind of projects. 

Agile methodologies, in my opinion, tend to perform well on projects with some of these characteristics

•    Small size (Cost and Time)

•    Small teams (no more than 8/10 people)

•    Initial scope not clear

•    High uncertainty

•    Many risks in different areas

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.