Is Agility Just a Toolkit?

I saw a blog post this morning that I have to respond to because it is so misguided and misleading. The blog post is entitled “Project Managers – Is Agility Just a Toolbox That You Can Simply Pick and Choose From?“.

The essence of this post is that there are project managers who have acquired “a PMI-ACP certification and little else in real-world Agile experience” and see “agile and traditional project management as a toolbox” that they can just mix-and-match together. There is an implication that I and others who have advocated blending the two approaches together as necessary to fit a given situation are in that category; however, that indicates a fundamental misunderstanding.

Learning to blend Agile principles and practices in the right proportions with traditional project management principles and practices to fit a given situation can be a difficult thing to do and it’s not just a matter of picking-and-choosing different “tools from different toolkits” and blindly mixing them together – it takes a lot more skill than that. It is more a matter of developing the right mindset to rise above the level of seeing different approaches as a collection of mechanical practices and seeing the principles behind the approaches at a deeper level as complementary rather than competitive. An additional obstacle is that there are many stereotypes and misconceptions on both sides of the fence that you have to get past to develop an objective point of view in order to see this in that kind of perspective.

In my book. I use the analogy of a project manager as a “cook” versus a “chef” (Bob Wysocki who originally created that analogy but I’ve used it a number of times). A “cook” knows how to prepare a limited number of recipes and does it “by the book” without much improvisation. A “chef” knows how to prepare a much broader range of recipes with more exotic ingredients and also knows how to prepare his or her own unique recipes to fit a given situation. I think that analogy fits this situation very well – in order to learn how to blend Agile and traditional plan-driven principles and practices, we need more people who are “chef’s” rather than “cook’s”. Being a good cook is not a matter of randomly picking out spices from different spice racks and mixing them together – it takes a lot more skill than that and learning how to blend Agile and traditional plan-driven principles and practices is the same way.

I’ve developed a free online training course called “Learn the Truth About Agile versus Waterfall” that is only 30 minutes long that is designed to help people see “Agile” and “Waterfall” in a fresh, new perspective as complementary to each other rather than competitive – you can check it out here:

https://www.udemy.com/learn-the-truth-about-agile-versus-waterfall/

Business Process Reengineering and Agile

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

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 but it was a gut-wrenching change for many companies because implementing an ERP system in many cases required rethinking their business processes to 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

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

  • 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’s 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?
  • The next statement is “In Business Process Reengineering, companies start with a blank sheet of paper and 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.
  • 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 but that needs to be done in a larger context of how it improves the customer value that the company delivers to its customers.
  • 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”

I’m not defending BPR, there were definitely some problems in the way it was implemented, but there’s a lot we can learn from it (both good and bad). If more companies realized how similar to Business Process Reengineering is to an Agile transformation and treated it that way, the probability of success would probably be significantly higher. It expands your thinking to see an Agile transformation in an overall business context rather than a very limited development-centric perspective.

I’ve developed a new online training course called “Making Agile Work for Your Business” that is designed to help companies see this perspective and to take a business-centric approach to successfully integrate an Agile development approach into their business.

What’s Next After PMI-ACP®?

I recently participated in a forum on PMI-ACP® when someone asked “What’s next after PMI-ACP®?”. I thought it was an interesting discussion and is worth elaborating on further. I believe that the individual who asked the question was wondering what new certifications PMI is going to come out with for people who have a PMI-ACP certificattion and are interested in continuing to advance their knowledge and career in that direction.

It’s a perfectly understandable question but, unfortunately, the answer may not be what you might want to hear. It raises a much larger question of what’s an “Agile Project Manager”? and what’s the career path for someone who has a project management background and is interested in developing into an Agile Project Management role? Many project managers have been thinking that PMI-ACP® would open up a new career path into Agile and it’s just a matter of getting another certification to move further, but I don’t believe that to be the case for a couple of reasons:

  • The role of an “Agile Project Manager” is not well-defined and is also somewhat controversial at this point in time. it’s very difficult to certify someone to have those skills when they are not well defined and contentious.
  • The PMI-ACP® certification tests general knowledge about Agile and Lean and is not designed around a specific role like the CSM (Certified Scrum Master) certification is.
  • Agile is much more heavily based on “tacit” knowledge versus “explicit” knowledge. It requires a lot more judgment and it’s not something that you can easily codify in a document like PMBOK that you can test and certify people against. For that reason, even if the idea of an “Agile Project Manager” was more well-understood, it still might be very difficult to develop a certification exam to test that someone really has the skills to fill that role.

