Agile Change Management – Why Is It important?

Why is Change Management for an Agile transformation so important? Implementing an Agile transformation can require a big shift in thinking and possibly also require changing a well-established corporate culture for many companies.  That is not an easy thing to do and it requires some skill and planning to do it successfully.

The Need for Change Management in an Agile Transformation

In general many companies need to move from an excessive emphasis on planning and control to a more flexible and adaptive approach with more emphasis on creativity and innovation in a very uncertain environment.  That requires:

  • Developing a spirit of trust and partnership among all parts of the organization at every level
  • Breaking down organizational barriers that might prevent a collaborative, cross-functional approach
  • Developing a clear, unifying vision for the organization that creates a common purpose that is well-aligned with the company’s business objectives

Why Is Change Management Difficult?

Those are not easy things to accomplish and creating lasting organizational change is difficult.  People resist change and will naturally revert back to the old, comfortable way of doing things if the change management effort is not successful.

Agile Change Management

Kotter’s Change Management Principles

The best source on this is John Kotter’s book “Leading Change”. Kotter identifies eight errors that companies make in change management initiatives:

1. Allowing Too Much Complacency

This probably could be better stated…it isn’t necessarily a matter of “allowing too much complacency”. The real issue is that if there isn’t a feeling of urgency for making a significant change, it will be difficult to get support for making the change.

2. Failing to Create a Sufficiently Powerful Guiding Coalition”

Overall leadership is extremely important – all the key leaders have to be on board with making a broad-based, cross-functional change and providing the guiding leadership to make it happen.

3. Underestimating the Power of Vision

A clear vision is needed for what the organization will look like after the change is complete. If there is no vision, it will be difficult to guide the change in the right direction.

4. Under-communicating the Vision

Major change is usually impossible unless most employees are willing to help, often to the point of making short-term sacrifices. But people will not make sacrifices, even if they are unhappy with the status quo, unless they think the potential benefits of change are attractive and unless they really believe that a transformation is possible.”

5. Permitting Obstacles to Block the New Vision

The important points that Kotter brings up are:

  • Implementation of any kind of major change requires action from a large number of people
  • New initiatives fail when employees, even though they embrace a new vision, feel dis empowered by huge obstacles in their paths
  • Occasionally, roadblocks are only in peoples’ heads – In many cases, the blockers are very real

6. Failing to Create Short-Term Wins

Many times the best approach is to not take on too much at once but focus on some short-term wins that show progress.

7. Declaring Victory Too Soon

  • People can be tempted to declare victory in a major change effort with the first major performance improvement
  • While celebrating a win is fine, any suggestion that the job is mostly done is generally a terrible mistake
  • Until changes sink down into the company culture(3-10 years) new approaches are fragile and subject to regression

8. Neglecting to Anchor Changes Firmly in the Corporate Culture

Culture and values are extremely important – if people are simply mechanically implementing the change without any real change in corporate culture and values to support it, the change may be somewhat fragile and not long-lasting.

Three Most Critical Principles

All eight of the issues that Kotter has defined are important, but from my experience, there are three that are most critical that most frequently derail an Agile transformation.  These are:

1. No Burning Platform

This is based on Kotter’s first error “Not Creating a Sense of Urgency”.  There needs to be something that creates some urgency about making a change because maintaining the current situation is very painful and untenable.The phrase “burning platform” originated with a fire on an oil-drilling platform off the coast of the United Kingdom some years ago.  The phrase can have several contexts –

  • One context was that there were serious safety issues with the platform that were not addressed until the platform caught fire because there didn’t seem to be a sufficiently urgent need to address them.

  • Another context was that once the platform was on fire, there was an urgent need for the employees to do something to save their own lives – staying on the platform at that point was an untenable situation.

2. No Vision for the Future

This is based on Kotter’s third error “Underestimating the Power of Vision”.  Taking the time to define a vision for an Agile transformation is extremely important – many people make the mistake of using a one-size-fits-all approach to force-fit a company to some kind of “textbook” model.The best approach is to fit the model to the company’s business and a pure, top-to-bottom Agile approach may or may not be the best fit.  It may require more of a hybrid approach to achieve that kind of alignment, at least in the short-term.

3. Failing to Show Short-term Progress

This is based on Kotter’s sixth error “Failing to create short-term wins”.  There are always naysayers and skeptics who will remain on the sidelines waiting to see if the change is likely to be successful before they jump on the bandwagon.  That is why it is important to get started and demonstrate progress as quickly as possible.  From an Agile perspective, it is important to set clearly-defined and measurable goals that show progress and regularly communicate that progress to everyone involved.

Overall Summary

Implementing Agile successfully at an enterprise-level many times requires a significant transformation. That can be a difficult thing to do and it requires some understanding of change management to do it successfully. It is actually very similar to a business process reengineering project.

Additional Resources

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

Improving Team Performance – How Do You Improve Team Performance in a Project Environment?

A number of people have asked questions related to improving team performance. It takes some skill to do that – “How do you improve team performance in a project? 

Improve Team Performance

Improving Team Performance

