Change is Good for Agile Projects

Kelley Hunsberger interviewed me for her article “Change is Good: For agile projects, redefining scope isn’t such a creepy thing”. It is great to see agile thinking in a mainstream project management magazine such as PM Network. And the article was a very nice little summary of why it is good to embrace change.

I took the opportunity to reiterate some of the points I’ve already made on Agile Project Scope and Agile Change Management, namely that all projects experience changing requirements and it is better to embrace this than fight it. For example legitimate sources of change include:

  • The customer learns as they see working functionality emerging of the development effort.
  • The technical team is also learning as they discover what works.
  • The environmental context might also dictate changes, such as changes in the market or legislation.

Ignoring any of these sources of “scope creep” would be foolish.
Continue reading

Agile Project Monitoring and Control

No battle plan survives contact with the enemy

Field Marshal Helmuth Graf von Moltke

Life is what happens to you
while you’re busy making other plans

John Lennon

Agile Project Planning tells us what we expect to do, but, to paraphrase the quotes above, plans often turn to custard. The job of the Agile Project Manager is to guide the team to successful delivery despite the challenges the world throws at the project. This article is about monitoring the project against the plan and intervening when we notice things going off track. In particular it covers Traditional Project Monitoring & Control, Agile versus Traditional Monitoring & Control, Agile Project control, Agile project metrics, Agile Project Reporting, and Agile Project Monitoring.
Continue reading

Agile Change Management

My background is running Agile projects for external customers in the context of a contract, often fixed price.  That influences my focus on good project management and specifically change management. Change Management is the mechanism to combat scope/feature creep.

Within the Agile world scope change is expected and time is considered more important than functionality. So if something has to give to allow change then functionality/scope loses and time wins. To do this the customer must make Requirements Trade-offs. The Customer directs development in Timebox and minor changes are just accepted. Big changes are handled different depending on whether it is a change to the Release Plan or Timebox Plan.
Continue reading

Agile Project Planning

No battle plan survives contact with the enemy

Plans are nothing, but planning is everything

Field Marshal Helmuth Graf von Moltke

I believe that Agile Project Management provides certainty of delivery. Planning is what lets us answer the question “When will you be finished?”. Planning is, however, just the start of the process. As Moltke pointed out planning is more important that the plan because once you start the project you’ll find the plan is wrong and you have to adapt. All plans need revisiting and you will have to use Agile Project Control, Agile Change Management, and Agile Risk Management to get the promised certainty of delivery.
Continue reading

Agile Project Scope

According to Wikipedia: Project Management project scope is:

The overall definition of what the project is supposed to accomplish, and a specific description of what the end result should be or accomplish.

We can talk about what is “in-scope”, i.e. what the project is meant to delivery, and what is “out-of-scope”, i.e. what won’t be delivered.

Typically the project scope is a subset of the scope of the product under development.
Continue reading

Agile Risk Management

Risk management is about identifying, addressing, and eliminating sources of risk before they become a threat to the project. This article outlines traditional risk management, how Agile is a risk mitigation strategy, and how to do Agile risk management.
Continue reading