The PMI-ACP certification is a great step in the right direction by PMI to try to close the gap between traditional plan-driven project management and Agile but it just doesn’t go far enough and it also leaves open some very large questions that any project manager who is interested in Agile would naturally want to have answered about what their career path is. Agile is rapidly changing the whole “ball game” for project managers and it’s very understandable that project managers have questions about what their career direction is.

The truth is that any project manager who has a PMI-ACP® certification who wants to further develop into an Agile Project Management role has to be somewhat of a “pioneer” to lead the way for other project managers at this point in time. It can be a difficult transformation, it’s certainly not a matter of just getting another certification, and the ultimate role you wind up in may be very different from a conventional notion of what “project management” is. You have to be a real self-starter to start out on that journey but I think it’s a survival issue for many people in the project management profession to move in that direction.

I am passionate about helping project managers move in this direction and I’ve developed some training courses to help. Check out this video for a summary of the training courses I’ve developed and how I think they help people make this transformation:

What’s Next Beyond PMI-ACP®?

This is a difficult problem but I believe that this is critical to the future of the project management profession and I’m determined to help project managers make this transformation. You can find more detailed information on any of my training courses here:

Agile Project Management Training Course Details

Agile Contracts

A lot of people may think that it is inconsistent to impose constraints that the project needs to be completed within a certain expected cost and schedule on an Agile project. It is difficult, but it definitely can be done – one of the areas where that becomes essential is Agile contracts. For example, I once managed a large federal government project that had all the typical government contracting requirements for cost and schedule milestones; but, at the same time, the government customer wanted some level of flexibility to work out detailed requirements as the project progresses.

Does that sound inconsistent? It might be depending on the relationship you have with the customer. Obviously, this will only work if there is a spirit of trust and partnership with the customer to collaboratively agree to work out any tradeoffs between the scope of the requirements and the cost and schedule of the contract as it progresses. If there is more of a typical “arms-length” contracting relationship or some kind of adversarial relationship, it’s not going to work at all.

Doing this requires a hybrid Agile approach that blends an Agile development approach with a plan-driven “shell”. The plan-driven shell provides some level of predictability and control over the overall scope, cost, and schedule of the project while the Agile development approach operates within that shell to provide some level of flexibility and adaptivity in the detailed requirements. That approach is described in more detail in my article on the “Managed Agile Development Framework“.

Jeff Sutherland has created a very nice model for this called “Money for Nothing, Change for Free”. Jeff’s approach is based on two primary clauses in an Agile contract:

  • “Change for Free”

    The “Change for Free” clause is based on the idea that the customer can make any change they want provided that the total contract work is not changed. This allows new features to be added provided that lower priority items are removed from the project. I have documented a case study in my book on how General Dynamics, UK successfully used this approach on a large government contract in the UK.

  • “Money for Nothing”

    The “Money for Nothing” clause is interesting. It recognizes the fact that in many projects, the customer always asks for everything that they could possibly need but if you prioritize those items and deliver the highest priority items first, at some point you will reach a point of diminishing returns where the cost of developing incremental features exceeds the value that those features provide. This clause allows the customer to cancel the contract at that point and save 80% of the cost that would have been spent to complete the remaining items; however the contractor receives a fee of 20% of the cost for early cancellation which makes it a win/win for both the customer and the supplier.

This concept is not limited to fixed-price contracts – that’s only the extreme case. It can be applied to almost any Agile project where there is a need for some level of predictability and control over the costs and schedule of the project. Very few people get a “blank check” to do an Agile project without any expectations of what will be delivered and what the estimated cost and schedule of the project are likely to be.

A “Business Centric” Approach to Agile

Many Agile coaching and consulting companies take what I would call a “developer-centric” approach to Agile. It 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.

