Project Managers Still Don’t Get Agile – Part 2

Anthony Mersino
June 26, 2017

Last year I wrote “Project Managers Don’t Get Agile” for the website.  As I continue to think about it, I see that part of the 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. I've spent the last 6 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 alters how organizations 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 the 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!
Further, project managers and teams are often incented to sacrifice quality to meet budget and timeline constraints. They take short cuts, reduce testing, and introduce technical debt to meet goals. This is especially prevalent with management imposed deadlines. This push for to achieve timeline and budget goals at the expense of quality is short term thinking.
Most organizations have multiple projects running at the same time. Project managers are measured on achieving 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. This is a form of local optimization.
#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.  

Thinking of projects as unique prevents us from seeing the work of the organization as a steady stream of 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.

#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 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. 

#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.  As new projects are started, the resource manager reassigns 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.

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. 

The problem is, 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 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. 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. These teams don’t sit and work together and they are working on multiple project 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 
A final downside to project thinking is that each project must be completed in its entirety. Remember that the project manager is focused on delivering on time, 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.
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. 

The Agile Mindset Shift

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. 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 have 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 - The Stable Team is 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.
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 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 than on the tactical level of tasks to people or assigning people to projects. 

#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 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,'s_stages_of_group_development
Working Together In "War Rooms" Doubles Teams' Productivity, University Of Michigan Researchers Find,
Jon Jenkins, Velocity Culture: 

About Anthony Mersino

Anthony is passionate about helping technology teams THRIVE and organizations TRANSFORM.  He loves partnering with organizations to help teams with Agile thinking and the Scrum Framework.  He teaches Agile and Scrum as well as the cultural elements that are necessary for an organization to gain true business agility. Anthony has  authored numerous articles and two books: Agile Project Management, and Emotional Intelligence for Project Managers.


A very good read! I would like to share my experience in context switching and percentage allocation of scrum team members' capacity. In my organization we have a Dev team that follows scrum and a production support team that follows kanban model. The latter is more like a L1/L2 support team and if they are not able to resolve the issues then they would escalate it to the Dev team (L3 support). We allocate a very small fraction of time in the Dev team's capacity to work on and resolve such escalated support tickets. Another option that we have been trying out is to have one dev completely dedicated to solving such L3 support tickets. He will pull in very less work into his sprint when compared to rest of the team. And we rotate this role every month. Still the scrum team raises concerns on the challenges that they face in context switching. And often they end up rolling over their work to the future sprints. It would be great if you could share industry best practices that could be adopted to tackle this issue.

I believe that stable cross functional teams are the new way to organize workforce. Instead of functional teams stable functional teams provide better productivity and improved efficiency. Companies don't need to worry about loosing knowledge and expertise and teams are stable and do not disband.