How Agile affects project managers

In this article’s context, an enterprise refers to one that software is not its main product, rather software plays a supporting role. A software enterprise might be running its projects quite differently. 

How agile is affecting project managers

With Agile becoming more popular, the role of a traditional project manager will undergo significant changes. 

To understand this, we need to look at the anatomy of an agile team. 

 

Agile promotes a self-organizing team consisting of a scrum master, product owner, devs and QAs. In this self-organizing team, many of the traditional project manager’s responsibilities will be undertaken collectively by the team. 

• Planning: There is much less up-front planning in Agile. Planning will be deferred before the start of the iteration, PO will decide the next batch of most important user stories to be worked on for the next iteration. The whole team will break down user stories, estimate their sizes and schedule them accordingly.

•   Project status tracking and reporting: this is built into the Agile practices, and is generally less formal. For example, the daily standup meeting and burn down charts make the project status transparent.

• Resource planning: In an Agile team, the primary members of the team are dedicated for the duration of the project, there is less need to do resource planning and allocation.

•   Drive improvement: Agile has a quick feedback loop and stresses on learning, at the end of each iteration, the team does a retrospective to reflect the good and bad of the last iteration, come up with improvement ideas and commit to them.

This doesn’t mean that with Agile there is no need for project managers. To understand why, we need to consider the disadvantages of Agile and the reality of an Enterprise.  

Disadvantages of Agile

I do not want to offend the enthusiasts who claim Agile is the best thing that has ever happened and it can cure any dysfunctional team. To avoid arguing in this regard, I admit the power of Agile and humbly propose that the way Agile is implemented today has the following disadvantages:

Local optimization

There is a risk that Agile teams will make local optimizations at the expense of global optimization. Agile teams strive to react to changes quickly, but not all changes should be welcomed. For example, the users for who an Agile team is working with propose a change, which will help out their work efficiency, but if examined in the whole value-stream, this change might negatively impacts other parts and result in the overall loss.  The Agile team might be doing Agile practices perfectly, but they might not be situated to perceive the whole value-stream and understand their decisions on the whole value-stream. 

Lean has a principle called “mapping the value-stream” which can be implemented to identify the big-picture value-stream (told you, I acknowledge the power of Agile), but it would be beyond the scope of an individual Agile team, some process should exist to support it. 

Unpredictable project schedule and cost

This is not necessarily a bad thing. Traditional project management strives to deliver the scope within the cost and schedule, which we all know has many issues, those issues has led us to Agile. Agile, instead of striving for “doing the project in the right way”, strives for “delivering the right product”. Agile has short iterations, at the end of each iteration, users review and provide feedbacks. Based on the feedback, Agile teams make adjustment to scope and schedule, which will inevitably lead to schedule and cost changes. 

Changes on schedule and cost will also happen because of the following:

• Up-front planning is usually limited, but it doesn’t mean there should be no up-front planning. Without sufficient understanding of project requirements and risks, the project schedule and cost might be way off.

•  If there is no adequate up-front architectural design, requirement changes might require extensive technical rework, ramping up project schedule and cost.

One might argue that the above causes for project schedule and cost deviation is because of bad Agile executions, which might be true, but pointing this out without suggesting a solution doesn’t help running projects. Agile methodology is not prescriptive, it won’t tell you what is the sufficient up-front planning and design. For an enterprise, it helps to have some support structure or process. 

Enterprise reality

Don’t fall into the trap “if all you have is a hammer, everything looks like a nail”. Just because Agile is great, doesn’t mean you should run every project as an Agile project. In reality of an enterprise, it will be hard to find pure waterfall or pure Agile projects, most projects will be run somewhere between the two extremes. 

 

When choosing a project management approach, the factors that should be considered include:

• The uncertainty of requirements. Generally, the more uncertainty of requirement, the more likeliness of users changing their minds, the more Agile the project approach should be.

• The flexibility of cost and schedule changes. If there is rigid required on cost and schedule, strict control has to be exerted.

