The Mindset Change for Agile Project Management

Last year I wrote Project Managers Don’t Get Agile for the ProjectManagement.com website. I also wrote The Myth of the Project Manager in Agile. As I have thought about it since then, I see that part of the PM’s challenge comes from the mindset change that is required to understand agile. If you are a great project manager, chances are that your mental models limit your ability to understand and implement Agile.

Project Managers Only See Projects

I’ve spent most of the last 10 years training and coaching individuals and teams to help them understand and leverage agile approaches and I’ve seen it happen again and again. Project managers tend to see the world as projects. The better the project manager, the more difficult it is for them to think outside the “project” paradigm.

This is sometimes called the law of the instrument:

If all you have is a hammer, everything looks like a nail

Back when I was a practicing project manager, my skills, and way of thinking served me well in most situations. I was great at organizing our family’s annual 4th of July party or planning a cross-country trip. But there were also times when my project thinking was over the top and my wife would tell me that I should stop trying to “project manage” everything.

Projects are one way to get important work done, and it worked great for us in previous times when there was less global competition and the rate of change was low. It doesn’t work so well in today’s environment where competition is fierce and change is constant.

In today’s competitive environment, seeing everything as a project will limit our flexibility and how we solve problems. Projects are unique and temporary.

We carefully plan projects in advance to identify the scope, timeline, and budget needed to achieve an outcome in the future. We organize teams of resources to complete the work. We execute the work, and we monitor and control our resources and tasks to a successful conclusion. Then we close out the project.

Rather than seeing Agile as a mindset and culture change that fundamentally alters how organizations view, plan and complete work, project managers constrain Agile to an alternative project lifecycle.

They miss the point of what agile really means, and they miss out on the opportunity to gain true business agility in a rapidly changing and highly competitive business context. True business agility is achieved by transcending the project mindset, changing the culture, and rethinking the work of the organization.

Below are some specific ways in which the project mindset will limit the ability to leverage Agile, and what it would mean to embrace an Agile Mindset.

Limitations of the Project Mindset

#1 – My Goal is to Get This Project Done on Time and On Budget

Project managers like missions. They are typically measured on whether they delivered their project on time, on budget and on scope. Unfortunately, these measures don’t necessarily correlate to the business goals and often lead to short-term, suboptimal thinking and approaches.

Delivering a project on time, on scope and on budget is a short-term goal that assumes (or ignores) the achievement of business value. Most organizations report on the timeline, budget, and scope for projects and few if any follow through to see if the project delivers the promised business value. The goal should be to deliver business value!

With the goal of delivery against the triple constraints, project managers and teams are often incentivized to sacrifice quality to deliver that scope within budget and timeline constraints. Forced to cut somewhere, they take shortcuts, reduce testing, and introduce technical debt to meet the triple constraint.

This push to achieve timeline and budget goals at the expense of quality is short-term thinking that results in huge costs; immediate production support costs, higher maintenance costs, and higher risk and fragility of the production code.

Pursuing individual project delivery goals also results in local optimization, rather than overall optimization. Most organizations have multiple projects running at the same time.

Project managers are measured on whether they achieve their own project without regard for others. Good project managers will even beg, borrow or steal the best resources from other projects to complete their own project.

#2 – Projects Are Unique

One part of the definition of project is unique. We tend to approach each new project with a blank sheet of paper. We tend to assemble a special group of ‘fractional resources’ (see below) who have the partial availability and exact skills required to deliver this unique project.

Thinking of projects as unique prevents us from seeing the work of the organization as a steady stream of mostly similar requests. While each request may be for a unique feature or solution, each request can be satisfied by the development of some sort of solution.

The requests for features are not unique at all, in fact, they are a pattern that recurs again and again. So, getting a new request for delivery of a solution to a business need shouldn’t be treated as unique or a project. It is just another request, like the others.

Which means we don’t need to start with a blank sheet of paper. And we don’t need to assemble a new team who will go through Tuckman’s stages of development starting with the least productive stages of forming, storming and norming.