How to Improve Team Performance

It is very common for project managers to over-manage teams and I think that is a mistake. A team is like a dynamic organism:

  • Rather than simply putting pressure on the team to improve performance, a better approach is to understand the dynamics of how a team performs. You can then work on the factors that impact improving performance
  • An even better approach is to help the team become self-organizing and take responsibility for improving their own performance

What is a Self-organizing Team?

Here’s a good definition of a self-organizing team from the Scrum Alliance web site:

“A group of motivated individuals, who work together toward a goal, have the ability and authority to take decisions and readily adapt to changing demands”

The diagram below shows a comparison of a traditional project team and a self-organizing team:

What is a Self-organizing Team

Does This Mean Abdicating all Responsibilities to the Team?

The principles behind empowered teams can be used in any project. It is just different levels of empowerment.  The diagram below shows a comparison of different levels of empowerment:

How Do You Improve Team Performance

Here’s a description of each of these levels:

Manager-led TeamThe lowest level of empowerment is a “manager-led team”. In that environment, the only responsibility delegated to the team is for managing the execution of tasks that they are responsible for.
Self-governing TeamAt the other extreme is a “self-governing team” where the team takes complete responsibility for their operations including setting their own direction. It would be unlikely to find that level in a project team but you might find a senior management leadership team that operated that way.
The two levels below are more typically found in an Agile environment:
Self-managing TeamA “self-managing team” takes responsibility for monitoring and managing work process and progress.
Self-organizing TeamA “self-organizing team” goes beyond that and takes responsibility for designing the team including defining roles within the team and defining the organizational context of how the team operates.

An important point is that “self-organizing” does not mean that a team does not need any direction at all. Self-organizing teams should not be used as an excuse for anarchy.

What Are the Advantages of Empowered Teams?

There are a number of advantages of empowered teams:

  • Empowered teams more fully utilize the capabilities of the people on the team
  • They reduce the need for someone to directly manage all aspects of how the team operates
  • They improve team performance because the team takes more responsibility for managing its own performance
  • Team performance is more sustainable because the performance of the team is more self-correcting
  • It encourages creativity and innovation and enables the team to quickly adapt to new problems and challenges

Comparison of Agile and Plan-driven Approaches

There can be a big difference between an Agile environment and a traditional plan-driven environment.

1. Traditional Plan-driven Projects

In a traditional plan-driven project team, a Project Manager or Team Leader typically provides direction to the team:

  • The project manager is the one who is held responsible for the performance of the team and the results that they produce, and
  • Some level of control may be needed to manage conformance to the project plan

However, even in that kind of environment, it is essential to delegate some level of responsibility to the members of the team.

2. Agile Projects

In an Agile project,

  • There is a much higher level of emphasis on creativity and innovation rather than conformance to a plan
  • In that kind of environment, it is very important to fully empower all the members of the team to actively contribute to the solution as much as possible

In an Agile environment, there may not be a project manager involved at all at the team level:

  • If a project manager is involved at that level, he/she needs to be more of a coach to help the team improve its own performance.
  • However, there is no reason why the idea of empowered teams is limited to an Agile environment
  • The same ideas can be applied in a traditional plan-driven environment; however, it may involve somewhat less empowerment

Overall Summary

Project Managers have a tendency to over-manage the performance of teams because the perception is that is what a Project Manager or Team Leader is supposed to do.

  • However, in many cases, simply putting pressure on the team to improve performance may not be effective
  • A more proactive and more sustainable approach is to better understand how the team functions as a dynamic organism. You can then work on the factors that drive performance.

Additional Resources

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

What Is Servant Leadership and How Does It Relate to Agile?

“Servant Leadership” is a commonly-used term in an Agile environment. However, if you asked people what it means, I’m sure you would get a number of different responses. For that reason, I think it is worthwhile to discuss “What Is Servant Leadership?”

What is Servant Leadership?

What Is Servant Leadership?

“Servant leadership” sounds like a manager who does nothing but get coffee, donuts, and pizza for the Agile team. Is that what it really is? (I don’t think so). The phrase “servant leadership” was coined by Robert K. Greenleaf in “The Servant as Leader”, an essay that he first published in 1970 long before Agile came into being.   Here’s a definition of “servant leadership”:

“Servant leadership is characterized by leaders who put the needs of a group over their own. These leaders foster trust among employees by holding themselves accountable, helping others develop, showing appreciation, sharing power and listening without judging. While serving and leading seem like conflicting activities, these leaders are effective initiators of action.”

A “servant leader” doesn’t necessarily completely abdicate the leadership role and do nothing but get coffee, donuts, and pizza for the team.  He/she recognizes the importance of working through others and engaging and empowering others to use as much of their own capabilities as possible.  Here’s an excellent quote on that:

“The servant-leader is servant first… It begins with the natural feeling that one wants to serve, to serve first.

The difference manifests itself in the care taken by the servant-first to make sure that other people’s highest priority needs are being served. The best test, and difficult to administer, is: Do those served grow as persons?

A servant-leader focuses primarily on the growth and well-being of people and the communities to which they belong”

