What is an Agile Project Manager?

No, really, what is it? What do they do?

I have managed PMO’s, teams of project managers, and I have been a project manager myself. I have even served as a volunteer instructor of the PMP course leading classes and teaching project managers the material they need to pass the PMP exam. Later, I developed an interest in Kanban, Scrum, and agility in general. This led me to study Lean concepts extensively and understand the causes and effects that all of these agile working techniques were trying to leverage. I am pretty well-versed in what a project manager does and what agility is about and what it is based on.

And yet I don’t know what an Agile Project Manager is supposed to be. I decided to take my question public on LinkedIn and ask people what this job entails and uncover whatever it is that I don’t know about why a company would think this job is useful and what tasks it performs.

A lot of the descriptions I received were pretty vague telling me that it was a PM who understood agility and did their project management job in a way that encouraged agility. The more specific responses were typical project management work: scope, schedule, cost, status, and leading meetings or work.

Empiricism

The gap between project management and agility is VUCA. If we accept that developing products is knowledge work, then we are accepting that VUCA dominates our experience. VUCA stands for:

• Volatility – change is continuous and the rate of change is increasing
• Uncertainty – we cannot see the future.
• Complexity – things are far more interconnected in surprising ways that what is apparent on the surface
• Ambiguity – we cannot see around us very far or very clearly

Empirical Product Development is based on the acceptance of VUCA. The process is simple: form a hypothesis, run a test, create transparency, inspect what is made visible, and then form a new hypothesis and adapt. Transparency, Inspection, and Adaptation are at the heart of empiricism.

Transparency

The basis of empiricism is transparency. Transparency means that we can see what is going on – both with the product and our process for creating it. Everyone receiving and doing the work is able to inspect what we produce and how we produce it, and this allows a continuous improvement cycle to develop.

Psychological Safety

The basis of transparency is being able to make the truth visible without getting in trouble or otherwise feeling threatened or in danger. We can’t improve things if we cannot say what is truly going on. This forms the basis of decentralizing decision making in organizations and empowering teams to manage themselves.

The Effect of Empiricism on Project Management

Because empiricism is at the heart of agility, the following things become true:

• An team works best when self-managing rather than managed meaning they are given a goal and some guard rails to obey, but otherwise they make their own decisions
• The team decides the process, so no PM enforces it, and there is no gatekeeping of the team’s activity requiring sign-offs or contractual type documents
• The team works in small, iterative, incremental chunks, reviews the work and the process, and then makes a new short-range plan, so there is no long-range plan other than a very high level roadmap and a desired business outcome

How does this align with what a project manager does? How does the project manager ensure scope is completed when the scope is decided as the team progresses and the team is working directly with the stakeholders? How does the project manager manage the schedule when it is only a few days long and the team is using completion of small work, not percent complete of big work, to determine progress? How does the PM manage cost when the team is a fixed-size cost that doesn’t change?

In an organization that truly understands empiricism and how agile teams work, what does a PM do?

The answer lies in the understanding the organization has about agility. In most organizations, agile working techniques have been deployed at the lowest levels of the organization and only in the software development departments of the technology division. This is the most common implementation, and it often gives negligible results.

As a result, most organizations are still running the project model, not the agile model, and teams are merely going through the motions of using an agile framework. Many of us call this Zombie Scrum: a team that does the events, has the roles, and uses a backlog, but which produces none of the benefits of Scrum because the developers are not using empiricism on their process nor on their product. The scope is predetermined, there is no intention to do Ship and Learn, and work is still being funded based on estimation.

Enter the Agile Project Manager – someone who understands Scrum or Kanban at least at some very basic, beginner level – who then can try to mitigate the disconnect between a project working model and a team attempting to use an agile framework without empiricism.

Summary: There is no agile in such an organization. There is just Zombie Scrum. They have adopted the theater – a pattern of meetings, roles, and templates. There is no empiricism.

Aren’t These Equally Valid Approaches?

The project model and the agile model are not equally valid in the same contexts. In a complex environment where VUCA is high (most software development)…

