If you have been involved in project management or change delivery even for a short time, you will probably have heard the reference to “agile” and “scrum” in respect of delivering change.  This is in place of the traditional “waterfall” approach.

Before going further, below are the definitions taken from Wikipedia:

Waterfall Project Management

“The waterfall model is a sequential (non-iterative) design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance.

The waterfall development model originates in the manufacturing and construction industries: highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Because no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.”

Agile Project Management

“Agile management, or agile process management, or simply agile refers to an iterative, incremental method of managing the design and build activities of engineering, information technology and other business areas that aim to provide new product or service development in a highly flexible and interactive manner.”

Agile sprint board

While each approach has merit, many organisations and employees have leapt towards agile as they see that it can provide benefit quickly due to the iterative approach and that functionality can be released on an ongoing basis.  As opposed to waterfall that can mean that the deliverables and benefits are only available at the end of phase or even project.

My opinion is that each are just tools in the project manager’s / PMO’s toolkit.  It is important that the right tool is used for the job.  Today there are many projects using agile when waterfall would be better and vice versa.  That is a topic for another post.

Today I want to cover the impact to the PMO.

PMO – the agile challenge!

There are many people / organisations who see the role of the PMO to define and implement strict standards for the management of projects.  The rationale being that by implementing standards you increase the predictability on how a project is managed.  In turn meaning it should reduce the chance of mistakes being made as there are checks along the project lifecycle ensuring key project artefacts are created and signed-off.

Progress is tracked on an agreed plan.  Status reported on a regular base.  Scope managed through change request and full visibility provided to stakeholders.

Those practicing agile will say that there is no place for these PMO practices in an agile environment.  There is no requirement documents, no plan and reporting is dynamic.  This is all well and good.  It is even important as a core principle of agile is to allow the project team to make rapid progress with minimal governance overheads.

However, just because senior management have been sold and bought into the benefits and value of agile, it will not stop them wanting to have oversight of progress.  Or in simple terms, they want to know that the investment of budget is achieving the required outcomes.

Now some may say, “that is OK they can attend the daily stand-up” to get an update.  The stand-up is where the team meets every day to discuss priorities and identify challenges.  Good idea.  However, the reality is that the more senior the sponsor, the less time they will have available to drop by the daily scrum for an update.

The Product Owner may find that they receive frequent requests from stakeholders demanding updates.  While important, this can take up a lot of the Product Owner’s time meaning they are not focused on the project.

It may be possible to make the different tracking tools available to the sponsors:

  • Product Backlog – list of all of the tasks and requirements needed for to achieve the outcome.
  • Sprint Backlog – subset of the Product Backlog of all of the items being progressed in a sprint.
  • Burndown Chart – chart showing the progress of items delivered against how many should have been delivered.
Example agile burndown chart

However, this is only helpful if the recipients understand agile and can interpret the information.  The reality is they probably will not.

The hard truth is that there must be a mechanism for the status to be communicated to all of the relevant stakeholders.  This is a particular challenge where and organisation may be running both waterfall and agile projects at the same time.  Senior management will still want a standardised view.

This is where the PMO continues to play an important role.  In the coming weeks I will look to cover how the PMO can help solve The Agile Reporting Challenge.