Greenleaf Center for Servant Leadership

What is Servant Leadership?

What Does it Really Mean to be a Servant Leader?

A major leadership principle that is applicable to any leadership role is that there is no single leadership style that works in all situations. A good leader should be capable of taking an adaptive and situational leadership approach that is appropriate to the people and the environment he/she is trying to lead.

With regard to servant leadership, the way the servant leader role is implemented will be very dependent on the capabilities of the Agile team you are leading and the environment you are part of. The goal should be to maximize the utilization of the capabilities of the entire team. However, that doesn’t mean a servant leader completely abdicates a leadership role and turns over all responsibility to the team. Determining the most effective servant leadership role requires some judgement:

  • If the team is very strong and very capable, the role of the servant leader may be limited to a facilitation role
  • If that is not the case, a more active leadership role may be needed by the servant leader

Basically, the servant leader needs to “fill the cracks” as much as possible to help the team become fully effective on their own.

Why Is This Important in Agile?

The idea of “servant leadership” is particularly important in an Agile environment because an Agile approach is best suited for projects with a high level of uncertainty.  In that kind of environment,

  • A lot of individual creativity may be needed to find an optimum solution and
  • Maximizing the creativity of the team requires that the team be empowered as much as possible.

It is basically a softer leadership style that puts an emphasis on empowering others over a more controlled approach.  It is ideal for a highly uncertain environment that requires an adaptive Agile approach.  Naturally, it probably would not be so ideal for a more plan-driven environment where conformance to a plan is important.

Additional Resources

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

What is Emotional Intelligence and Why Is It Important?

I recently created a significant training module on Agile Leadership. One of the key topics in that module is “Emotional Intelligence”.  I’m sure some people are wondering “What is emotional intelligence and why is it important?”  I’d like to summarize some of that here.

What Is Emotional Intelligence?

First, here’s a definition of “emotional intelligence”:

“Emotional intelligence is the ability to identify and manage your own emotions and the emotions of others. It is generally said to include three skills:

  • “Emotional Awareness
  • The ability to harness emotions and apply them to tasks like thinking and problem solving; and
  • The ability to manage emotions, which includes regulating your own emotions and cheering up or calming down other people”

What Is Emotional Intelligence and Why Is It Important?

Why Is It Important?

Emotional intelligence is one of the most important skills of an effective leader. The reason that emotional intelligence is so important to leadership is that if you can’t control your own emotions; it will be difficult, if not impossible to be an effective leader.

Here’s a quote that sums up the value of emotional intelligence very well:

“We probably also know people who are masters at managing their emotions. They don’t get angry in stressful situations. Instead, they have the ability to look at a problem and calmly find a solution. They’re excellent decision makers, and they know when to trust their intuition.

“Regardless of their strengths, however, they’re usually willing to look at themselves honestly. They take criticism well, and they know when to use it to improve their performance.”

What Are the Benefits of Emotional Intelligence?

Here are some of the key benefits of developing emotional intelligence:

Increased Leadership AbilityYour leadership approach will be based on sound, rational principles rather than being dominated by emotional responses
Increased Team PerformanceTeam members will feel much more comfortable and secure in a non-threatening team environment with no hidden agendas
Improved Decision-makingDecisions are made more objectively and rationally
Decreased Occupational StressThere will be less emotional tension involved in the work environment
Reduced Staff TurnoverThere will be fewer emotional flare-ups
Increased Personal Well-beingLearning to accept yourself and gain control of your emotions can lead to a much happier life

How Do You Improve Emotional Intelligence?

The following tips have been reproduced from the Mind Tools web site:

1. Observe How You React to People

“Do you rush to judgement before you know all the facts? Do you stereotype? Look honestly at how you think and interact with other people. Try to put yourself in their place, and be more open and accepting of their perspectives and needs.”

2. Look at Your Work Environment

“Do you seek attention for your accomplishments? Humility can be a wonderful quality, and it doesn’t mean that you’re shy or lack self-confidence. When you practice humility, you say that you know what you did, and you can be quietly confident about it. Give others a chance to shine – put the focus on them, and don’t worry too much about getting praise for yourself.”

3. Do a Self-Evaluation

“What are your weaknesses? Are you willing to accept that you’re not perfect and that you could work on some areas to make yourself a better person? Have the courage to look at yourself honestly – it can change your life.”

4. Examine How You React to Stressful Situations

“Do you become upset every time there’s a delay or something doesn’t happen the way you want? Do you blame others or become angry at them, even when it’s not their fault? The ability to stay calm and in control in difficult situations is highly valued – in the business world and outside it. Keep your emotions under control when things go wrong.”

5. Take Responsibility for Your Actions

“If you hurt someone’s feelings, apologize directly – don’t ignore what you did or avoid the person. People are usually more willing to forgive and forget if you make an honest attempt to make things right.”

6. Examine How Your Actions Will Affect Others

“Before you take those actions. If your decision will impact others, put yourself in their place. How will they feel if you do this? Would you want that experience? If you must take the action, how can you help others deal with the effects?”

