Tag Archives: Agile Project Management

What is an Agile PMO? Is it Possible? How Would it Work?

Background

I recently saw a question on a LinkedIn discussion group asking: What is an Agile PMO?

  • There are many people in the Agile community who might say that there is no role for a PMO in an Agile/Lean environment and
  • That the whole concept of a PMO is inconsistent with Agile.
  • That opinion is based on a stereotype that the role of the PMO is heavily associated with controlling and enforcing rigid, waterfall-style policies for selecting and managing the execution of projects and programs.

In that kind of environment, a PMO might require:

  • Very thorough and detailed upfront planning to justify the ROI on projects to support rigorous project/product portfolio management decisions
  • Rigid control of project execution to ensure that projects meet their cost and schedule goals and deliver the expected ROI

There is no doubt that some PMO’s have played that kind of role to some extent in the past; however, it is a stereotype to believe that is the only possible role for a PMO to play.

Understanding the Truth About “Agile versus Waterfall”

The key to understanding this issue is to first understand that there is not a binary and mutually-exclusive choice between “Agile” and “Waterfall”.  It is better to think of this as a range of alternatives between heavily plan-driven at one extreme and heavily adaptive at the other extreme. That looks something like this:

Range of Agility

And, the right approach is to fit the methodology to the nature of the project and business environment rather than going in the other direction and attempting to force-fit projects and business to some kind of canned approach (whatever it might be – Agile or not).

What’s the General Role of a PMO in Any Organization?

The general role of any PMO is to:

  • Align the selection and execution of projects and programs with the organization’s business goals. That includes:
    • Project/Product Portfolio Management,
    • Providing oversight of project execution and
    • The overall interface for management and reporting of projects and programs to senior management and the business
  • Coordination, guidance, and training to project teams as needed in the organization’s methodologies and standards for project management.

Those general functions probably don’t change in an Agile/Lean project environment. However, how a PMO performs those functions may change significantly depending on the organization’s overall strategy for implementing an Agile transformation.

  • Some organizations may choose to implement a relatively complete top-to-bottom Agile transformation for their business
  • Dean Leffingwell’s Scaled Agile Framework (SAFe) is an example of such a model
  • However, that can be a very ambitious and gut-wrenching change for many organizations. And, it may also may not be the best solution

It may be a mistake to believe that you have to force a company to do an extensive, top-to-bottom Agile transformation in order to adopt an Agile process at the development level.  There are many ways to adapt an agile development process to a company whose overall business may not be totally compatible with an agile approach at the enterprise level.

If you accept the notion that you need to tailor the approach to fit the nature of the business, it should be evident that:

  • The design of a PMO should be consistent with that approach and
  • There isn’t a single “canned” solution for what an “Agile PMO” is.  However, there are some general guidelines that should be useful.

What Does a Traditional PMO Look Like?

A traditional PMO organization that is oriented around a heavily plan-driven approach might look something like this:

Typical Traditional PMO Structure
Reference: Cobb, Charles, “Making Sense of Agile Project Management”, Wiley, 2011

In this kind of environment:

  • The PMO typically takes almost complete responsibility for the execution of projects on behalf of the business sponsors
  • The emphasis in this kind of organization is typically on planning and control of projects

This kind of organization would be consistent with a heavily plan-driven approach. However, how does that role change as an organization moves towards more of an adaptive approach?

What is an Agile PMO?

A more adaptive version of a PMO organization might look something like this:

What is an Agile PMO?
Potential Agile PMO Structure
Reference: Cobb, Charles, “Making Sense of Agile Project Management”, Wiley, 2011

Key Differences

Here’s what some of the key differences might be as an organization moves towards more of an adaptive (Agile) approach:

Advisory Role

The role of the PMO becomes more of an advisory role and a consultative role rather than a controlling role. The function of the PMO should be to:

  • Put in place well-trained people coupled with
  • The right process and tools
  • To make the process most effective and efficient and
  • To keep it well-aligned with the company’s business

Primary Responsibility

The primary responsibility for providing direction to projects:

  • Shifts more to the business side represented by the Product Owner in the projects and
  • There is a much more of a closer coupling with the business side, and
  • There is more emphasis on the PMO providing business value rather than simply managing project costs and schedules

Role of Functional Organizations

The role of the functional organizations (Development, QA Testing, etc.) also changes to providing more of an advisory function as the resources are more committed to project teams and the project teams become more self-organizing

Key Challenges

This model can be a very big change for many businesses because:

  • It puts a lot more responsibility on the business side of the organization to provide direction to projects. And, the business organization may not be well-prepared to take on that responsibility
  • It requires developing a close collaborative relationship between the project team and the business rather than using a PMO as a “middle-man”
  • It also relies much more heavily on self-organizing teams

For those reasons and others, a totally adaptive approach may not be the right approach for all businesses. And, even if it is, it may take time to migrate an existing organization to that kind of approach. Fortunately, there are many ways to develop a hybrid approach to blend a traditional plan-driven approach with a more adaptive approach to fit a given business and project environment.

Hybrid Environments

The role of the PMO should be aligned with supporting whatever the overall business strategy is. That might require a hybrid of an Agile and traditional plan-driven approach. For example, here are some of the ways that a hybrid approach might be implemented:

Project/Product Portfolio Management

