Many people think that you can’t benefit from agile if the rest of the organization hasn’t changed. That is only true to a small degree, much less than you would think.
In essence, the only organizational change that is a must is to agree that projects carry a level of uncertainty.
I hear you thinking: “That’s just common sense, everybody knows that!”. Indeed! Everybody knows it, but many refuse to acknowledge it.
It is essential that your company’s leadership agrees on this. This is the only way to start managing projects in an agile fashion, which is based on:
- Regular feedback
Two things that are essential to keep a project on course by making decisions on a regular basis.
If on the other hand, your leadership does not acknowledge the uncertainty of projects, projects don’t need feedback cycles or transparency, because they are cast in stone and will be delivered as planned anyway.
If they do acknowledge this, you don’t need to change much to the current organizational processes for starters. If you’re a project manager in an organization that manages its projects the way PMBOK prescribes, you’re probably sending performance reports to your stakeholders or hosting monthly project boards.
Because this is a model of management by exception, you’re only supposed to bother them with details when things go wrong.
So typically, your performance reporting consists of:
- Status reporting
- Progress reporting
PMBOK contains 5 Controlling processes:
- Scope Change Control
- Schedule Control
- Cost Control
- Quality Control
- Risk Response Control
The output of these processes is the input of your performance reporting. Sounds very heavyweight, doesn’t it?
In this blog post I’ll show you how you can easily keep your performance reporting in this format when you’re dealing with an agile project.
1. Scope Change Control
This process tries to structure the way scope changes need to be dealt with.
Typically, the work breakdown structure (WBS) acts as the project’s scope baseline. A change request needs to be formally approved in order to be included in a new version of the WBS, so that a corrective action can be included into the project plan.
A process like this is critical when you’re working in a fixed price, fixed scope contract. Each change that was not part of the contract needs to be tracked, approved and funded. That’s common sense right? If you’re contractually bound to deliver a scope for a fixed amount of labor, you want to make sure that the scope is well-defined and you only spend time on what’s in that contract. All additional work might make sense for a user, but will not be paid for and therefore will endanger your project success.
In an agile project, the concept phase of a project is significantly smaller. For various reasons, it makes more sense to start with a high level scope description and high level project plan, which we will expand later through learning and feedback.
This means that it is much more difficult to decide whether or not something is a change. Actually, a change is treated differently. Where in our classical Scope Change Control process, a change is treated as a danger, in an agile project it is treated as an opportunity. Learning or feedback have emerged the discussion of a potential change, which is then weighed and the change enters the product backlog at a specific place or not at all.
In my opinion, it is still healthy to report about Scope Change. Because in an agile project you’re also working with constraints.
Maybe you need to realize a certain minimum scope, maybe you have a maximum budget or maybe you need to release before a certain date. I call this the primary project focus. The one thing that is most important. The one thing we hate to tamper with.
Instead of reporting on the list of change requests against the WBS, in an agile project you can report about the evolution of the size of the product backlog. By definition, content is variable to a certain extent, because we started with a high-level scope description.
So it’s no surprise that the scope is changing. What is most important is to keep an eye on the total size of the product backlog.
Because you don’t have unlimited resources, the scope can only grow so far. If your product owner can compensate the growth by removing other pieces of the product backlog, no action needs to be taken. But in some cases, the product backlog grows too much. This is a case when management by exception takes place. The project board needs to take a decision. Additional funding, yes or no? Altering scope, yes or no? …
This may sound bureaucratic to most agile enthusiasts, but it matches the idea behind the product owner role. She gets the mandate to represent all stakeholders and take decisions about the product, until a certain level. Within the dimension of scope, a product owner may get the mandate to take decisions as long as all 6 epics are covered and the total amount stays lower than 300 story points.
In an agile project you can report about scope change with the use of a burn-up chart.
As you can see, the red line represents the total size of the product backlog. As it evolves, you can plot a new point after each sprint. This shows the evolution in the product backlog size to the project board. So besides the actual total, they can also see the evolution.
This seems very high level, which it is. But remember, the project board manages by exception and is not interested in the detail evolution of the product backlog. It has given a mandate to the product owner to manage that.
What data do you need to create this graph in excel? This is what my data table looks like:
The burn-up chart can also be used for reporting about the other PMBOK Controlling processes, but I’ll leave that for next blog posts.