Why Is This Particularly Important to Agile Project Management?

Check out my previous article on Agile Leadership and I think you will understand why effective leadership is extremely difficult and so important in an Agile environment with high performance teams.  Agile is based heavily on transparency and openness and if you can’t be open and transparent about who you are as a person, you will have a difficult time being effective in an Agile environment.

Overall Summary

Self-awareness is one of the biggest components of emotional intelligence.  Many people aren’t even aware of who they are as a person and don’t reveal that to others.  They live their lives behind a facade that is based on projecting an image of who they are to others that may not be very genuine and others can employees can see through that easily.

When I was a young manager many years ago, self-awareness training was a standard part of many companies’ management training curriculum.  

  • The idea was that, to be an effective leader, its important to be genuine and open with others and you can’t do that without self-awareness
  • Unfortunately, over the years, companies have cut back on that kind of training.  It was seen as frivolous and not essential and as pressure has mounted to reduce cost of operations, a lot of that kind of training has been cut

Additional Resources

I can’t really directly help you develop emotional awareness in my online training; however, I’ve added two new sections and twelve additional lessons on Agile Leadership and Emotional Intelligence in my online training that I think will be helpful to you to better understand how to develop an effective leadership strategy.

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

What’s Really Different About Agile Leadership?

I just finished developing some online training on Agile Leadership and What’s Really Different About Agile Leadership? This article is a brief excerpt of that training.

Agile Leadership

Leadership Stereotypes

They’re are lots of stereotypes and myths in this area – here are a few of them:

  • Project Managers only know how to do a “command-and-control” style of management
  • Agile requires a “servant leadership” approach which means that you completely abdicate the leadership role

Those stereotypes generally follow many of the stereotypes that people have about “Agile” and “Waterfall”. They see them as binary and mutually-exclusive choices with nothing in the middle of those extremes.  Instead of force-fitting a project to one of those extremes, the right approach is to go in the other direction and fit the methodology to the nature of the problem. Sometimes that requires a blend of the two approaches.

Instead of force-fitting a project to one of those extremes, the right approach is to go in the other direction and fit the methodology to the nature of the problem and sometimes that requires a blend of the two approaches.

Agile Leadership – Fitting the Leadership Style to the Nature of the Problem

You can make some similar observations about leadership style:

  • A good leader doesn’t have one well-defined style of leadership that he/she force-fits all situations to.
  • A good leader recognizes that different styles of leadership are needed in different situations. That’s what “situational leadership” is all about

Another important observation is that the leadership style that is most appropriate in a given situation is directly related to the nature of the project and the problem solving approach.  Here’s how I see the relationship:

What's Really Different About Agile Leadership?

The nature of the problem shapes the management objective and

  • The management objective shapes the problem solving approach
  • The problem-solving approach  determines the leadership style that may be most appropriate

Comparison of Different Environments

The table below shows some important differences between a traditional plan-driven environment and an Agile environment. The table shows the characteristics in each environment that might have some impact on the overall leadership approach.

General Characteristics and Problem-Solving Approach

AreaPlan-driven EnvironmentAgile Environment
General Characteristics Projects that have a relatively low level of uncertainty and require some level of predictability might lend themselves to more of a plan-driven approach to project management.

An important characteristic that differentiates this kind of project is that it is assumed to be possible to define the general solution to the problem with some level of certainty prior to the start of the project.

Projects that have a higher level of uncertainty typically require a more flexible and adaptive approach to arrive at the solution as the project is in progress.>

In an Agile project, both the solution and the process for finding the solution might evolve as the project is in progress.

Problem-Solving Approach A defined problem-solving approach is what is typically used. The solution to the problem is generally well-defined in advance and the general approach for implementing the solution is also fairly well-defined. An Agile project uses a empirical process control approach. The word “empirical” means “based on observation” which means that both the definition of the solution as well as the process to discover the solution will evolve based on observation throughout the project.

Management Objective and Leadership Approach

AreaPlan-driven EnvironmentAgile Environment
Management Objective Predictability is normally important. Achieving predictability requires a well-defined plan and conformance to the plan and some level of emphasis on control are also important. Arriving at an effective solution is far more important in this kind of project than predictability. Therefore, innovation and creativity would generally be emphasized more than control.
Leadership Approach The style of leadership naturally might be a bit more directive in order to remain on track with the project plan. You certainly don’t want members of the project team running loose in all different directions without some kind of plan that integrates all of their efforts together that is consistent with the overall plan. A different leadership style is typically called for. If you want to encourage creativity and innovation, you don’t want to emphasize control, you want to empower people and give them some flexibility to use their own intelligence and judgement to explore alternatives as necessary to find the best solution.

Polarized Viewpoints

There are a lot of very polarized viewpoints in this area that go something like this:

  • Agile is good and
  • Waterfall is bad

Or alternatively:

  • Command-and-control management is bad and
  • Agile Servant Leadership is good