The PMO may still be the focal point for Project/Product Portfolio Management. However, a more agile approach might be used to perform that function.

  • Instead of very rigorous upfront planning that might be required to analyze project ROI to support a more traditional, plan-driven project/product portfolio management approach,
  • A more dynamic decision-making process might be used at that level with a much more limited amount of upfront planning and less-detailed ROI analysis.

Project Execution

In the other functions related to managing the execution of projects, the PMO:

  • Probably would probably delegate more responsibility to project teams and
  • Play more of a facilitative and consultative role to support the project teams rather than playing a controlling role.

Overall Summary

In summary,

  • Agile certainly forces some rethinking of the role of a PMO. However, it doesn’t necessarily make the whole concept of a PMO obsolete and irrelevant
  • There are a wide range of strategies an organization can choose for implementing an Agile transformation at an enterprise level. It isn’t necessarily a binary choice between a pure “Waterfall approach from top-to-bottom or a totally “Agile” approach from top-to-bottom. You have to choose the right approach to fit the business rather than attempting to force-fit the business to some kind of “textbook” approach.

The important thing to recognize is that this is not a “one size fits all” decision. What is the right approach for one company may not be the best approach for another.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Fear of Failure Can Cripple a Project

What’s the Impact of Fear of Failure?

Many people have excessive fear of failure and do everything possible to avoid it. An excessive fear of failure can stifle the creativity and innovation that is often needed to maximize the business value of a solution in a project

Fear of Failure

How is the Attitude on Fear of Failure Different in Agile?

One of the key things that differentiates an Agile approach from a traditional plan-driven approach is the attitude towards failure:

Agile Environment

In an Agile environment,

  • A “failure” is seen in a positive sense as an opportunity for learning
  • There’s a very popular mantra of “fail early, fail often”

In other words, sometimes you just have to try something and see what works. Being totally risk-averse and attempting to analyze and anticipate every possible risk and contingency before you even get started may not produce the best results.

Traditional Plan-driven Environment

In a traditional, plan-driven environment,

  • The attitude towards failure is many times very different
  • Any significant unexpected event that occurs might be regarded as a failure and many times is regarded negatively
  • There is an inference that you didn’t do enough upfront planning to anticipate the problem and avoid it

Risk Management – What’s the Right Approach?

The approach for risk management is directly related to fear of failure. I don’t think either the Agile or the plan-driven approach is necessarily right or wrong. It’s a question of how much risk is appropriate to accept and what’s the best way to manage it.

  • Like many things, it depends on the situation
  • There are some situations that call for a more risk-averse approach and some that don’t

The Edge of Chaos

Some businesses have to operate on the “edge of chaos” because of a highly competitive business environment. If they were overly risk-averse and had excessive fear of failure, they would not be successful in their business. That would be a failure in itself to not do anything to “push the envelope”.

Another saying I like is “If you’ve never failed, you’re not trying hard enough”

  • Amazon.com is probably a good example of a company that has a lot of failures like the smartphone they tried to develop
  • Yet they continue to push the envelope to explore very risky new technology such as package delivery with drones
  • I’m sure that they feel that they need to continue to “push the envelope” to maintain their competitive position

Other More Conservative Environments

In other environments,

  • The consequences of problems may be much more significant and need to be more thoroughly anticipated and mitigated
  • Sending an astronaut to the moon might be an example
  • Check out the book, “Failure Is Not an Option: Mission Control From Mercury to Apollo 13 and Beyond” for more on that

The Gray Area

There’s a lot of gray area between those extremes where it may require considerable judgment to figure out what the right approach should be. Any project that involves a large amount of uncertainty might be an example. You need to determine:

  • How much uncertainty you can tolerate and let it be resolved as the project progresses, and
  • How much of it you can’t tolerate and need to resolve upfront before the project starts

It would probably be very irresponsible to take a cavalier approach and ignore the potential impact of risks. However, on the other hand, it could be equally problematic to get bogged down in “analysis paralysis” and never get started. Trying to anticipate and mitigate every possible risk that could possibly happen could easily stop progress.

What Level of Risk Is Acceptable?

The most important thing is to have a clear mutual understanding and a sense of partnership between the project team and the project sponsor about:

  • What the goals of the project are,
  • What level of risk is acceptable in the project, and
  • How those risks will be managed

Agile Projects

In an Agile project, that’s typically easier to do because the relationship with the business sponsor is based on a spirit of trust and partnership as well as openness and transparency. The Business Sponsor (represented by the Product Owner) should:

  • Have a sufficient level of judgment and maturity to make good, sound decisions on the project
  • Be intimately involved as the project progresses to provide ongoing direction

Traditional Plan-driven Projects

In many traditional, plan-driven environments, the business sponsors may not have that level of maturity and there may be less of a spirit of partnership with the project team.

  • The Business Sponsors frequently put that responsibility totally on the project team to “just get it done” and don’t necessarily want to know about any risks at all
  • That can lead to a fear of failure and a “CYA” approach by the project team:
    • It can cause the project team to over-analyze the project to avoid any possible problems and
    • It can also lead to less-than-open sharing of project information to avoid airing any “dirty laundry” with the project sponsors

Overall Summary

There is generally a direct relationship between risk and opportunity:

  • Completely avoiding risks may lead to a very mediocre solution
  • An Agile approach provides an excellent environment for taking calculated risks that may be necessary to maximize the value of the solution
  • In an Agile environment, a partnership approach where the business and the project team mutually agree on the project risks and how they will be managed is essential

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

What is an Enterprise Agile Coach?