What I’ve seen frequently is that 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 “Agile” and what’s commonly called “Waterfall”. That over-simplifies what I believe is a much more complicated decision and the result of that is that people often try to force-fit a company’s business into an Agile approach. The right solution, in my opinion, is to go in the other direction and fit the approach to the company’s business and sometimes that may require blending an Agile approach with a more traditional management approach in the right proportions to fit the company’s business rather than force-fitting the whole company to an Agile 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?” and the answer to those questions may be very different depending on the nature of the company’s business. Check out my article on “Where Does it Hurt?” for more on that. Agile works best in companies that are in the business of developing software products like Intuit who develops Quicken, QuickBooks, and TurboTax and other companies where software development has a very direct relationship to their business objectives like an Amazon.com which is very technology-driven.

In those companies, there is a strong and direct alignment between an Agile development process and the company’s business objectives and it is relatively easy to implement an Agile development approach in that environment. In companies that are not in the primary business of developing software products, the relationship between the development process and the company’s business objectives is typically much more indirect and there is less of a natural alignment between an Agile development approach and the company’s business objectives.

The key to developing a more business-centric approach is that you have to recognize that at an enterprise level, 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, if a company like Walmart is in a business that demands “operational excellence” as the primary value discipline, one of the most important critical success factors in their business is going to be reducing costs to be most competitive. How does an Agile development approach contribute to achieving that objective? The answer isn’t necessarily obvious.

What’s needed in this situation in many cases is more of a “top-down” business analysis to identify potential areas for process improvement so that those initiatives are really well-aligned 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 they might have and start working on making them more agile, you have to figure out how its really going to benefit the company and make the company more competitive in the business that they’re in.

It also doesn’t necessarily require throwing out any existing management processes that they may have and making the whole company more Agile. There may be a legitimate reason for some of those management processes that are already aligned with the critical success factors in their business and it may require some compromise to adapt an Agile development approach to that environment. In the 1990’s and early 2000’s, I did a lot of work with companies on large-scale process improvement and business process reengineering initiatives and even though that effort had nothing to do with Agile at the time, the methodology you would use to do a business-centric Agile transformation would be very similar.

This is a great example of what I call the “Program du Jour”. When a new management approach like Agile comes along, we often “throw the baby out with the bath water” and consider anything that came before it as obsolete and passé. I saw a similar thing when Six Sigma was hot in the early 2000’s. Everyone wanted to jump on the Six Sigma bandwagon, there was a lot of hoopla about it (like green belts and black belts, etc.), any other process improvement methodology that came before it was considered out-of-date, and people got lost in the mechanics of Six Sigma without understanding how it really helped their business.

I published my first book at that time in 2003 and did quite a bit of research before writing my book. What I found was that the companies I considered most successful in implementing Six Sigma had so thoroughly integrated it into the way they did business that it might not have been easily identifiable as Six Sigma and they may not have even called it “Six Sigma”. I think a similar thing is needed with Agile today…companies need to go beyond the mechanics of simply implementing “Agile” and figure out how to really integrate it into the way they do business and there isn’t just one canned way to do that. The approach for doing that may be very different depending on the nature of the company’s business.

To do this, requires a broader approach for implementing an enterprise-level Agile transformation that blends a top-down business-centric approach with a bottom-up developer-centric approach in the right proportions. The basic approach for doing that top-down “business-centric” approach to identify areas of process improvement for the business might not be a lot different from what we did 10 years ago for some of the business process improvement initiatives and business process reengineering initiatives I was involved in at that time that had absolutely nothing to do with Agile.

In fact, an Agile transformation is very similar to what you would do in a major business process reengineering effort. Of course, there are many ways to do this top-down business centric analysis depending on the nature of the company’s business and the company’s appetite for making a significant change but this can be a way to keep an Agile transformation well-aligned with the company’s business objectives rather than simply becoming Agile for the sake of becoming Agile.

An Agile Approach to Risk Management

I recently participated in a LinkedIn discussion on risk management that was heavily focused on a conventional approach to risk management built around a plan-driven approach to project management. I wanted to share my thoughts on how I think we need to take a broader view of risk management that would be appropriate for an Agile project environment as well as a traditional plan-driven project management environment.