Those polarized points of view tend to over-simplify what is not quite so simple. It not as simple as drawing a black-and-white comparison between two extremes. 

  • There are lots of “shades of gray” in both the problem-solving approach and the leadership style that is most appropriate for a particular situation. 
  • An effective leader should be able to adjust his/her leadership style and problem-solving approach as necessary to fit any given situation.

Overall Summary

Here’s a summary of some key points:

  • There is not just one leadership style that fits all situations
  • Leadership styles are not necessarily good or bad. Saying a particular leadership style is good or bad is like saying “a car is better than a boat”.  Each has advantages and disadvantages depending on the environment you’re in.
  • Agile leadership is not really a radically different style of leadership. It is not totally separate and mutually-exclusive with other leadership styles. However, it significantly expands our definition of what “leadership” is.

Additional Resources

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

Scaling Agile and Scrum for Large, Complex Projects

There is a lot of confusion and some fairly polarized opinions about scaling Agile and Scrum for large, complex projects involving multiple teams. There are a number of different competing approaches for doing this.

Scaling Agile and Scrum

Scrum-of-Scrums and LeSS

  • Some people think that it can be done simply by adding a Scrum-of-Scrums approach to provide a mechanism to coordinate the efforts of multiple teams.
  • A more comprehensive approach for integrating the efforts of multiple development teams is Large-Scale Scrum (LeSS).
  • A Scrum-of-Scrums approach is a loosely-coupled approach that only provides for basic coordination of the work between teams – each team still operates fairly independently.
  • LeSS is a much more tightly-coupled approach that goes beyond the very basic level of coordination of work that the Scrum-of-Scrums approach provides.

The table below shows a comparison of the two approaches:

Coordination of WorkFormal Scrum-of Scrum’s MeetingInformal, “Just Talk”
Product Backlog Management
(Single or Multiple Backlogs)
Not SpecifiedSingle Product Backlog
Sprint Planning
(Separate or Joint)
Not SpecifiedJoint
Sprint Review
(Separate or Joint)
Not SpecifiedJoint
Allocation of Work
(Component or Feature)
Not SpecifiedFeature

Selecting the Right Approach

The right approach will depend on the project and the need for a more loosely-coupled or tightly-coupled approach for integrating the development efforts. However,

  • Both of these approaches only address integration of the teams from a technical, development perspective and do not explicitly provide any mechanism for integration of the efforts from a business perspective.
  • It is assumed that the normal Product Owner role provides that level of integration but that may not be very realistic for very large, complex projects. This is really a multi-dimensional problem as shown in the diagram below:
Agile Scaling Dimensions

Scaled Agile Framework (SAFe)

The Scaled Agile Framework (SAFe) and other enterprise-level Agile frameworks recognize the need to provide this level of business integration with an appropriate level of program management and/or product/project portfolio management to ensure that the development efforts are well-integrated and well-aligned with the company’s business strategy.

Enterprise Agile Scaling Frameworks

Overall Summary

The ability to scale Agile to handle large, complex enterprise-level projects is a relatively new area that has a lot of confusion and conflict associated with it. It also poses some very significant challenges.

Confusion and Conflict

There is a lot of confusion and conflict in this area:

  • A number of people who see this from a development perspective tend to think that SAFe and other enterprise-level frameworks that address the problem of business integration are just unnecessary overhead and bureaucracy
  • Many people who see this from a business strategy perspective don’t understand the need for integrating development efforts from a technology perspective


There are three major challenges that need to be considered:

  1. Integrating the efforts of multiple teams from a development perspective
  2. Aligning the efforts of all teams with the organization’s business objectives
  3. Coordination with other related efforts outside of the project team and providing tracking and progress reporting to management

Both the development integration perspective and the business integration perspective have merit and need to be considered when scaling Agile/Scrum to large, complex projects and all of the above challenges may need to be addressed to make a large, complex, multi-team Agile project successful.

Additional Resources

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

How Do You Go About Selling Agile?

A student in one of my courses asked if I could help him develop a short and succinct way of “How Do You Go About Selling Agile? I think it’s an excellent topic and I told him I would write up something on that. Here it is…

Selling Agile
Mature businessman in his office with offce building on the background

How Do You Go About Selling Agile?

First, I don’t think that anyone should start with an objective of “selling Agile” to anyone. There are a lot of people out there who try to do that.

  • I think it is fundamentally the wrong approach to try to convince someone to become more Agile.
  • A better approach is to focus on what problem it will solve.

Selling Agile – Fitting the Approach to the Business

I also very strongly believe that there is not a binary and mutually-exclusive choice between “Agile” and “Waterfall”. Rather than attempting to force-fit a business or project to one of those extremes, you have to go in the other direction and fit the methodology to the problem. It takes a lot more skill to do that but it definitely can be done. It requires:

1. A Broader Knowledge of Different Methodologies

You need a broader knowledge of different methodologies (both Agile or adaptive and plan-driven) including an ability to:

  • See past many of the stereotypes, myths, and misconceptions that exist about what’s commonly referred to as “Agile” and “Waterfall”
  • See those two approaches in a fresh, new perspective as being complementary to each other rather than competitive and
  • Objectively understand the strengths and weaknesses of both approaches

