Tag Archives: Agile Transformation

Lean and Agile – Is Lean in Conflict with Agile?

I’ve participated in several discussions and presentations lately where the subject of Lean and Agile came up and I think the relationship of the two is very interesting. If you pursued each of those approaches to the extreme and tried maximize what you would get out of both, they would tend to pull you in different directions:

  • Lean emphasizes reducing “waste” and Agile emphasizes flexibility and adaptivity to meet customer needs.
  • Those two approaches are not totally compatible with each other; however, they are not necessarily incompatible either. It just requires some skill to blend them together in the right proportions to fit a given situation.

Here’s an example, Michael Nir recently made a presentation at an Agile Boston meeting about “The Agile PMO” which was based on his book of the same name. Michael indicated that a key potential role of an Agile PMO is to reduce waste in an organization and that goal is very consistent with Lean. An example of that could be under-utilization of people in the organization.

How Does Lean Reduce Waste?

Michael indicated that a key potential role of an Agile PMO is to reduce waste in an organization and that goal is very consistent with Lean. For example,

  • Under-utilization of people in the organization,
  • Under-utilization of resources, or
  • Less than optimum utilization of resources

could certainly be a major source of waste in an organization. There are a number of ways that a PMO can reduce waste:

Utilization of Specialized Resources

If specialized resources that are not dedicated to project teams (such as DBA’s) are not well-planned and coordinated across teams:

  • Project teams may be idle waiting for these specialized resources, or
  • The specialized resources might not be fully-utilized waiting for work from project teams

Project Portfolio Management

If a project portfolio is not well-managed, allocation of resources to project teams may not be not well-aligned with company business goals and priorities

Project Management of Individual Projects

If individual projects are not well-managed and are allowed to go off track, the allocation of resources to projects may not be optimized to maximize the business results for the company

Development Process Definition and Training

If:

  • The development process is not well-defined,
  • Tools aren’t adequate to support the process, and/or
  • Project teams are not well-trained to execute the process

the execution of the process will not be consistent across teams and may not be as efficient and effective as it could be

In all of those areas, a PMO might add value by reducing waste but how far do you go with that? 

Can You Reduce Waste to Zero?

Carried to an extreme, a focus on simply reducing waste could easily become dysfunctional.  Michael mentioned that waste in some organizations could be as high as 95%.  What would happen if you attempted to reduce waste to 0%?

  • First, reducing waste to 0% is probably an unrealistic and impossible goal. No business is totally predictable where everything is known in advance to enable perfect prioritization, planning, and scheduling of resources
  • Second, putting too much emphasis on reducing waste would would mean superimposing a level of control and standardization on projects. That could easily be inconsistent with achieving the flexibility and adaptivity required by an Agile approach

What’s the Right Answer?

Given that conflict, what’s the right answer?  This is not necessarily an easy problem to solve. It will take some skill to figure out the right blend of:

  1. Focusing on lean and reducing waste and
  2. Preserving the flexibility and adaptivity required by an Agile approach. 

There clearly seems to be an optimum point between the two extremes of focusing on those two extremes individually. A PMO could probably perform a value-added role in helping an organization find that optimum point.

Finding that optimum point is yet another example of the need for “systems thinking”.  Here’s a previous post I wrote on that subject:

http://managedagile.com/2013/04/28/systems-thinking-and-binary-thinking/

People many times like to over-simplify what is really much more complex and reduce it to a simple, binary choice between two extremes: 

  • “Agile” versus “Waterfall” is one example of that and
  • “Lean” versus “Agile” is another example. 

Overall Summary

On the surface, Lean and Agile might appear to be in conflict with each other. If you pursued each approach individually and mechanically without really understanding the principles behind each at a deeper level, they could easily be in conflict. 

On the other hand, if you take take a systems-thinking approach to understand these seemingly disparate approaches at a deeper level. you will begin to develop a fresh new perspective to see them as complementary to each other rather than competitive.

Michael made a key point that it is a matter of focusing on value versus control and he’s absolutely right.  Here are some ways a PMO could add value:

  • Better defining processes and tools,
  • Providing training to people, and
  • Doing some level of project portfolio management and resource planning of people

Each of those can potentially add value; however, it does take some skill to determine the optimum point beyond which it stops producing value and starts to become dysfunctional.

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”…

Adaptability

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

Time-to-Market

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.