An Essential Paradigm Shift for Implementing Agile

By Anthony Mersino

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 six 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 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%.[i]

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.[ii]

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[iii] 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.

5. 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 nine 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 communication and improves productivity by as much as 100%.[iv]

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 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[v]. By 2016, it was leveraging automated tools to make 50 million changes a year, or 1 per second[vi]. That is business agility.

This article can be found at https://www.projectmanagement.com/articles/387464/An-Essential-Paradigm-Shift-for-Implementing-Agile.

Anthony Mersino is an enterprise agile Coach with Vitality Chicago, Inc. He has over 30 years of experience delivering large-scale business programs and IT projects. He specializes in helping organizations effectively apply Lean and agile principles and the Scrum framework to gain true business agility. He teaches a wide range of agile and Scrum training courses as well as the cultural elements that are necessary for agile to succeed. Anthony is the author of numerous blog posts and articles and two books: Agile Project Management and Emotional Intelligence for Project Managers. He has an undergraduate degree from Michigan State University and an MBA from Loyola University of Maryland.