#3 – More Projects Started Means More Projects Done

There is a belief that starting more projects means that more projects will be completed, even if we don’t have enough people to staff all the projects. There is wishful or magical thinking that we can complete more projects than the organization has the capacity to complete.

Running all these projects concurrently doesn’t get things done faster, it slows all projects down and reduces the delivery of value. More projects in flight means less projects delivered. As they say in Kanban land, “Stop starting and start finishing”.

#4 People are Resources that Can be Fractionally Assigned to Projects

There is a role in most organizations of a ‘resource manager’ who tracks and assigns people to different projects. This task may be done by the department manager, or it may be centralized to a single resource manager across many departments.

The resource managers job is to keep everyone 100% busy and to maximize the number of projects underway. This is done through the assignment of fractional parts of each person to various projects – 50%, 25%, 10% or whatever.

As new projects are started, the resource manager reassigns the people who are already on projects to the new projects. This assignment of fractional resources creates an illusion that a lot of work is getting done. Trust me, it isn’t.

Treating people as “fractional resources” is dehumanizing. It is most painful for the best performers who can easily wind up assigned to two, three, or even four or five projects.

I hear horror stories from those best performers working on five projects at the same time. They say that they do nothing but go to project status meetings (or worse, daily standups!) for all their various projects. Ironically, the focus of those status meetings is the work not getting done.

Rather than sitting in meetings handwringing about work not getting done, how about cancel the meeting or eliminate the need for any one person to have to go to more than one meeting.

Less work gets done with fractional resources. Team members are continually shifting their focus between projects. Inevitably there is too much work and each team member is juggling multiple priorities and frequently overwhelmed. A common refrain is “just tell me what to work on”. Context switching and multi-tasking reduce individual effectiveness by as much as 40%. 

A negative side effect of using fractional resources is that each person on the team will be used for their primary skill only, whether that be java development, salesforce configuration or testing.

They don’t have the time or opportunity to develop other skills. This continued use of single specialty team members is self-reinforcing – the more you do it the more you will need to do it. Individual specialists represent key person risks and they limit business agility.

This approach also necessitates handoffs between specialty team members, for example, from business analyst to developer and developer to tester. Each handoff represents as much as a 50% loss of information. 

#5 – Projects have a Beginning and End

When we see the world as a series of temporary initiatives that start and stop, we miss out on efficiencies. There is a significant cost to starting something new and closing it out when it is done.

There is the cost of building a team, learning to work together, and fostering healthy team dynamics. As noted above, each team will go through Tuckman’s stages of group development from forming, storming and norming before they can be performing.

Most temporary teams formed with fractional resources will be stuck in forming and storming and will never become high-performing teams. Because they are on multiple teams, they won’t sit together and teams that don’t sit together are automatically 50% less productive than those that do.

For distributed teams, geographic and time zone separation will further undermine team performance. There is low buy-in, synergy, and team performance for these teams.

#6 – Project Scope is Monolithic

Another downside to project thinking relates to project managers being measured by timeline, budget, and scope. Though the individual features and deliverables vary in their contribution to business benefit, all features and deliverables are in scope and that is how the project manager is measured.

Delivery of all of the features that were in the planned scope at the beginning of a traditional project is guaranteed to result in building the wrong thing.

Studies have shown that delivering the planned project scope results in a waste of building unneeded features about 2/3 of the time. In other words, about 2/3 of the scope of a traditional project is unnecessary and goes unused in production.

This has been borne out by studies by the Standish Group as well as an evaluation conducted by Ronnie Kohavie at Microsoft who found that 2/3 of the features released in production did not achieve their intended business goal. (This story is shared in the DevOps Handbook).

When we deliver the project as a monolith, we invest a lot before we see any business value. Frequently, all the business benefit is delivered at the end of the project. The time from project idea to delivery of value is easily 9 to 15 months.

In many organizations, the annual budgeting process further delays the time between the identification of business needs and the delivery of the project and realization of the business value. I worked through this exercise with a team recently and we documented that on average, projects went from idea to delivery in 14 to 26 months.