What is an Enterprise-level Agile Coach? There are very different Agile Coach roles and when people use the term “Agile Coach” it is often not exactly clear what role that they are referring to.

Enterprise Agile Coach

Typical Team-level Agile Coach Role

Most often, what they’re talking about as an “Agile Coach” is what I would call a team-level Agile Coach. Someone in that role works at a tactical level with individual members of an Agile team to help them become more proficient in executing a Scrum process.

What Is an Enterprise Agile Coach?

The role of an Agile Coach at an enterprise-level needs to be better-defined and differentiated from a normal team-level “Agile Coach” role. Beyond the team-level Agile Coach role, an enterprise-level Agile Coach:

  • Helps companies design and implement an effective Agile transformation for their business
  • Works at a more strategic level to integrate an Agile development process with a company’s business. (See diagram above)

An enterprise-level Agile Coach should be able to see the need for an Agile transformation from a broader business perspective. Check out this article for more on that:

The Impact of the Business Environment

The problem is that there is a big difference between companies whose primary business is focused on product development and other types of businesses.

Product Development Companies

  • Agile works very well in companies that are in the primary business of developing products (particularly software products). Intuit is an example that develops TurboTax, Quicken, and QuickBooks).
  • In those companies, there is a strong and natural alignment between an Agile development process and the overall business goals of the company
  • It is very easy to apply an Agile development process in that environment.

Non-Product Development Companies

It is much more difficult to apply an Agile development process in a company that is not in the primary business of developing products. In that kind of business, the relationship of an Agile development process to the company’s overall business strategy is much more indirect.

In companies that are not in the primary business of developing products:

  • You can’t just force the company to be “Agile” in order to make the company more amenable to an Agile development process
  • The company’s overall culture and business strategy needs to be optimized around the critical success factors for that business

Fitting the Approach to the Business

An enterprise-level Agile Coach role can be very challenging. It’s important to fit the approach to the business rather than force-fitting the business to some arbitrary approach, Here’s an example:

  • If a company is in a business that requires operational excellence, it needs to focus its overall culture and business strategy primarily on efficiency of operations and reducing costs and
  • That doesn’t necessarily align completely with just becoming more “Agile”.
  • In that kind of environment, you have to develop a strategy that considers both the company’s business strategy and the requirements of an Agile development process to develop a well-integrated approach
  • The implementation of that strategy often requires fitting the approach to the company’s business environment rather than simply trying to force-fit the company to some kind of overall Agile approach

Blending Agile and Plan-Driven Project Management

The solution in that kind of environment could be a blend of Agile and traditional plan-driven management principles and practices. That is a lot more difficult thing to do and requires a lot more skill than a typical team-level Agile coach would normally have. It requires an understanding of:

  • Agile principles and practices; as well as
  • Traditional project management principles and practices
  • And a deeper understanding of the principles behind both of them to know how to blend them together as necessary to fit a given situation

Business Perspective

An enterprise Agile Coach should have the ability to look at a very complex, broad-based, enterprise-level business from both:

  • A more strategic high-level business management perspective as well as
  • A more tactical product development process perspective to develop a strategy for integrating the two.

Overall Summary

An Enterprise Agile Coach is a different kind of Agile Coach role:

  • Instead of working at a team-level on improving team performance,
  • He/she needs to work at a much higher strategic level to help a company fit an Agile approach to their business

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Managing Conflict in Agile Teams – Is Conflict Normal?

I recently saw a LinkedIn post from someone who was requesting advice on managing conflict in Agile teams. One response was to remove the people who are causing the conflict from the team.

  • That may not be an appropriate solution – some level of conflict is necessary and healthy in a high performance team
  • A team where everyone always agrees with everyone else would probably not be a very high performance team
  • In this particular situation, the conflict was occurring over estimation. In that area, you certainly want to bring out opposing views and attempt to resolve them. You don’t want to suppress conflicting opinions
Managing Conflict in Agile Teams

How Do You Manage Conflict in Agile Teams?

The right way to manage conflict on an Agile team is not to try to stifle conflict. An important value is to listen to the views of others and treat them with respect and consideration even if you disagree with them.

  • Each person on the team also needs to put their own ego and emotions aside. Instead of focusing on who’s right and wrong; focus on working collaboratively with others towards what is in the best interest of the team and the business
  • Some times people become argumentative and pursue an argument just to have the last word. They may also try to prove that they’re right and others are wrong. That behavior can be very counter-productive
  • A good way to minimize that kind of behavior is to have a clearly-defined set of values that everyone on the team agrees to

Tuckman’s Stages of Group Development

“Tuckman’s Stages of Group Development” is an excellent model for understanding team performance. The model consists of four stages that teams go through in the journey to becoming a high performance team. Here’s a brief summary.

1. Forming

The first stage is called “Forming”. In this stage, “Individual behavior is driven by a desire to be accepted by the others and avoid controversy or conflict:

  • Serious issues and feelings are avoided and people focus on being busy with routines such as team organization, who does what, when to meet, etc.
  • However, individuals are also gathering information and impressions about each other an
  • d about the scope of the task and how to approach it
  • This is a comfortable stage to be in, but the avoidance of conflict and threat means that not much actually gets done.”

2. Storming