• The teams’ capabilities. Agile is really really hard. For me personally, I am still trying to figure out two things: how to do architecture in Agile and how to test in Agile. Agile calls for more high-skilled people. Just because you organize Scrum teams and have all the ceremonies of Scrum (daily standing up, story grooming etc) doesn’t mean you are running Agile – in fact, a rigid-running Scrum is probably the worst way to start Agile.

• The regulatory requirements. If there are strict regulatory requirements, you might need to run the project in phases and have adequate documents.

• The scope and complexity of projects. The more complex a project is, the more up-front planning and designing is called for.

• The willingness or capacity of user involvement. If you can’t find users that are willing or able to participate in each iteration, you might need to come up with comprised ways to engage users.

• The commitment of upper management to bring about the culture changes that are necessary for Agile to flourish. Agile is a mindset shift, from following the plan rigidly to embracing changes and failures. Upper management must understand what they are walking into, Agile is not a silver bullet that will magically cure any dysfunctional project, to make Agile work, they need to know the trade-offs between Agile and control, they need to put investment to train people, they need to break up the organizational silos to enable transparent communication and value alignment, and they need to learn to celebrate early failures.  

For example, upgrading a server usually shouldn’t be run as an Agile project, it has a deadline: on the next weekend, upgrade must finish; a thorough impact analysis should be performed to understand the who and what will be impacted; an emergency plan should be formed in case of upgrade failure; success criteria are usually clear. 

On the other hand, a project that emphasizes heavily on usability might benefit from a more Agile approach. 

In a board term, choosing different project management approaches for different projects is more in the spirit of “being Agile”, rigidly following agile practices without consideration of context is definitely not. 

The disadvantages of Agile and the reality of an Enterprise do call for experienced project managers, but they will play a very different role than the traditional project managers.

To understand this, we first need to understand the core value of Agile. 

The core value of Agile and its implication

Agile has short iterations, in each iterations, the most valuable user stories are worked on; at the end of the iteration, users review the work and provide feedback. Based on the feedback, agile teams reprioritize the backlog, reexamine features and start a new iteration. 

 

The whole point of approach is to make sure teams are doing the right thing for the users, the meaning of the right thing is defined by users. Users are able to review the work early and make changes if what they see doesn’t satisfy them. 

Compared with the traditional project managers, they are focused on making sure the scope is finished within schedule and cost – the famous triangle:

 

The core value of Agile is that it is “value-oriented”, compared with the traditional project management which is “process-oriented”. All companies are jumping onto the Agile bandwagon with mixed results, regardless if nothing sticks, “value-oriented” will stick, because what CEO doesn’t want to hear “we are using a methodology that will create values earlier?” 

The implications for a project manager are:

• He needs to focus on values. It doesn’t mean that he should forgo schedule and cost, because values are seldom absolute, he needs to consider many factors to understand the optimal values.

• He needs to have a systematic thinking to know how to maximize the global values instead of achieving values locally.

• He needs to understand how changes impact values.

• He needs to find a way to consolidate data from projects run in different ways, and design reports that are consistent and easy to understand. It will be confusing to show reports saying this project has done 300 story points and that project is now in the QA stage, somehow, he needs to convert the data into a consistent form that are easy to understand for all stakeholders. 

•  He needs to exert a certain level of control without impacting teams’ agility.

• For him, the project might not end on the day when it is released, he needs to continue to monitor and gather values of the project in order to justify its existence and future investment.  

Since the role of a traditional project manager is weakened significantly in an Agile team, the above implications could essentially mean that project managers need to move up to program or portfolio managers. And with that move, comes other responsibilities, such as:

• Project selection

• Project prioritization

• Overall resource optimization. 

In short, an enterprise project manager will be facing a more complex and probably more chaotic environment, his goal, while before was to make sure projects are completed within the time and the budget, will be changed to create maximum value, which requires a higher degree of systematic thinking.