2. Systems Thinking Approach

It also requires the ability to take a “systems thinking” approach to see those methodologies in a broader context beyond just a development process perspective of how they relate to an overall business and what problems they might solve

3. Understand the Principles Behind the Methodologies

In addition to all of that, you also need to understand the principles behind the methodologies at a deeper level. (Rather than just the mechanics of how to perform the methodology) That is essential to understand how to blend different, seemingly disparate methodologies together as needed to fit a given situation

Selling Agile – Taking a Business Perspective

If you’re trying to “sell” a manager on becoming more agile,

  • He/she probably doesn’t have all of those skills and
  • Is probably not willing to sit through a series of training courses to develop those skills either

So, how do you develop a relatively simple “elevator speech” to help someone understand why they should even consider becoming more Agile?  Here are some thoughts on that:

Look at It From an Overall Business Perspective

First, you have to look at it from an overall business perspective , not from a more limited development process perspective. It’s very easy to get “tunnel vision” with Agile:

  • We get so enthusiastic about the benefits of Agile from a development process perspective
  • We assume that what’s good for the development process must be good for the company as a whole and that’s not necessarily the case

Rather than attempting to force-fit a company to an Agile approach:

  • You may have to craft an approach that is more well-aligned with the primary success factors that drive the company’s business and
  • Becoming more Agile may or may not be the most important factor in the company’s overall business success.

Fear of Agile

Second, you have to recognize that some companies are scared to death of Agile. They’re afraid of losing control and that fear is not totally unfounded if the Agile approach is not well-designed and managed.

  • So, you may need to start off with more of a hybrid approach as an initial first step to demonstrate success rather than going full-bore into a complete corporate Agile transformation
  • You also need to recognize that an Agile transformation can take a long time and demands a lot of patience and perseverance

Focus on Results

Finally, nothing sells better than results. Work on developing good results and that will sell itself.

Benefits of a More Agile Approach

It’s important to focus on the benefits. How will it help the business?

  • Don’t just try to become Agile for the sake of becoming Agile
  • Although the benefits of adopting a more agile approach will vary from one company to another, there are some general benefits that apply, to some extent, to any company

Here are the key general benefits I would focus on in my “elevator speech”…


The biggest and most general benefit is adaptability. Regardless of whatever other benefits an agile approach might provide,

  • No one is likely to argue that there’s a big advantage in being able to tailor an approach to fit a project and a business rather than
  • Force-fitting all projects to a traditional, plan-driven project management approach


Probably the next most important general benefit is time-to-market. An Agile approach is not necessarily the fastest but it has some significant advantages:

  • Prioritizing requirements and delivering functionality incrementally can significantly accelerate progress
  • A more streamlined planning process can also accelerate the startup of a project
  • Reduction of unnecessary overhead will improve efficiency and throughput

Reduced Costs

Another big factor is reduced costs associated with reducing unnecessary overhead in projects. This is another one that doesn’t require adopting a full Agile development approach to achieve. All it requires is:

  • Taking a hard look at some of the documentation and other artifacts and controls used in a project and
  • Deciding whether they really produce value or not and who they produce value for.

Customer Satisfaction

A big selling point of Agile is the improved customer satisfaction from having a customer directly engaged in the project to ensure that the project really solves their business problem and provides an appropriate level of value to them

Employee Productivity and Morale

Improved employee productivity and morale is a result of more empowered teams

Organizational Synergy

Finally, a major benefit of an Agile approach is the organizational synergy that results from the cross-functional collaboration of an Agile approach. Having everyone in the organization work together in a spirit of trust and partnership towards some overall goals can have a very powerful impact.

Overall Summary

The key point to emphasize is that all of these are relatively tangible benefits that can be realized, to some extent, on any project simply by using more of an “Agile Mindset”. It doesn’t necessarily require adopting a full-blown Agile approach like Scrum and/or risk losing control of your business to get some of these benefits.

Years ago when I was a Program Manager in a large computer company, part of the training to become a Program Manager was a course called “Solution Selling” which was basically a consultative approach to “selling”. It created a different approach to “selling”

  • Instead of going in to a client to sell them something like “Agile”, the “solution selling” approach is to go in to the customer and to do a lot active listening to understand their problem before attempting to sell any solution
  • I think that’s a good approach with Agile also. There are people out there who get overly-zealous about “selling” Agile to the extent that “Agile” becomes a solution to any problem you might have. That’s the wrong approach, in my opinion.

Additional Resources

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

Is the Idea of a PMO Obsolete? What Does a Future PMO Look LIke?

Is the idea of a PMO Obsolete? What does a future PMO look like? I think the traditional notion of a PMO is becoming obsolete rapidly in many industries; however, that doesn’t mean that the idea of a PMO is no longer needed at all:

  • A PMO can play a value-added role but it is a somewhat different role than what a PMO may have played in the past.
  • It’s a difference in emphasis between providing control versus producing value

The traditional emphasis of a PMO has been primarily on:

  • Providing control of spending to ensure that individual projects were well-managed from a fiscal responsibility perspective and
  • That the overall portfolio of projects produced an acceptable return