The next stage is called “Storming”. During this stage, “Individuals in the group can only remain nice to each other for so long, as important issues start to be addressed.

  • “Some people’s patience will break early, and minor confrontations will arise that are quickly dealt with or glossed over
  • These may relate to tIndent1he work of the group itself, or to roles and responsibilities within the group
  • Some will observe that it’s good to be getting into the real issues, while others will wish to remain in the comfort and security of stage 1
  • Depending on the culture of the organization and individuals, the conflict will be more or less suppressed, but it’ll be there, under the surface
  • To deal with the conflict, individuals may feel they are winning or losing battles, and will look for structural clarity and rules to prevent the conflict persisting.”

3. Norming

As Stage 2 evolves, the “rules of engagement” for the group become established, and the scope of the group’s tasks or responsibilities are clear and agreed.

  • “Having had their arguments, they now understand each other better, and can appreciate each other’s skills and experience. Individuals listen to each other, appreciate and support each other, and are prepared to change pre-conceived views: they feel they’re part of a cohesive, effective group.
  • However, individuals have had to work hard to attain this stage, and may resist any pressure to change – especially from the outside – for fear that the group will break up, or revert to a storm.”

4. Performing

The final stage is called “Performing”. “Not all groups reach this stage, characterized by a state of interdependence and flexibility.

  • “Everyone knows each other well enough to be able to work together, and trusts each other enough to allow independent activity. Roles and responsibilities change according to need in an almost seamless way.
  • Group identity, loyalty and morale are all high, and everyone is equally task-orientated and people-orientated. This high degree of comfort means that all the energy of the group can be directed towards the task(s) in hand.”

Important Points to Recognize

There are several important things to recognize about this model:

Jumping Past Stages

You can’t just jump past the “Storming” stage and go right to the “Performing” stage

  • The only way that might happen is the people on the team have a lot of maturity on working in other teams
  • You have to progress through these stages to some extent to make progress
  • For that reason, conflict should be viewed as a sign of progress that you’ve moved past the “forming” stage

Sequential Progression

You don’t necessarily always proceed through these stages in a strict sequential order.

  • Sometimes a team will regress and fall back to an earlier stage and start over from that point and
  • You might go back-and-forth like that over a period of time.

Moving to the Norming Stage

The natural progression for a team that is in conflict is to move to the “norming” stage:

  • You do that by adopting rules and values of how the team interacts with each other.
  • Those rules and values are like “training wheels on a bike”.
  • After teams have reached a point of maturity, those rules become just a natural part of people’s behavior and the team reaches the “performing” stage which is similar to riding a bike without the “training wheels”.

Source: “Stages of Group Development”

Overall Summary

One of the key points in this model is that conflict is a normal and necessary stage of progression on the journey to becoming a high-performance team. For that reason, you shouldn’t try to stifle conflict – the best approach is to manage it by setting values so that it doesn’t become destructive.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

What’s the Difference Between a Project and a Process?

What’s the difference between a project and a process? I have a very broad view of “project management” but there is a danger of broadening the definition too far. If the definition is broadened too far, almost anything could be “project management” and that would make it meaningless. 

Difference between a project and a process

For example: Is an effort to provide ongoing maintenance and enhancements for a product a “process” or a “project”?   To eliminate potential confusion, we need clearly-defined and objective criteria for drawing a line between the two. What is a “process”, and what is a “project”.

Difference Between a Project and a Process

I’ve summarized some distinctions between a “process” and a “project” below:

ProcessProject
ObjectiveA “process” has an objective that is typically defined around the ongoing operation of the process. For example, “provide ongoing maintenance for GM vehicles”A “project” has an objective or outcome to be accomplished and the project ends when that objective is accomplished. That objective might be broadly-defined and might change or be further elaborated as the project is in progress. For example, “find a replacement ignition switch that will solve the problem with GM vehicles”.
Time DurationA “process” is generally ongoing and doesn’t normally have an end.A “project” has a beginning and an end (although the beginning and end may not be well-defined when the project starts and the end might be a long time in the future).
Process OrientationA “process” is a repetitive sequence of tasks and the tasks are known at the outset since it is repetitive.The sequence of tasks in a “project” is not normally repetitive and may not be known at the outset of the project.

Project Management Versus Process Management

Here’s a similar distinction between “process management” and “project management”:

Process ManagementProject Management
FocusThe focus of Process management is on managing a process such as a product manufacturing process. Such a process might be used across a variety of projects. Process management might involve some project management to define and improve the process.The focus of Project management is on managing a project typically using some process in achieving some kind of desired end result. Every project follows some kind of process even though it may not be formally defined.
EmphasisThe emphasis of Process management is on increasing “repeatability” of the tasks, improving efficiency (decreasing time needed, reducing cost), and improving quality of the work product produced by the process (including consistency in quality).The emphasis of Project management is on achieving the end result that the project is intended to accomplish. Higher efficiency is harder to achieve since it might require custom tools and methods that can only be developed if the project was turned into a repetitive process.

Overall Summary

In simple, terms:

  • The goal of “Process Management” is to manage existing business processes as efficiently and effectively as possible. An example would be managing a process associated with the current way the business operates.
  • The goal of “Project management” is on managing some kind of change in the way a business operates to make the overall business operate more effectively. An example would be introducing a new product, implementing new processes, etc.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

What is a Project?

What is a Project?

What is a project? I recently wrote a blog post on “What is Project Management?” that has generated some good comments on LinkedIn.  One of the comments was that “the change is not merely to redefine ‘project management’ but to redefine ‘project'”. That is absolutely correct.

What Is a Project?

PMBOK defines a project as follows:

“A project is a temporary endeavor undertaken to create a unique product, service, or result”. The temporary nature of projects indicates that a project has a beginning and an end.”

How Does This Apply to Agile?

There are potentially several problems with applying this definition to an agile project:

Beginning and End

An agile project may not have a well-defined beginning and end:

  • An Agile project will have an end at some point in time, but
  • The end may be indeterminate when the project starts

Temporary Nature

An Agile project may be:

  • More of an ongoing development effort with an end that is not well-defined and
  • The end, when it happens, may be a long time in the future. That kind of effort might not be considered to be “temporary”

Results

An agile project generally creates “a unique product, service, or result”; however,

  • The “unique product, service, or result” might not be well-defined at the beginning of the project and
  • The goal of the project may be more broadly-defined at the beginning of the project.

The Value of a Project Manager

The traditional definition of a “project” is probably based on how people have seen the value provided by a project manager.

  • The value provided by a project manager has traditionally been in planning and managing the activities of a project to meet well-defined requirements within expected costs and schedules
  • Obviously, a project manager can’t do that unless
    • The project has a beginning and an end
    • The product, service, or result the project is intended to create also needs to be relatively well-defined at the beginning of the project

What is a Project? A More Broadly-Defined Definition

An Agile project may be a more broadly-defined initiative to meet a business goal or objective.

  • It may not have specific, well-defined requirements at the beginning of the project and
  • May not have a well-defined end-date at the beginning of the project probably wouldn’t fit this definition of a “project”

In that situation, the value provided by a project manager is likely to be very different. It may put more emphasis on guiding the people, process, and tools, to maximize the business value that the effort produces.

If we broaden the vision of what “project management” is, we also need to broaden the definition of what a “project” is. There are probably two key things that are needed to develop a more general definition:

  1. A project does not necessarily have a well-defined beginning and an end
  2. The goal of the project may be to satisfy a more broad-based business objective

The new definition of a project would come out something like this:

“A project is a endeavor undertaken to satisfy a broad-based business objective/outcome or to create a unique product, service, or result”.

Overall Summary

If we broaden the definition of “project Management” to embrace Agile as well as traditional plan-driven projects, we must also broaden the definition of what a “project” is as well.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

What is Agile Project Management? How Is It Different?

There’s a lot of confusion on the subject of “What is Agile Project Management?” and how is it different? Let’s start with the standard PMI definition of “Project Management” from PMBOK that exists today:

“The application of knowledge, skills, tools and techniques to the project activities to meet project requirements”

What’s Wrong With That Definition?

It seems to me that this classic definition that so many people seem to take for granted is way out-of-date. It:

  • Seems to be based on the narrow, traditional notion that a project manager is someone who manages the costs and schedule of a project to meet defined requirements
  • Implies that there is only one way to do project management and that is based on a traditional plan-driven approach to project management.

And the definition assumes that “Project Management” is only performed by someone called a “Project Manager”.

What Is Agile Project Management

We need to significantly expand that thinking to embrace the idea that a project manager may play a role in a much more uncertain environment where:

  • The requirements may not be not well-defined and
  • The project requires a more adaptive (Agile) approach

In that environment, the goal is typically focused more on:

  • Maximizing the value the project produces rather than
  • Managing costs and schedules to deliver well-defined requirements.

The person performing that function may not even have the formal title of “Project Manager”.

Many people may claim that is not “project management” because there have been so many well-established stereotypes that have developed over the years about what “project management” is. So the first challenge is to get past many of the stereotypes that exist about what “project management” is.

Project Management Stereotypes

Here are a few of the common stereotypes that exist about project management:

1. Project Managers Are Very “Command-and-Control” Oriented

One common stereotype is that Project Managers are very “command-and-control” oriented. There is some amount of truth in that. Project managers are held responsible for getting results and:

  • Sometimes that means being assertive and somewhat directive to set goals and manage the performance of project teams
  • Many times, a project manager is expected to perform that role by the businesses that they operate in
  • In many companies, the Project Manager is the one held responsible and is expected to take corrective action to get the project on track if there is the project does not meet expectations

2. Project Managers Are Rigid and Inflexible and Only Know How to Manage by the “Waterfall” Methodology

Another common stereotype is that project managers are rigid and inflexible. That also has some truth to it. For many years,

  • Project managers have been accountable for the costs and schedules of projects and
  • In order to meet cost and schedule goals, project managers have to control the scope of the project.
  • That, in turn, requires a disciplined approach to defining and documenting detailed requirements and controlling changes

The emphasis on managing costs and schedules naturally leads to extensive use of plan-driven or “Waterfall-style” methodologies. Those methodologies are based on

  • Trying to define the project requirements in-detail upfront before the project starts and
  • Controlling changes once the project is in progress

3. Project Managers Are Just Not Adaptive and Cannot Adapt to an Agile Environment

A final stereotype is that project managers cannot adapt to an Agile environment. Like the other stereotypes, there may be some amount of truth in this stereotype. However, it would be inaccurate to generalize and say that this is true of all project managers. For many project managers:

  • Agile will require some considerable rethinking of the project management approach and
  • It will also require a significant mindset change

Where Does Project Management Fit in Agile/Scrum?

If you look at how an Agile/Scrum project works, There is actually a lot of “project management” going on but:

  • Many people will not recognize it as “project management” because it doesn’t fit the traditional stereotype of what “project management” is and
  • You may not find anyone at the team level with the title of “Project Manager”