A Shift for Success in Agile Project Management

To maximize the delivery of business value, we need to transcend project thinking and embrace an Agile Mindset.

#1 – Move from Project Thinking to Value Stream Thinking

If we step back and view the activity of the organization from a distance, we can see that there is a continuous stream of business needs or requests that are satisfied or delivered by groups of mostly technical people with cross-functional skills.

Each request may be slightly different, but combined they represent “work” that needs to be completed. This is the value stream of the organization. The value stream looks more like a factory than a bunch of one-off projects.

#2 – Focus on Delivery of Business Value

Shifting from thinking of unique and monolithic projects to a value stream is the first step. Breaking these bigger projects down into smaller requests or features is the second step. We can then prioritize these smaller requests by business value, and deliver each one to the customer quickly to get a faster return on our investment.

Working in smaller chunks reduces the amount of investment we have at risk. Teams will learn quickly and make adjustments. And if teams are going to fail, they will fail quickly. This is true business agility – the ability to deliver quickly, and to make changes quickly and cheaply.

As an example, consider two large projects (A & B) that each has five features. If Feature 2 from project B is more valuable than Feature 5 from Project A, then it would be better for the organization to shift and deliver Feature 2 from Project B, rather than finish all five features of Project A. And it would be better to work on one feature at a time and get it done quickly rather than run these two projects concurrently.

#3 – Establish Stable Cross-Functional Teams as the Basic Building Block

Rather than spin up new teams for every project, agile organizations build strong, high performing and long-standing teams. They avoid the cost and inefficiencies of forming, storming and norming by creating teams once and then keeping them together as they become high-performing.

Planning is much simpler with stable teams since they have a track record of delivery. These stable teams have a predictable capacity and velocity, and they have mastered tools for performing estimates that are fast and accurate enough for forecasting the future.

Stable teams also provide a foundation that we can use to develop our team members through cross-training and skill development so that we reduce key person dependencies. By spreading skill out and encouraging learning, teams can deliver all the way to done and eliminate costly handoffs.

Long-term stable teams can be co-located in one room. Co-location increases knowledge sharing, increases the effectiveness of communications, and improves productivity by as much as 100%. 

Finally, having stable teams means that organizations can do away with the resource spreadsheets and other fractional resource management tools. The organization can save the cost of tools and ongoing effort required to manage fractional resources.

Managers can focus on strategy and culture rather leveling down and carving up resources or moving people around like chess pieces on a chess board.

#4 – Work to Capacity

Rather than optimistically starting a bunch of new projects and ‘pushing’ work to the teams, Agile organizations let the teams work to capacity. When teams have the capacity, they ‘pull’ work from the prioritized list of smaller features. Context switching and multitasking is reduced, which results in more productivity and throughput.

Key Takeaways:

Thinking in terms of projects inhibits us from understanding and implementing Agile effectively and achieving the benefits of productivity and business agility. The delivery of concurrent large, monolithic projects slows the delivery of value, encourages working beyond capacity, and guarantees multi-tasking and context switching.

On the other hand, thinking with an Agile mindset can help us to organize to maximize the productivity and throughput of our teams. By creating stable teams, reducing work in process and prioritizing smaller units of work, we can deliver value faster.

If delivering value quickly isn’t a business imperative right now, you can bet that it will be soon. Organizations will need to be fast and nimble to survive in a global economy. Consider companies who are competing in some way with Amazon.

In 2011 Amazon revealed that it was releasing a new feature or change to their production systems every 11 seconds. By 2016, they were leveraging automated tools to make 50M changes a year or 1 per second. That is business agility.

---

Project Managers Don’t Get Agile
The True Cost Of Multi-Tasking, Psychology Today
Poppendieck, Mary and Tom. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, 2006.
Tuckman’s Stages of Group Development
Working Together In “War Rooms” Doubles Teams’ Productivity, University Of Michigan Researchers Find
Jon Jenkins, Velocity Culture