What Does the Future PMO Look LIke?

What’s Wrong With the Traditional PMO Role?

What’s wrong with that picture? We’ve learned that many projects may seem to be successful from a financial perspective yet fail to deliver business value. Business value is a much more elusive target that is much more difficult to measure. So what is the answer?

  • It’s a significant shift in emphasis for a PMO to put more focus on producing value versus providing control; however, that’s not an all-or-nothing proposition.
  • Many people tend to see things in black-and-white, binary terms. Either you’re focused on value or you’re focused on control and there’s no middle ground. I don’t believe that to be the case.

How Do You Find the “Middle Ground” to Get to a Future PMO?

It takes a lot more skill to find that middle ground” but it definitely can be done. It requires seeing “control” in a different perspective – it’s a more dynamic kind of control. There’s a lot of similarities to the difference between traditional plan-driven project management and a more dynamic form of Agile Project Management at the project level:

  • Instead of having very well-defined plans at the project portfolio level that aren’t expected to change at all, plans are much more broadly defined and are expected to change and become further defined over time
  • It also requires a partnership with the business and much more active participation in the development and implementation of the project portfolio strategy by the business

What needs to happen at the project portfolio level is very similar to what needs to happen at the project level; it’s just at a higher level. There is a direct parallel between the role of a modern, PMO and the role of an Agile Project Manager.

  • Both need to play much more of a facilitation role and add value based on a much more dynamic style of management rather than a controlling role
  • They both need to put in place the right people, process, and tools to execute the strategy and intervene only as needed

What Does the Future PMO Look Like? Overall Summary

The idea of a PMO is not necessarily obsolete but the role of a PMO in an Agile environment is very different and requires some considerable re-thinking about how to implement a PMO.

Additional Resources

For more on this, check out my article:

What is an Agile PMO?”

Also check out this online training course:

“Agile Project Management for Executives”

Business Process Reengineering and Agile Transformation

I recently wrote an article on a “Business-centric Approach to Agile“. Have you ever thought about how similar Business Process Reengineering and Agile Transformation are? The similarities are amazing but I suspect that many people don’t think of any relationship between BPR and Agile.

What Is Business Process Reengineering?

Business Process Reengineering (BPR) was very hot in the 1990’s. One of the catalysts that precipitated the need for BPR was the advent of new Enterprise Resource Planning (ERP) systems.

  • ERP systems enabled many companies to much more completely automate their business processes. However, it was a gut-wrenching change for many companies because, in many cases, implementing an ERP system required rethinking their business processes and take a much more cross-functional approach to their business.
  • Another important catalyst was “lean manufacturing” which seeks to eliminate the use of any resource that does not create value for the end consumer.

Does that sound like an Agile enterprise-level transformation? Here’s how Bain and Company defines “Business Process Reengineering”:

“Business Process Reengineering involves the radical redesign of core business processes to achieve dramatic improvements in productivity, cycle times and quality. In Business Process Reengineering, companies start with a blank sheet of paper and rethink existing processes to deliver more value to the customer. They typically adopt a new value system that places increased emphasis on customer needs. Companies reduce organizational layers and eliminate unproductive activities in two key areas. First, they redesign functional organizations into cross-functional teams. Second, they use technology to improve data dissemination and decision making”

Source: Bain & Company: Insights – Management Tools, Business Process Reengineering

Understanding Business Process Reengineering

Let’s take this definition one step at a time:

Radical Redesign of Core Business Processes

The first statement is

“Business Process Reengineering involves the radical redesign of core business processes to achieve dramatic improvements in productivity, cycle times and quality”.

There is no question in my mind that that statement could apply to an Agile transformation, but do companies really realize that and do it that way?

Start With a Blank Sheet of Paper and Rethink Everything

The next statement is

“In Business Process Reengineering, companies start with a blank sheet of paper a2nd rethink existing processes to deliver more value to the customer.”

There’s also a good fit with that statement. You may not start with a “blank sheet of paper” and throw out all your existing management processes, but it is definitely important to rethink many existing stereotypes and misconceptions that exist about both Agile and traditional management approaches before you launch into an Agile transformation.

Adopt a New Value System

The statement that

“They typically adopt a new value system that places increased emphasis on customer needs”

is very relevant to an Agile transformation but is probably not given the attention that it deserves. When a company implements an Agile transformation, it is often done from a limited development perspective focused on how it improves the development process. However, that needs to be done in a larger context of how it improves the customer value that the company delivers to its customers.

Reduce Organizational Layers and Eliminate Unproductive Activities

The last statement is absolutely very relevant to an Agile transformation:

“Companies reduce organizational layers and eliminate unproductive activities in two key areas. First, they redesign functional organizations into cross-functional teams. Second, they use technology to improve data dissemination and decision making”

Additional Resources

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

Making Agile Work for Your Business