The project management functions that would normally be done by a single person called a “Project Manager” are distributed among all the members of the Agile team. For more detail on that, check out this article:

What Is an Agile Project Manager?

A logical question would then be

  • What’s left for a project manager to do in that environment and
  • What is an Agile Project Manager?
  • What role does he/she play in the real world?

Those are not easy questions to answer because:

  • The role of an Agile Project Manager is not well-defined and
  • There may not be a role at all for a Project Manager at all at the team level in an Agile project

Basically, an Agile Project Manager is someone who knows how to blend Agile and traditional plan-driven project management principles and practices in the right proportions to fit any given situation.

There are a number of different roles an Agile Project Manager might play in an Agile environment. Check out this article for more detail on that:

Overall Summary

In my opinion, we need to make some radical shifts in thinking about what “Project Management” is. The project management profession and PMI, in particular, seem to unintentionally perpetuate these stereotypes by not addressing these basic definitions that are published in PMBOK that many project managers have taken for granted for many years.

Here’s my suggestion for a broader definition of what “Project Management” is:

“Project Management is the application of knowledge, skills, tools, and techniques to maximize the value that the project produces.”

Project management is focused on maximizing business results within the context of the business environment that a project is part of in a way that is appropriate to the nature of the project.

I’m sure that definition could be fine-tuned, but the key points that I’m trying to get across are that:

  • There isn’t just one way to do project management and we need to fully embrace Agile as a legitimate form of project management
  • One of the greatest skills of anyone performing a project management function should be to select the right approach to fit the nature of the project

This definition of “Project Management” is not be limited to someone who has a title of “Project Manager”. In an Agile environment, “project management” functions are often distributed among other roles but it is still “project management”.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Levels of Mastery in Agile – How Do You Measure Maturity?

I came across the diagram shown below that I think nicely summarizes different levels of mastery in Agile:

Levels of Mastery in Agile

Many people don’t seem to realize that there are these three different levels of mastery. Just learning the basic practices is only the beginning.

Levels of Mastery in Agile

The three levels of mastery are:

1. Practices (Doing)

The initial level of Practices is associated with learning the basic practices of Agile at a mechanical level.

  • There are many people who are at this level of learning.
    • They’ve received their CSM certification (or equivalent) and
    • They may have had some practice in the real world and know how to do the basics
  • The danger is that many people think that this is all they need to know. They think that their development is complete when they have mastered this level of learning
  • People who get stuck in this level of learning can become fairly ritualistic or dogmatic. They may insist that there is only one way to do Agile and that is doing it exactly by the book as they have learned to do it

2. Principles (Understanding)

People who have gone on to the “Principles” level of learning have gained a deeper understanding of the principles behind Agile. They understand why it makes sense rather than just doing it mechanically.

  • This deeper level of understanding gives people a broader perspective. Instead of seeing Agile as a mechanical process that must always be done ritualistically “by the book”; people at this level recognize that there may be a need to customize and adapt the processes to fit a given situation
  • People at this level are also able to see Agile in a much broader context.
    • They see beyond the basic team-level Agile implementation and
    • They recognize the need to make Agile work at much higher levels of complexity for large enterprise-level projects.

3. Values (Being)

Values is the highest level of mastery.

  • People at this level of learning go beyond only understanding the principles at a deeper level. They also understand the values behind those principles and have internalized those values into the way they work
  • People at this level are becoming Masters and are at the “top of their game”. They are able to:
    • Easily go beyond applying Agile to routine Agile project implementations.
    • Apply the principles and practices to much more demanding and difficult situations. They are also able to do it with much higher levels of consistency and success

The three levels of mastery shown in this diagram correspond to the “Shu-ha-ri” levels of mastery from martial arts. I have previously discussed that in this article:

Agile and Lessons Learned From the Martial Arts

How Does This Relate to Agile Project Management?

How does this relate to the idea of “Agile Project Management”? Many people in both the Agile and traditional plan-driven project management communities are at a very basic level of mastery of those two disciplines. They see them as firmly-defined processes to be followed. I believe that people who are at a higher level of learning and understand the principles behind these two disciplines will see things in a very different perspective. They will:

  • See these two areas as much more complementary rather than competitive
  • Recognize the reasons why one set of principles and practices makes sense in one situation and not another
  • Be able to easily blend the two sets of principles and practices together as needed to fit a given situation

Overall Summary

One of my favorite analogies for this that was originally created by Bob Wysocki is the difference between a “cook” and a “chef”:

  • A good “cook” may have the ability to create some very good meals, but those dishes may be limited to a repertoire of standard dishes. His/her knowledge of how to prepare those meals may be primarily based on following some predefined recipes out of a cookbook.
  • A “chef,” on the other hand, typically has a far greater ability to prepare a much broader range of more sophisticated dishes using much more exotic ingredients in some cases.
    • His/her knowledge of how to prepare those meals is not limited to predefined recipes, and
    • In many cases, a chef will create entirely new and innovative recipes for a given situation.
    • The best chefs are not limited to a single cuisine and are capable of combining dishes from entirely different styles of cooking

This is the challenge that I believe we face in creating a more integrated approach for Agile Project Management. We need to develop more “chefs” who are capable of seeing both Agile and traditional plan-driven project management principles and practices in a very different light as complementary rather than competitive alternatives.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

The Next Generation of Project Management – What Is It?

Background

