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 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.

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…

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 and I think it is fundamentally the wrong approach to try to convince someone to become more Agile rather than focusing on how becoming more Agile will help them and what problem it will solve.

I also very strongly believe that there is not a binary and mutually-exclusive choice between “Agile” and “Waterfall”; and, 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 (whatever it might be – Agile or plan-driven or some combination of both) to the situation. It takes a lot more skill to do that but it definitely can be done. It requires:

  • A broader knowledge of different methodologies (both Agile or adaptive and plan-driven) and an ability to see past many of the stereotypes, myths, and misconceptions that exist about what’s commonly referred to as “Agile” and “Waterfall” to see those two approaches in a fresh, new perspective as being complementary to each other rather than competitive and to objectively understand the strengths and weaknesses of both approaches
  • 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
  • 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) to understand how to blend different, seemingly disparate methodologies together as needed to fit a given situation

I’ve developed a set of online training courses that are specifically designed to help prepare people for those challenges, you can check that out here:

Agile Project Management Training Courses

However, if you’re trying to “sell” a manager on becoming more agile, he/she probably doesn’t have all of those skills and they’re 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:

  1. 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 that 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.
  2. 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.
  3. Finally, nothing sells better than results. Work on developing good results and that will sell itself.

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 – a lot of people have the impression that an Agile project is always faster and that’s generally true but not always true. The real emphasis in Agile, in my opinion, is keeping the customer closely-engaged with the project as it progresses to ensure that what you’re developing really meets their needs. Sometimes that may actually take longer because it may involve some trial-and-error. However, very few people could argue that prioritizing requirements and delivering functionality incrementally rather than waiting to deliver the entire project all at once can significantly accelerate progress even if you don’t take a full Agile approach.
  • 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 SatisfactionFinally, as I’ve mentioned, the big selling point of Agile is the improved customer satisfaction you get 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

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” and it doesn’t necessarily require adopting a full-blown textbook Agile approach like Scrum and/or risk losing control of your business to get some of these benefits. Also, in addition to those more tangible benefits, there are also a lot of intangible benefits such as:

  • Improved employee productivity and morale that results from more empowered teams
  • Improved organizational synergy that results from higher levels of collaboration, trust, and shared responsibility within the organization

I want to add one note to this post that came out of some follow-up discussions we had on LinkedIn on this post…The word “selling” has a variety of different connotations. Some people regard “selling” as a manipulative process to convince someone to buy something they don’t want (like life insurance or used cars).

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 do a lot active listening to understand their problem before attempting to sell any solution. I think that’s the right 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.

Making Agile Work for Your Business

Background

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 I believe that there are some significant misconceptions behind these failures:

  • Agile versus Waterfall – At the project management level, there is a big misconception that there is a binary and mutually-exclusive choice between an Agile approach and a traditional plan-driven project management approach (or what people many times refer to loosely as “Waterfall”). The result of this misconception is that people often try to force-fit projects to one of those extremes when a much better solution is to fit the approach to the project and sometimes a hybrid of the two approaches is the best fit. (See my online training course “Learning the Truth About Agile versus Waterfall” for more on that)
  • Aligning Agile With a Business Strategy – Another big misconception is that whatever is good for the development process must be good for the company as a whole and that is also not necessarily the case. At the business management level, the approach should be designed around what makes the most sense for the company’s business and 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.
    • An Agile development process is easiest to apply in companies whose primary business is developing software products (Such as Intuit QuickBooks and TurboTax) or companies where software development has a very direct and significant leverage effect on the company’s business (Such as Amazon.com). In those companies, there is a fairly direct alignment between a company’s overall business management goals and an Agile development process.
    • In companies where that is not the case, the alignment may be less direct. For example, it may or may not be totally realistic for a company to adopt a complete, top-to-bottom Agile approach for their entire business and a more traditional, plan-driven approach may be appropriate at the higher levels (at least as an interim solution). However, that doesn’t preclude implementing a totally Agile or hybrid Agile development process. The Managed Agile Development process is an example of a hybrid Agile approach that can be used in that kind of environment.
  • 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:

    Enterprise Agile Frameworks

    Overall Summary

    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. 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:

    Enterprise Agile 2

    It should be apparent that making Agile work at an enterprise level isn’t necessarily as simple as it might seem and requires a broad understanding of both the business strategy and the development strategy to fit the two together. For more information on this subject, check out my online training course on “Making Agile Work for Your Business”.