How do you go about making Agile work for your business? Many Agile coaching and consulting companies take what I would call a “developer-centric” approach to Agile:

  • The effort is heavily focused on team-level capabilities and is primarily oriented around improving the development process
  • There’s nothing wrong with that, in itself. However,
    • People often make the mistake of assuming that whatever is good for the development process must be good for the business as a whole, and
    • That is not necessarily the case
Make Agile Work for Your Business

When you apply Agile to a business at an enterprise level, a balance between two approaches is needed:

  • A bottom-up “developer-centric” approach and
  • A top-down “business-centric” approach to Agile


Making Agile work for your business is a real challenge:

  • There is widespread knowledge that exists about almost every possible aspect of how to optimize an Agile development process at a team level; however,
  • The knowledge about how to make Agile work at an enterprise level is much more limited.
  • There have been numerous failures in trying to make Agile work at an enterprise level and there are some significant misconceptions behind these failures

Another big challenge is aligning the overall business strategy and the development strategy:

  • At the business level, the approach should be designed around what makes the most sense for the company’s business
  • That may or may not be exactly the same as the approach used to manage projects at the development level
  • The people designing the enterprise-level strategy need to be able to understand the business strategy as well as the development strategy and fit the two together
  • It isn’t necessarily just a matter of forcing the entire company to become more agile

Frequent Mistakes

Many people have the belief that:

  • Any kind of traditional management approach is bad,
  • Agile is good, and
  • There is a binary and mutually-exclusive choice between the two approaches

That over-simplifies what I believe is a much more complicated decision. The result of that is that people often try to force-fit a company’s business to an Agile approach

  • The right solution is to go in the other direction and fit the approach to the company’s business
  • Sometimes that may require blending an Agile approach with a more traditional management approach

How Do You Determine the Right Approach?

Becoming agile for the sake of becoming agile may not be an appropriate goal for all companies. You have to ask:

  • “What problem will it solve?” and
  • “How will it really benefit the company?”

The answer to those questions may be very different depending on the nature of the company’s business.

Product-oriented Companies

A pure Agile approach is best suited for:

  • A company that is in the business of producing some kind of software product. An example would be Intuit and TurboTax or Quicken or
  • Where the software plays a very direct role in leveraging the company’s primary business (an example would be

Project-oriented Companies

Where that is not the case and the company’s business is only indirectly leveraged by the Agile development process,

  • It can be a lot more difficult to implement an Agile development process and
  • More adaptation may be required to fit the Agile development process to the company’s business environment

An example would be an internal IT application development project)

How the company handles financials and business decisions is a key difference. An Agile development approach is very well-aligned with a product development approach. Here’s an article with more detail on that difference:

Product Development versus Project Development

How Do You Develop a “Business-centric” Approach?

The key to developing a more business-centric approach is to recognize that the overall approach must be designed to satisfy the critical success factors of the company’s business.

  • A good model to look at to understand this better is the idea of “value disciplines”. Check out my article on “Agile and Corporate Culture” for more on that.
  • For example, a company like McDonalds is in a business that demands “operational excellence” as the primary value discipline
  • In that environment, one of the most important critical success factors is going to be reducing costs
  • How does an Agile development approach contribute to achieving that objective? The answer isn’t necessarily obvious.

What Is Needed?

What’s needed in this situation in many cases is:

  • More of a “top-down” business analysis to identify potential areas for process improvement
  • Aligning those initiatives with the critical success factors that are most important to the company’s business

That should be one of the first steps in an Agile transformation for this kind of company:

  • Before you jump to the conclusion that Agile is a good solution to any problem the company might have,
  • Its important to understand how its going to make the company more competitive in the business that they’re in

Enterprise-level Agile Transformation Strategies

There are a number of different potential strategies at an organizational level 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 also may not be the best solution
  • Fortunately, there are other alternatives companies can select to fit an Agile approach with their business

Organizations typically have different layers of management as shown in the diagram below. And, at each level, there is a choice of:

  • Taking more of an Agile approach or
  • More of a traditional, plan-driven approach:
Making Agile Work for Your Business

Business Process Reengineering

It doesn’t necessarily require throwing out any existing management processes that the company may have:

  • There may be a legitimate reason for some of those management processes
  • Those processes may be already well-aligned with the critical success factors in the business, and
  • It may require some compromise to adapt an Agile development approach to that environment

The approach for doing that analysis is actually similar to a Business Process Reengineering initiative. Check out this article for more on that:

Business Process Reengineering and Agile Transformation

Overall Summary

The important things to recognize are 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
  • It’s also not an easy thing to do and “cookbook” solutions don’t generally work

It’s kind of like a chess game to choose the fit the right strategy to each level of the organization as shown in the diagram below:

Making Agile Work for Your Business

You have to consider an Agile development process in the context of the business it operates in. And, many times you need to adapt an Agile development process to fit the business environment.

  • Within the development process itself, the process may be largely the same
  • The differences may be at a higher-level such as the project portfolio management layer that wraps around the project
  • Those higher-level layers could also be Agile, but
  • That kind of complete, top-to-bottom Agile transformation just doesn’t work in all business environments

Additional Resources

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

My course, “Agile Project Management for Executives” is specifically designed to help business leaders deal with this challenge.