What is the next generation of project management? What is the impact of Agile on the future of project management?

  • Does it mean that project managers who are heavily trained in a traditional plan-driven project approach will become obsolete over some period of time?
  • What do project managers need to do to adjust their career direction to adapt to the future direction of project management?

I believe that the project management profession is at a major turning point that requires:

  • Broadening our view of what “project management” is and
  • Reshaping the direction of the project management profession for the future

The new direction should fully embrace and integrate both Agile and traditional plan-driven project management as complementary approaches within an overall project management portfolio.

Reinventing Project Management

What sort of image comes to your mind when you think of the words “project management”? Does it have any relationship to Agile?

  • My guess is that many people have a very well-ingrained image of what “project management” is and
  • Many people wouldn’t associate “project management” with Agile at all

In fact, some people still see those two disciplines as polar opposites. To see things differently,

  • We have to broaden our thinking about what “project management” is and
  • Get past many of the well-established stereotypes of what “project management” is.

Why Is Reinvention Important?

Long-lasting companies have learned to “reinvent” themselves from time-to-time to keep up with changes in technology and the business environment they operate in. Here’s an excerpt from Harvard Business Review on that topic:

Harvard Business Review Excerpt

Sooner or later, all businesses, even the most successful, run out of room to grow. Faced with this unpleasant reality, they are compelled to reinvent themselves periodically. The ability to pull off this difficult feat—to jump from the maturity stage of one business to the growth stage of the next—is what separates high performers from those whose time at the top is all too brief.

“The potential consequences are dire for any organization that fails to reinvent itself in time. As Matthew S. Olson and Derek van Bever demonstrate in their book Stall Points, once a company runs up against a major stall in its growth, it has less than a 10% chance of ever fully recovering. Those odds are certainly daunting, and they do much to explain why two-thirds of stalled companies are later acquired, taken private, or forced into bankruptcy.”

Source: “Reinvent Your Business Before It’s Too Late”, Harvard Business Review, January 2011,

Another Excellent Article

Here’s another excellent article on that subject:

“A successful company is like a great white shark. In its prime, it chews up the competition, but if it dares to sit still for too long, it dies. Some of the world’s most profitable and enduring companies have achieved their long track record of success by constantly reinventing themselves.”

“Cell phone maker Nokia started off selling rubber boots. The oil giant Shell used to import and sell actual shells. But these companies and the eight others on our list adapted with the times, evolving their product lines and business strategies to stay one step ahead of their customers’ needs. In business, it’s better to be a chameleon than a great white.”

Source: How Stuff Works, “10 Companies That Completely Reinvented Themselves”

Check out the link above for some great examples of companies that have done that successfully. As the article points out, the trick is recognizing that you are at a “stall point” and taking action before you have stalled for very long and that can be a difficult thing to do.

Project Management History

To understand the transformation that is going on, its useful to look at the history of project management and how we got to where we are today:

Early History

Project Management could probably be considered to be one of the world’s oldest professions. Think of the Egyptian pyramids and the Great Wall of China:

  • The level of “project management” at that time may have been very crude and they probably didn’t call it “project management” at all but large efforts like that don’t just happen without some kind of planning and organization behind them
  • In the US, the development of the Transcontinental Railway in the late 1800’s is another example of a very large effort that had to have some kind of planning and organization behind it.

Scientific Management Approach

Around the turn of the century, along came Frederick Taylor and his co-worker, Henry Gantt. Frederick Taylor started developing new theories on how to organize workers and Henry Gantt created his famous Gantt Charts to describe the order of operations in work.

World War II and the 50’s and 60’s

World War II resulted in the Manhattan project which was another huge effort and the 1950’s and 1960’s had more large scale efforts such as the Polaris missile program and the Apollo program to put a man on the moon. PERT and CPM were invented and then in 1969, PMI was founded.

The Next Generation of Project Management

The general approach for doing project management hasn’t changed significantly since that time and the big question is “What’s next?” and also “Why Now?”

  • Has the project management profession reached its peak or is there yet another major phase of growth that is just beginning to take place? I believe it is the latter.
  • Here’s why I believe it there is some level of urgency to rethink the way we think about “project management”. The diagram below shows how the adoption rate of new technologies has changed over the last century.
Consumption of New Technology Trends

“Source: Mulbrandon, Catherine, Visualizing Economics – Adoption of New Technology Since 1900, http://visualizingeconomics.com/blog/2008/02/18/adoption-of-new-technology-since-1900

This data only goes through 2005, but you can be sure this trend hasn’t slowed down since then. (Think of how quickly smartphones have evolved as an example) This rapid proliferation of new technology calls for a new approach to project management. The traditional, heavily plan-driven approaches of the past can’t keep pace with the speed that technology is changing in many areas.

This dynamic and rapidly changing environment calls for a more adaptive project management approach in many areas. However, that doesn’t necessarily mean that

  • We need to throw out everything we’ve learned about traditional, plan-driven project management and
  • Start over again

However, it does create some significant challenges for individual project managers and for the project management profession, as a whole.

What’s the Impact on Project Managers?

This “raises the bar” for project managers significantly:

  • In the past, if you had a PMP certificate, that was as far as you needed to go for many project management roles
  • PMI has now created the Agile Certified Professional (ACP) certification and that’s not an easy certification to get, but that’s only the beginning, in my opinion