First, let me preface this post by saying that I’m not an “Agile zealot”. If you’ve read any of my other posts or books or taken my training courses, I’m sure you recognize that I think that there is a widely-held misconception that:

  • “Agile” and “Waterfall” are polar opposites of each other, and
  • There is a binary and mutually-exclusive choice between the two approaches

I think we need to broaden our view of project management to see “Agile” and what is commonly called “Waterfall” as complementary to each other rather than competitive and recognize that traditional plan-driven project management is not the only approach to project management. I prefer to think of a continuous range of alternatives from heavily plan-driven at one extreme to heavily adaptive at the other extreme that looks something like this:

Agility Range

And, the right thing to do is to fit the approach to the project rather than force-fitting a project to some arbitrary model (whatever it might be – Agile or plan-driven). One of the biggest characteristics that would influence the choice of an approach is the level of uncertainty in the project.

If you think of a broader approach to project management in those terms, it has a big impact on how you might do risk management. Here’s how I see some of the key differences in a risk management approach that might be associated with a more adaptive approach to project management in a very uncertain environment:

Why is Risk Management Different in an Agile or More Adaptive Environment?

  1. Definition of “Failure” – Risk is associated with the failure of a project, so how you define “failure” has a big impact on how you do risk management.
    • In a traditional plan-driven project, the requirements of the project are typically well-defined and a “failure” would normally be associated with failing to deliver those requirements within the required cost and schedule budgets allocated for the project. In that kind of environment, it wouldn’t normally be considered a failure if the project met the requirements it was supposed to meet within the cost and schedule goals but failed to deliver the appropriate business value.
    • That approach works fine in an environment where it is possible to relatively accurately define the requirements of the project before the project starts and three is a reasonable level of certainty that if you meet the defined requirements, the project will automatically produce the appropriate business value that is required.

    • An Agile or more adaptive approach is best in situations where it is much more difficult to define detailed requirements for the project prior to the start of the project and there is far less certainty of what is required to produce the appropriate business value. In that kind of environment, there is a much larger risk that the project won’t produce the required business value even if it does meet the defined requirements within budgeted cost and schedule goals. That’s a very important difference between an Agile (or adaptive) approach and a more traditional plan-driven approach.
  2. Relationship to Upfront Planning – Since an Agile approach normally has a lot less upfront planning, it typically requires a more dynamic approach for identifying and managing some of the risks while the project is in progress rather than a comprehensive approach to identify and anticipate risks before the project starts.

    Note that this is not an all-or-nothing choice between zero upfront planning and highly detailed and rigid upfront planning – the approach to planning could be anywhere between those extremes and the approach to risk management should be consistent with the level of planning.

    The important point is that it just isn’t practical to take a comprehensive approach to identify and anticipate all risks in a project with a very limited amount of upfront planning.

  3. The Relationship to Business Value – The risk of not producing the appropriate business value in a very uncertain environment is a very different kind of risk and requires a different kind of risk management approach. That kind of risk isn’t necessarily totally black-and-white – you could produce a relatively mediocre product that met the letter of the requirements but really didn’t provide much business value.

    A conventional approach to risk management is generally based on avoiding and eliminating risks and uncertainty as much as possible so that the project will deliver predictable results, but that approach can work against you if you have a goal of maximizing business value. (See my previous article on Management of Uncertainty in Agile Projects).

    In many cases, risk is associated with opportunities to provide a higher level of business value. With a conventional approach to risk management, you might try to reduce the level of uncertainty and ambiguity associated with user requirements as much as possible prior to the start of the project and you might also tend to favor a low risk approach of using tried-and-true technology rather than “pushing the envelope” a bit to use riskier technology that might provide a higher level of value to the user. From a conventional risk management perspective, that may be the right thing to do but it could easily result in a very mediocre product that doesn’t provide much business value.

How is the Approach to Risk Management Likely to be Different in an Agile environment?

