An agile project is a temporary endeavor undertaken to create a unique product, service, or result, in which requirements are not clear at the beginning and must be progressively elaborated from the continuous stakeholders’ feedback (=value) who attend to project reviews to see working product increments regularly.
In an agile project, after each iteration review, project stakeholders openly state their thoughts on the increment they’ve just seen. The product owner uses this feedback to validate requirements –in agile we prefer the term user story– or to reduce uncertainty. This way of moving on projects is called «value driven lifecycle».
For those projects in which requirements can be agreed early on, such as engineering and construction projects –a.k.a. EPC projects– following a value driven lifecycle is considered a methodological flaw. The correct way is to follow a plan driven lifecycle –a.k.a. predictive or process driven lifecycle– consisting of agreeing on requirements in the first place, and based on that, elaborating a scope baseline to estimate the schedule and cost baselines, to finally get a project management plan, including the rest of project management knowledge areas: quality, resources, communications, risks, procurement, and stakeholder management.
When project requirements are cannot be agreed upon initially, given the huge uncertainty at the beginning, quite usual on software projects, it is considered a methodological mistake to follow a plan driven lifecycle. In this case, the correct way is to follow an agile lifecycle –a.k.a. adaptive, change or value driven lifecycle. First, we decide how long the project is going to take, and also the cost of a stable team, and then we divide the project into sequential releases to be closed in about 2-3 months. Inside each release, we follow sequential iterations taking the same duration –timeboxes are typically 1-2 weeks long– ending up with a demo to stakeholders of the new product increment. Stakeholders’ feedback allows us to validate old requirements and estimate the new ones. We can say the scope is progressively elaborated.
Any project may apply an agile lifecycle or predictive lifecycle in any particular phase or release. When that is the case, we say the project is following a hybrid lifecycle.
Professional project managers are usually proficient on predictive and agile project management methodologies. They are supposed to have a practical knowledge on tools and techniques to get any project to meet the project management goals, mainly to finish on time and on budget. Obviously, there are many factors causing the project do not deliver the value or do not meet the project management goals. Then we say the project is a failure and the project manager is usually considered as the prime responsible. Good project managers document failure evidence not at the end of the project or phase, but on each project review, so that everybody may anticipate potential issues and get involved to find corrective actions before is too late.
Most of the times, it is unfair to blame the project manager as the only accountable of the project failure, but managers think the other way around: managers usually want us to get the blame.
Managers want a PM on top of the project to get somebody to blame if project fails 🙁
When you know this is the name of the game, then you play better. Professional project managers want project review meetings and project status reports. These are our tools to report how the project is doing, but also to get project steering committee members engaged: we want to involve them in the problems and seek the solutions with them. If we do like this, everybody understand the project is own by the performing organization, not by the project manager. The project manager is not the only one to blame, anymore.
No rules for Agile Projects?
Whenever managers authorize a new agile project in the organization, a kind of cognitive dissonance come to their minds:- On the one hand, they want the project meets the management goals and deliver the expected value. That is, they want the project on time, on budget, and meeting the project requirements, the same as any other project.
- On the other hand, they know the team should self-organize. Team members take their own decisions and, when they have any doubt, they should ask directly to business users. So, what’s the point of having a project manager in an agile project?