I think the PMI-ACP exam is good certification but it doesn’t go far enough:

  • It is really a test of general knowledge related to Agile and Lean
  • It doesn’t really test whether you know how to integrate Agile and traditional project management principles and practices in the right proportions to fit a given situation. That’s the real challenge for project managers, in my opinion
  • It also doesn’t prepare a project manager for a specific job role. And, the role that an Agile Project Manager might play in the real-world is not well-defined

What Needs to be Done to Address These Challenges?

This is a huge challenge to transform the project management profession and broaden our thinking of what a “project manager” is and it will take some time. However, the alternative of ignoring these trends and continuing to think of a project manager in the narrow context of someone who only does traditional, plan-driven project management will seriously degrade and undermine the project management profession over time. Here’s what I think needs to be done to address this challenge:

1. Acknowledge the Need to Make a Change

The first step is to acknowledge that we have a problem. We cannot deny the impact of Agile on the project management profession and think that:

  • A traditional, plan-driven project management approach, as we know it, is the only way to do project management and
  • Agile is just a fad that will go away.

2. Get Past Sterotypes

There are many stereotypes about what traditional project management is and about what Agile is that we need to overcome. And, we need to change our thinking to see both Agile and traditional project management approaches as complementary to each other rather than competitive.

3. Redefine Project Management

We have to better define and develop the concept of what an “Agile Project Manager” is and better define the role that an “Agile Project Manager” might play. In my view,

  • An “Agile Project Manager” is not someone who only does Agile projects
  • It is someone who has a deep knowledge of both Agile and traditional plan-driven principles and practices and knows how to blend them together in the right proportions to fit a given situationIndent1

4. Develop Agile Project Management Training

We need to develop training programs and resources to help project managers reach the goal of becoming an “Agile Project Manager”.

5. Influence Enterprise-level Management Practices

Project Managers are a product of the environment that they work in. For example,

  • Many project managers take a heavily plan-driven approach to controlling costs and schedules of a project because that’s what their organizations expect of them
  • To change the behavior of project managers, we must change what companies expect of project managers and that can require some significant changes in organizational culture

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

I encourage any project manager who needs help in making this transformation to check into my online training courses and to contact me directly if I can be of help.

Was Steve Jobs an Agile Leader?

Was Steve Jobs an effective Agile leader? I watched the movie “Jobs” this weekend about the life of Steve Jobs and his career at Apple and it was very thought-provoking. 

Was Steve Jobs an Agile Leader?

Steve Jobs was absolutely brilliant, embodied a lot of Agile values, and he was enormously successful in developing some very innovative products in a relatively short amount of time that made Apple very successful;  but he was ruthless, tyrannical, and very insensitive in his relationships with people. 

I was thinking – is that style of leadership really consistent with Agile and is it an effective style of leadership for an Agile environment?

  • Much of the thinking behind Agile is based on the idea of empowered and self-organizing teams where the product definition bubbles up rather than being driven down from above,  Steve Jobs’ leadership style doesn’t seem to be very consistent with that model, but he was very successful in getting things done.
  • Another thing that seems to be not entirely consistent with Agile is that Agile is based on the idea of teams working at a “sustainable pace” and it was apparent that many of the teams that worked under Steve’s direction at Apple worked incredible hours to get things done but they were very passionate and dedicated to their work.

Here are some quotes from Steve Jobs that indicate his values that are related to Agile:

Was Steve Jobs an Agile Leader? – Higher-level Values

Area>Quote
Focus and Simplicity“People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things… “That’s been one of my mantras – focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”
Leadership Style“It’s not about charisma and personality, it’s about results and products and those very bedrock things that are why people at Apple and outside of Apple are getting more excited about the company and what Apple stands for and what its potential is to contribute to the industry…The people who are doing the work are the moving force behind the Macintosh. My job is to create a space for them, to clear out the rest of the organization and keep it at bay.”
Planning“Again, you can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something – your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.”
Seeing the “Big Picture”“A lot of people in our industry haven’t had very diverse experiences. So they don’t have enough dots to connect, and they end up with very linear solutions without a broad perspective on the problem. The broader one’s understanding of the human experience, the better design we will have…To turn really interesting ideas and fledgling technologies into a company that can continue to innovate for years, it requires a lot of disciplines.”

Was Steve Jobs an Agile Leader? Project-level Values

Area>Quote
Requirements and Customer Needs“You can’t just ask customers what they want and then try to give that to them. By the time you get it built, they’ll want something new.”
Innovation“Sometimes when you innovate, you make mistakes. It is best to admit them quickly, and get on with improving your other innovations.”
Quality“Be a yardstick of quality. Some people aren’t used to an environment where excellence is expected.”
Continuous Improvement“I have a great respect for incremental improvement, and I’ve done that sort of thing in my life, but I’ve always been attracted to the more revolutionary changes. I don’t know why. Because they’re harder. They’re much more stressful emotionally. And you usually go through a period where everybody tells you that you’ve completely failed.”
Tools“It’s not the tools that you have faith in – tools are just tools. They work, or they don’t work. It’s people you have faith in or not.”

And one of his most famous quotes that really sums up his values is “Stay hungry, stay foolish”. 

Was Steve Jobs an Agile Leader? Overall Summary

My thoughts on this are that:

  • Steve Jobs definitely had some “rough edges” in his relationships with people but he embodies many of the characteristics of an effective Agile leader
  • There probably isn’t one leadership style that is effective in all situations and some “out of the box” thinking is definitely worthwhile rather than implementing some kind of “textbook” Agile approach in all situations

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.