Some people might think that risk management isn’t appropriate in an Agile environment – I don’t believe that to be the case. You can do as much or as little risk management as needed depending on the nature of the project – it just requires a different approach to risk management.

  1. It needs to recognize a broader definition of “failure” – a project can fail by failing to deliver business value even if it meets defined requirements and meets its cost and schedule goals
  2. The approach to risk management needs to be consistent with the overall level of upfront planning in the project – that might mean a less comprehensive identification and analysis of risks prior to the start of the project and a more dynamic approach to risk management as the project is in progress.
  3. Instead of seeing all risks as a bad thing that should be avoided and eliminated, we need to recognize that some risks are related to opportunities. For that reason, a decision to avoid or eliminate risks needs to consider the impact of potential missed opportunities as well as the impact of the risk.

Advantages of an Agile or Adaptive Risk Management Approach

In fact, an Agile or adaptive approach can have a lot of advantages for developing a very effective risk management approach. Steve Gordon commented that Agile or adaptive thinking provides the ability to structure a project to fail early and inexpensively to minimize the impact of a risk on the overall project. Wayne Mack also suggested several more specific risk management advantages that an Agile or adaptive approach can provide:

  • “Technical risks are addressed through early prototypes (“spike stories”) and side-by-side comparison of alternatives (‘A/B testing’)”
  • “Integration risk is mitigated through early and continuous integration. User acceptance risk is mitigated through early product review”
  • “Cost and schedule risk is mitigated through incremental releases – we always have something to show for the money spent; it is no longer an all or nothing trade-off”

Management of Uncertainty in Agile Projects

One of the biggest advantages of an Agile approach is the ability to manage higher levels of uncertainty. Agile is based on an empirical process approach – the word “empirical” means “based on experiment or observation”. When you use an empirical process approach, you accept that you don’t know everything you might want to know about a project before you start and the process is designed to adapt both the solution and the process to discover the solution to learning as the project progresses.

A “Defined Process” is repeatable and doesn’t change significantly from one project to the next and is very predictable in the results it produces while an “Empirical Process” is specifically intended to favor adaptability over predictability. For that reason, an empirical process is much better suited for a project with high levels of uncertainty.

A very powerful concept for understanding uncertainty is the “Stacey Complexity Model” which is shown below:

Stacey Diagram

There are two dimensions of uncertainty in this model:

  • One dimension is requirements uncertainty – How well understood are the goals and requirements for the project and how certain are the customers that they know what they want?
  • The other dimension is technology uncertainty – How well understood is the technology solution to the problem and what is the level of risk associated with the technology solution?

This is a very important concept because the ability to handle uncertainty is so important in today’s most critical projects and heavily plan-driven projects are not well-designed to deal with high levels of uncertainty. What typically happens in a plan-driven project is the project manager tries to reduce the level of uncertainty to an acceptable level before starting the project by:

  • Trying to resolve any uncertainties in the requirements as much as possible before the project starts, and
  • Trying to eliminate as much technology risk as possible

This often results in using tried-and-proven technology and doesn’t push the envelope too far in terms of going into areas of new and undefined user requirements. The downside of that, of course, is that the technology approach may wind up being obsolete within a relatively short amount of time after it is released and it may also result in a very mediocre user experience with the solution.

Let me clarify what I mean by “managing uncertainty”. To some people, uncertainty is like a cancer that attacks a project and can cause it to fail and conventional project management thinking has reinforced this approach to reduce the risk and uncertainty in a project as much as possible. I don’t see it that way uncertainty can also represent opportunity to go beyond what is expected and the value a project produces is many times directly related to the risk and uncertainty in the project. If you force a project to fit into a plan-driven model by reducing the risk and uncertainty, you may be maximizing the predictability of the project to meet cost and schedule goals but minimizing the value that the project produces.

That doesn’t mean that uncertainty should be ignored and not managed at all and fortunately, this is not a black-and-white, either/or decision between a totally rigid, plan-driven approach with almost zero uncertainty and a totally adaptive approach with an extremely high level of uncertainty. The right thing to do is to fit the approach to the level of uncertainty in the project rather than force-fitting a project to some kind of canned approach (whatever it might be). It takes more skill to develop an intelligent approach for managing uncertainty – it requires:

  • The ability to objectively assess the level of uncertainty in a project
  • An understanding of both empirical and defined process models
  • A deeper understanding of the principles behind these approaches to know how to blend the two together to fit the situation

The ability to do that is the essence of what I believe is an effective Agile Project Management approach.