• Planning. lf we accept VUCA, then the project model creates a lot of wasteful documentation and meetings that are likely to be scrapped later on. Scope and plans cannot be determined in advance in any detail, because the plans will necessarily change. Projects run in a VUCA environment have many change requests to adjust the schedule, scope, and cost as the project proceeds, but this is a slow, bureaucratic, ponderous process to use to manage change. Large plans in advance are therefore waste, because much of their content will be revised or tossed out.
• Scope. Large scope in advance ignores potential learning from frequent release and customer feedback. Large scope is also waste, and is best managed just-in-time.
• Schedule. Long-range planning is just as wasteful as large scope in advance. What if the first iteration proves that the entire roadmap is garbage and we need to cut bait and run? Why plan beyond the point past which we cannot see?
• Cost. Without large scope and plans in advance, what are we budgeting for? Why are we approving big plans that will change as if we can predict their cost through estimation (guessing)?

The project model works better where VUCA is low, such as building an office building, residential development, ship building, and other repeated, physical construction where the steps are known and the second ship needs to be just like the first one. In a low VUCA environment, we can pretend as though we know the future, and the future will mostly be kind to us. Variability will be far less than in a high VUCA world.

An attempt has been made to model a world where there is a continuum of work from simple, repeatable, predictable work and unpredictable, chaotic, high-VUCA work. It is the Cynevin Sense-Making Framework. Pronounce it like “Kin-evin.” It rhymes with Kevin.

Project managers are most successful and useful in the area of “obvious.” Best practices are known, monitoring and controlling the process is important. We have done this before many times and it is known. Where things break down is in underestimating VUCA and assuming that most work is obvious just because it looks like previous work.

So You’re An Agile Project Manager

I am sure that everyone with this job title is doing something a little different from someone else. You can make yourself more successful by being aware that research into Lean Manufacturing and Management has led to some definitive conclusions about how people are most productive and work is best organized to ensure that things get done with quality. Some things to think about as you go about your day:

• Large batches of work increase complexity, risk, cost to build, lower quality, and decrease value delivery. Encourage smaller batches of work. Make your projects smaller and smaller, if you can, until finally work items are very small and are moving independently rather than in releases (batch work).
• Meta-work is generally wasteful. Creating status reports is capacity that could have been used to implement solutions. Find out how to passively learn things without using capacity.
• Functional silos (teams with a single function) cause slow-downs because work queues at the entry point of every silo and team. Teams should be cross-functional and avoid handing work outside the team whenever possible working toward an architecture and organizational structure where this is minimized or even eliminated. Anywhere you see a centralized organization that everyone has to use, you can safely bet that organization causes delays simply by existing. Decentralization is the better approach unless a function is in infrequently needed.
• Time to Market is a critical metric. In fact, I recommend adopting all flow metrics, including cycle time, WIP, throughput, and item aging. If it takes 180 days to deliver a small feature, that is a huge problem to solve. Don’t tolerate that. Work with the goal of daily releases becoming the norm.
• Long Planning Horizons are wasteful, as are big plans up front, big scope up front… Decide on a small proof of concept and go. Make a small improvement and go. Small moves, small bets, small feedback, and small pivots as you learn.
• The process only improves if people own it. Don’t expect continuous improvement if the process is dictated and must be followed. Empowered teams make their own process. Don’t be the enforcer. Be the champion of the idea that everything doesn’t need to be standardized and centralized. Pursuing economies of scale saves money up front but loses it every day thereafter on waste caused by queueing.

That’s what I would do if I was an Agile Project Manager.

Note that throughout the article I do not use the term “waterfall.” Waterfall is a very specific thing that is not implemented in many places any longer. An organization can still have a wasteful approach to doing work involving documenting, estimating, and funding large batch work (projects) without requiring all projects queue into releases and march through the system one phased-gate at a time. Most project managers have not seen any system operated in this way in many years. Thus, I use the term “project management” where improvements to a product are batched together into a single work entity that has an owner where the assumption is that all or most of the scope will be delivered and people falsely believe they can predict delivery completion without many changes and adjustments along the way.