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 things are not totally compatible with each other; but that doesn’t mean that they are incompatible. It just requires some skill to blend them together in the right proportions to fit a given situation.
Here’s an example, I attended a presentation at an Agile Boston meeting last night by Michael Nir who talked 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 – 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 could happen:
- The utilization of shared, specialized resources such as DBA’s that are not dedicated to project teams is not well-planned and coordinated across teams. As a result, 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 is not well-managed. As a result, allocation of resources to project teams may not be not well-aligned with company business goals and priorities.
- Individual projects are not well-managed and are allowed to go off track. As a result, the allocation of resources to projects may not be optimized to maximize the business results for the company.
- 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. As a result, the execution of the process is not consistent across teams and is not as efficient and effective as it could be.
It seems clear that all of these things could result in wasted resources and could be considered legitimate areas that a PMO could add value to but how far do you go with that? 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, it probably would not be successful because reducing waste to 0% is probably an unrealistic and impossible goal just because no business is totally predictable where everything is known in advance to enable perfect prioritization, planning, and scheduling of resources
- Second, at some point, putting too much emphasis on reducing waste would tend to run counter to Agile because it would mean superimposing a level of control and standardization on projects that would likely be inconsistent with achieving the flexibility and adaptivity required by an Agile approach
So, what’s the right answer? This is not necessarily an easy problem to solve and it will take some skill to figure out what is the right blend of (1) focusing on lean and reducing waste and (2) preserving the flexibility and adaptivity that is required by an Agile approach. There clearly seems to be an optimum point between the two extremes of focusing on those two extremes individually and a PMO could probably perform a value-added role in helping an organization find that optimum point.
This 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, which it is not. “Agile” versus “Waterfall” is one example of that and “Lean” versus “Agile” is yet another example. On the surface, those approaches might appear to be in conflict with each other; and, if you pursued each approach individually and mechanically “by the book” without really understanding the principles behind it at a deeper level, they could easily be in conflict. It takes some skill to take a systems thinking approach to understand these seemingly disparate approaches at a deeper level and see them as complementary to each other rather than competitive but it can be done.
Michael made a key point last night that it is a matter of focusing on value versus control and he’s absolutely right. Better defining processes and tools, providing training to people, and doing some level of project portfolio management and resource planning of people is something that can definitely add value if it is done in the spirit of adding value; but it does take some skill to determine the optimum point beyond which is stops producing value and starts to become dysfunctional.