Tag Archives: Agile

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

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

Do You Have Excessive Fear of Failure?

Do You Have Excessive Fear of Failure? I participated in a discussion on LinkedIn this morning that stimulated my thinking. The individual who started the discussion asked the question,

“If a pilot project is discontinued because it didn’t achieve results it had hoped for, would that be considered project failure?”

What’s the Impact of Failure?

The answer seemed obvious to me but it really stimulated my thinking – one of the key things that differentiates an Agile approach from a traditional plan-driven approach is the attitude towards failure:

  • In an Agile environment, a “failure” is regarded in a positive sense as an opportunity for learning and there’s a very popular mantra of “fail early, fail often”. In other words, sometimes you just have to try something and see what works and take a risk rather than being totally risk-averse and attempting to analyze and anticipate every possible risk and contingency before you even get started.
  • In a traditional, plan-driven environment, the attitude towards failure is many times very different. Any significant unexpected event might be regarded as a failure and many times is regarded negatively. There is an inference that it’s a failure in planning that you didn’t do enough upfront planning to anticipate the problem and avoid it.

What’s the Right Approach?

I don’t think either of these two approaches is necessarily right or wrong. Like many things, it depends on the situation. There are some situations that call for a more risk-averse approach and some that don’t:

The Edge of Chaos

  • Some businesses have to operate on the “edge of chaos” because of a highly competitive business environment.
  • If they were overly risk-averse and had excessive fear of failure, they would not be successful in their business and that would be a failure in itself to not do anything to “push the envelope”.
  • Another saying I like is “If you’ve never failed, you’re not trying hard enough”.
  • Amazon.com is probably a good example of a company that has a lot of failures like their smartphone, yet they continue to push the envelope to explore very risky new technology such as package delivery with drones because I’m sure that they feel that they need to continue to “push the envelope” to maintain their competitive position

Other More Conservative Environments

In other environments, the consequences of problems may be much more significant and need to be more thoroughly anticipated and mitigated. Sending an astronaut to the moon might be an example. Check out the book, “Failure Is Not an Option: Mission Control From Mercury to Apollo 13 and Beyond” for more on that

The Gray Area

There’s also a lot of gray area between those extremes where it may require considerable judgment to figure out what the right approach should be.

  • Any project that involves a large amount of uncertainty might be an example. You need to figure out how much of that uncertainty you can tolerate and let it be resolved as the project progresses and how much of it you can’t tolerate and need to resolve upfront before the project starts.
  • It would probably be very irresponsible to take a cavalier approach and ignore the potential impact of risks; but, on the other hand, it could be equally problematic to get bogged down in “analysis paralysis” and never get started trying to anticipate and mitigate every possible risk that could possibly happen.

What Level of Risk Is Acceptable?

The most important thing is to have a clear mutual understanding and a sense of partnership between the project team and the project sponsor about what the goals of the project are, what level of risk is acceptable in the project, and how those risks will be managed.

Agile Projects

In an Agile project, that’s typically easier to do because the relationship with the business sponsor is based on a spirit of trust and partnership as well as openness and transparency and

  • The Business Sponsor (represented by the Product Owner) is expected to have a sufficient level of judgment and maturity to make good, sound decisions on the project.
  • Because there is an understanding that some of the risks and uncertainties will be resolved while the project progresses, the Business Sponsor (represented by the Product Owner) is also intimately involved as the project progresses to provide ongoing direction

Traditional Plan-driven Projects

In many traditional, plan-driven environments, the business sponsors may not have that level of maturity and there may be less of a spirit of partnership with the project team.

  • The Business Sponsors frequently put that responsibility totally on the project team to “just get it done” and don’t necessarily want to know about any risks at all.
  • That can lead to a fear of failure and a “CYA” approach by the project team to over-analyze the project to avoid any possible problems and it can also lead to less-than-open sharing of project information to avoid airing any “dirty laundry” with the project sponsors.

Overall Summary

It seems to me that the partnership approach where the business and the project team mutually agree on the project risks and how they will be managed is a lot more sensible and has numerous advantages.

Additional Resources

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

What is an Enterprise-level Agile Coach?

What is an Enterprise-level Agile Coach? When people use the term “Agile Coach” it is often not exactly clear what they mean.

Typical Team-level Agile Coach Role

Most often, what they’re talking about as an “Agile Coach” is what I would call a team-level Agile Coach. That is someone who works at a tactical level with individual members of an Agile team to help them become more proficient in executing a Scrum process.

  • There is very little standardization or certification for what it takes to become an “Agile Coach” at that level and
  • Almost anyone could claim to be an “Agile Coach”.

What Is an Enterprise-level Agile Coach?

What is an Enterprise-level Agile Coach?

Beyond that; however,

  • The role of an Agile Coach at an enterprise-level needs to be better-defined and differentiated from a normal team-level “Agile Coach” role.
  • An enterprise-level Agile Coach works at a more strategic level to integrate an Agile development process with a company’s business. (See diagram above)

Enterprise-level Challenges

An Agile Coach at an enterprise level typically helps plan and organize an enterprise-level agile transformation.

  • However, many Agile Coaches are only trained in Agile from a team-level development process perspective and make the assumption that whatever is good for the development process must be good for the business as a whole
  • They also may assume that it is a binary and mutually-exclusive decision to be either “Agile” or “Waterfall” and attempt to force-fit the entire company into an Agile model when the right solution is to fit the approach to the company’s business

The Impact of the Business Environment

The problem is that there is a big difference between companies whose primary business is focused on product development and other types of businesses.

Product Development Companies

  • Agile works very well in companies that are in the primary business of developing products (particularly software products). Intuit is an example that develops TurboTax, Quicken, and QuickBooks).
  • In those companies, there is a strong and natural alignment between an Agile development process and the overall business goals of the company
  • It is very easy to apply an Agile development process in that environment.

Non-Product Development Companies

It is much more difficult to apply an Agile development process in a company that is not in the primary business of developing products. In that kind of business, the relationship of an Agile development process to the company’s overall business strategy is much more indirect.

In companies that are not in the primary business of developing products,

  • You can’t just force the company to be “Agile” in order to make the company more amenable to an Agile development process
  • The company’s overall culture and business strategy needs to be optimized around the critical success factors for that business

Fitting the Approach to the Business

For example,

  • If a company is in a business that requires operational excellence, it needs to focus its overall culture and business strategy primarily on efficiency of operations and reducing costs and
  • That doesn’t necessarily align completely with just becoming more “Agile”.
  • In that kind of environment, you have to develop a strategy that considers both the company’s business strategy and the requirements of an Agile development process to develop a well-integrated approach.
  • The implementation of that strategy often requires fitting the approach to the company’s business environment rather than simply trying to force-fit the company to some kind of overall Agile approach.

Blending Agile and Plan-Driven Project Management

The approach that you might wind up with in that kind of environment also could be a blend of Agile and traditional plan-driven management principles and practices blended together in the right proportions to fit the situation. That is a lot more difficult thing to do and requires a lot more skill than a typical team-level Agile coach would normally have. It requires an understanding of:

  • Agile principles and practices; as well as
  • Traditional project management principles and practices
  • And a deeper understanding of the principles behind both of them (not just the mechanics) to know how to blend them together as necessary to fit a given situation

Business Perspective

Beyond that; however, it also requires the ability to look at a very complex, broad-based, enterprise-level business from both a more strategic high-level business management perspective as well as a more tactical product development process perspective to develop a strategy for integrating the two.

What often seems to happen is

  • Someone who is trained in “Agile” from a development process perspective attempts to steer the company in the right direction and
  • That person typically doesn’t have the breadth of business management experience and agile development process experience to know how to successfully integrate the two.

Is it any wonder why some of these “Agile transformations” are not successful?

Additional Resources

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

What’s the Difference Between a Project and a Process?

What’s the difference between a project and a process? I have a very broad view of “project management” but there is a danger of broadening the definition too far. If the definition is broadened too far, almost anything could be “project management” and that would make it meaningless. 

What's the difference between a project and a process?

For example: Is an effort to provide ongoing maintenance and enhancements for a product a “process” or a “project”?   To eliminate potential confusion, we need clearly-defined and objective criteria for drawing a line between the two. What is a “process”, and what is a “project”.

“Process” versus “Project”

I’ve summarized some distinctions between a “process” and a “project” below:

ProcessProject
ObjectiveA “process” has an objective that is typically defined around the ongoing operation of the process. For example, “provide ongoing maintenance for GM vehicles”A “project” has an objective or outcome to be accomplished and the project ends when that objective is accomplished. That objective might be broadly-defined and might change or be further elaborated as the project is in progress. For example, “find a replacement ignition switch that will solve the problem with GM vehicles”.
Time DurationA “process” is generally ongoing and doesn’t normally have an end.A “project” has a beginning and an end (although the beginning and end may not be well-defined when the project starts and the end might be a long time in the future).
Process OrientationA “process” is a repetitive sequence of tasks and the tasks are known at the outset since it is repetitive.The sequence of tasks in a “project” is not normally repetitive and may not be known at the outset of the project.

“Process Management” versus “Project Management”

Here’s a similar distinction between “process management” and “project management”:

Process ManagementProject Management
FocusThe focus of Process management is on managing a process such as a product manufacturing process. Such a process might be used across a variety of projects. Process management might involve some project management to define and improve the process.The focus of Project management is on managing a project typically using some process in achieving some kind of desired end result. Every project follows some kind of process even though it may not be formally defined.
EmphasisThe emphasis of Process management is on increasing “repeatability” of the tasks, improving efficiency (decreasing time needed, reducing cost), and improving quality of the work product produced by the process (including consistency in quality).The emphasis of Project management is on achieving the end result that the project is intended to accomplish. Higher efficiency is harder to achieve since it might require custom tools and methods that can only be developed if the project was turned into a repetitive process.

Overall Summary

In simple, terms:

  • The goal of “Process Management” is to manage existing business processes as efficiently and effectively as possible. An example would be managing a process associated with the current way the business operates.
  • The goal of “Project management” is on managing some kind of change in the way a business operates to make the overall business operate more effectively. An example would be introducing a new product, implementing new processes, etc.

Additional Resources

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

What is a Project?

What is a project? I recently wrote a blog post on “What is Project Management?” that has generated some good comments on LinkedIn.  One of the comments from Wayne Mack on that post was that “the change is not merely to redefine ‘project management’ but to redefine ‘project'”. He is absolutely right.

PMBOK defines a project as follows:

“A project is a temporary endeavor undertaken to create a unique product, service, or result”. The temporary nature of projects indicates that a project has a beginning and an end.”

How Does This Apply to Agile?

There are potentially several problems with applying this definition to an agile project:

  • An agile project may not have a well-defined beginning and end. An Agile project will have an end at some point in time, but the end may be indeterminate when the project starts.
  • An Agile project may be more of an ongoing development effort with an end that is not well-defined and the end, when it happens, may be a long time in the future. That kind of effort might not be considered to be “temporary”.
  • An agile project generally creates “a unique product, service, or result”; however, that “unique product, service, or result” might not be well-defined at the beginning of the project and the goal of the project may be more broadly-defined at the beginning of the project.

This definition is probably based on how people have seen the value provided by a project manager.

  • The value provided by a project manager has traditionally been seen as planning and managing the activities of a project to meet well-defined requirements within expected costs and schedules.
  • Obviously, you can’t do that unless the project has a beginning and an end and the product, service, or result the project is intended to create is relatively well-defined at the beginning of the project.

A More Broadly-Defined Definition

A more broadly-defined initiative to meet a business goal or objective that doesn’t have specific, well-defined requirements at the beginning of the project and may not have a well-defined end-date at the beginning of the project probably wouldn’t fit this definition of a “project”. In that situation, the value provided by a project manager is likely to be very different and may put more emphasis on guiding the people, process, and tools, to maximize the business value that the effort provides.

If we broaden the vision of what “project management” is, we also need to broaden the definition of what a “project” is. There are probably two things that are needed to develop a more general definition:

  1. Drop the second statement that a project has a well-defined beginning and an end
  2. Broaden the first statement to include the potential that a project may be designed to satisfy a more broad-based business objective

The new definition of a project would come out something like this:

“A project is a endeavor undertaken to satisfy a broad-based business objective/outcome or to create a unique product, service, or result”.

Overall Summary

If we broaden the definition of “project Management” to embrace Agile as well as traditional plan-driven projects, we must also broaden the definition of what a “project” is as well.

Additional Resources

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

What is Project Management? Do We Need a Broader Definition?

I recently saw a LinkedIn post on the subject of “What is Project Management?” that suggested the standard PMI definition of project management from PMBOK:

“the application of knowledge, skills, tools and techniques to the project activities to meet project requirements”

What’s Wrong With This Definition?

I had to respond to that because it seems to me that this classic definition that so many people seem to take for granted is way out-of-date.

  • It seems to be based on the narrow, traditional notion that a project manager is someone who manages the costs and schedule of a project to meet defined requirements
  • That implies that there is only one way to do project management and that is based on simply executing a project where the requirements have been defined in advance
  • And “Project Management” is something that is only performed by someone called a “Project Manager”
What Is Project Management

We need to significantly expand that thinking to embrace the idea that a project manager may play a role in a much more uncertain environment where the requirements are less-defined and the project requires a more adaptive (Agile) approach that is focused more on maximizing the value the project produces rather than being totally focused on managing costs and schedules to deliver well-defined requirements.

The person performing that function may not even have the formal title of “Project Manager”. Many people will claim that is not “project management” because there have been so many well-established stereotypes that have developed over the years about what “project management” is.

Project Management Stereotypes

Here are a few of the common stereotypes that exist about project management:

Project Managers Are Very “Command-and-Control” Oriented

Project managers are noted for getting results and sometimes that means being assertive and somewhat directive to set goals and manage the performance of project teams. Many times that behavior is expected of a project manager by the businesses that they operate in. In many companies if a project team is under-performing, the Project Manager is the one held responsible and is expected to take corrective action to get the project on track.

Project Managers Are Rigid and Inflexible and Only Know How to Manage by the “Waterfall” Methodology

For many years, project managers have been held accountable for managing the costs and schedules of projects and we all know that in order to meet cost and schedule goals, you have to control the scope of the project. That, in turn, requires a disciplined approach to defining and documenting detailed requirements and controlling changes where changes become the exception rather than the norm.

The emphasis on managing costs and schedules naturally leads to extensive use of plan-driven or “Waterfall-style” methodologies that are based on trying to define the project requirements in detail upfront before the project starts and controlling changes once the project is in progress.

Project Managers Are Just Not Adaptive and Cannot Adapt to an Agile Environment

Like the other stereotypes, there may be some amount of truth in this stereotype, but it would be inaccurate to generalize and say that this is true of all project managers. Agile will require some considerable rethinking of the project management approach and some project managers are so heavily ingrained in the traditional way of operating because it has been so widely accepted as the norm for such a long time that they may have a difficult time adjusting to an Agile project approach.

Where Does Project Management Fit in Agile/Scrum?

If you look at how an Agile/Scrum project works, there is actually a lot of “project management” going on but many people will not recognize it as “project management” because it doesn’t fit with the traditional stereotype of what “project management” is:

  • In an Agile/Scrum project you may not find anyone at the team level with the title of “Project Manager”
  • The project management functions that would normally be done by a single person called a “Project Manager” are distributed among all the members of the Agile team. For example:
    • Developers – All members of the project team are expected to take responsibility for planning and completing the tasks that they are responsible for to meet commitments that they have made. They are also expected to report progress and coordinate their work with other members of the team as necessary.
    • Scrum Master – The Scrum Master is expected to facilitate team meetings and take action to remove any obstacles if necessary
    • Product Owner – The Product Owner is expected to make any decisions or tradeoffs that might be needed to meet the project goals
    Those are all functions that would normally be performed by a project manager if there was one; they are simply distributed across a number of roles rather than being performed by a single person called a “Project Manager”.
  • It doesn’t use a traditional plan-driven approach to project management – the requirements may not be well-defined at the beginning of the project and it uses a more adaptive approach to further refine the requirements as the project is in progress

Does that mean that there is no “project management” going on?  I don’t think so – it’s just a different kind of “project management” that doesn’t fit the typical narrow stereotype that many people have of what “project management” is.

What is a Broader Definition of “Project Management”?

In my opinion, we need to make some radical shifts in thinking about what “Project Management” is – it’s evident to me that the project management profession and PMI, in particular, seem to unintentionally perpetuate these stereotypes by not addressing these basic definitions that are published in PMBOK that many project managers have taken for granted for many years.

Here’s my suggestion for a broader definition of what “Project Management” is:

“Project Management is the application of knowledge, skills, tools, and techniques to maximize the value that the project produces.”

Project management is focused on maximizing business results within the context of the business environment that a project is part of in a way that is appropriate to the nature of the project.

I’m sure that definition could be fine-tuned, but the key point that I’m trying to get across is that:

  • There isn’t just one way to do project management and one of the greatest skills of anyone performing a project management function should be to select the right approach to fit the nature of the project within the context of the business environment the project is part of.
  • I’m also not excluding the possibility that this function might be performed by someone who doesn’t have the title of “Project Manager” (for example, a Product Owner in an Agile/Scrum project).

The definition of “Project Management” should not be limited to someone who has a title of “Project Manager”. In an Agile environment, “Project Management” functions are often distributed among other roles, but just because they are being done by someone who has does not have a formal title of “Project Manager” doesn’t mean that they are not part of the functional discipline of “Project Management”.

Additional Resources

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

Levels of Mastery in Agile – How Do You Measure Maturity?

I came across the diagram shown below that I think nicely summarizes different levels of mastery in Agile:

Levels of Mastery in Agile

Many people don’t seem to realize that there are these three different levels of mastery and just learning the basic practices is only the beginning.

Three Levels of Mastery

The three levels of mastery are:

1. Practices (Doing)

The initial level of Practices is associated with learning the basic practices of Agile at a mechanical level.

  • There are many people who are at this level of learning – they’ve received their CSM certification (or equivalent) and they may have had some practice in the real world and know how to do the basics.
  • The danger is that many people think that this is all they need to know when they have mastered this level of learning.
  • People who get stuck in this level of learning can become fairly ritualistic or dogmatic and insist that there is only one way to do Agile and that is doing it exactly by the book as they have learned to do it.

2. Principles (Understanding)

People who have gone on to the Principles level of learning have gained a deeper understanding of the principles behind Agile and why it makes sense.

  • This deeper level of understanding gives people a broader perspective – instead of seeing Agile as a mechanical process that must always be done ritualistically “by the book”, people at this level recognize that there may be a need to customize and adapt the processes to fit a given situation.
  • They are also able to see Agile in a much broader context beyond the basic team-level Agile implementation and recognize the need to make Agile work at much higher levels of complexity for large enterprise-level projects.

3. Values (Being)

Values is the highest level of mastery.

  • People at this level of learning not only understand the principles at a deeper level, they also understand the values behind those principles and have internalized those values into the way they work.
  • People at this level are becoming Masters and are at the “top of their game” – they are able to easily go beyond applying Agile to routine Agile project implementations and they are able to apply the principles and practices to much more demanding and difficult situations with much higher levels of consistency and success.

The three levels of mastery shown in this diagram correspond to the “Shu-ha-ri” levels of mastery from martial arts that I have previously discussed:

Agile and Lessons Learned From the Martial Arts

How Does This Relate to Agile Project Management?

How does this relate to the idea of “Agile Project Management”? People who look at Agile and traditional plan-driven project management practices (what many people tend to call “Waterfall”) at a basic level of practices will typically see them as competitive, mutually-exclusive, binary alternatives that are totally incompatible with each other. This is a basic problem and has led to Agile and traditional plan-driven project management being perceived as separate and independent domains of knowledge with little or no integration between the two.

  • I believe that people who are at a higher level of learning and understand the principles behind these two disciplines will see things in a very different perspective.
  • They will probably see them as much more complementary rather than competitive and recognize the reasons why one set of principles and practices makes sense in one situation and not another.
  • They will probably not see them as totally incompatible and be able to easily blend the two sets of principles and practices together as needed to fit a given situation.

Cooks and Chefs

One of my favorite analogies for this that was originally created by Bob Wysocki is the difference between a “cook” and a “chef”:

  • A good “cook” may have the ability to create some very good meals, but those dishes may be limited to a repertoire of standard dishes, and his/her knowledge of how to prepare those meals may be primarily based on following some predefined recipes out of a cookbook.
  • A “chef,” on the other hand, typically has a far greater ability to prepare a much broader range of more sophisticated dishes using much more exotic ingredients in some cases. His/her knowledge of how to prepare those meals is not limited to predefined recipes, and in many cases, a chef will create entirely new and innovative recipes for a given situation. The best chefs are not limited to a single cuisine and are capable of combining dishes from entirely different kinds of cuisine.

This is the challenge that I believe we face in creating a more integrated approach for Agile Project Management. We need to develop more “chefs” who are capable of seeing both Agile and traditional plan-driven project management principles and practices in a very different light as complementary rather than competitive alternatives.

Additional Resources

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

The Next Generation of Project Management – What Is It?

Background

What is the next generation of project management? What is the impact of Agile on the future of project management?

  • Does it mean that project managers who are heavily trained in a traditional plan-driven approach to project management will become obsolete over some period of time?
  • What do project managers need to do to adjust their career direction to adapt to the future direction of project management?

I believe that the project management profession is at a major turning point that requires broadening our view of what “project management” is and reshaping the direction of the project management profession for the future to fully embrace and integrate both Agile and traditional plan-driven project management as complementary approaches within an overall project management portfolio.

Reinventing Project Management

What sort of image comes to your mind when you think of the words “project management”?

  • Does it have any relationship to Agile? My guess is that many people have a very well-ingrained image of what “project management” is and many people wouldn’t associate “project management” with Agile at all.
  • In fact, many people still see those two disciplines as polar opposites.
  • To see things differently, we have to broaden our thinking about what “project management” is and get past many of the well-established stereotypes of what “project management” is.

Long-lasting companies have learned to “reinvent” themselves from time-to-time to keep up with changes in technology and the business environment they operate in. Here’s an excerpt from Harvard Business Review on that topic:

“Sooner or later, all businesses, even the most successful, run out of room to grow. Faced with this unpleasant reality, they are compelled to reinvent themselves periodically. The ability to pull off this difficult feat—to jump from the maturity stage of one business to the growth stage of the next—is what separates high performers from those whose time at the top is all too brief.”

“The potential consequences are dire for any organization that fails to reinvent itself in time. As Matthew S. Olson and Derek van Bever demonstrate in their book Stall Points, once a company runs up against a major stall in its growth, it has less than a 10% chance of ever fully recovering. Those odds are certainly daunting, and they do much to explain why two-thirds of stalled companies are later acquired, taken private, or forced into bankruptcy.”

Source: “Reinvent Your Business Before It’s Too Late”, Harvard Business Review, January 2011,

Here’s another excellent article on that subject:

“A successful company is like a great white shark. In its prime, it chews up the competition, but if it dares to sit still for too long, it dies. Some of the world’s most profitable and enduring companies have achieved their long track record of success by constantly reinventing themselves.”

“Cell phone maker Nokia started off selling rubber boots. The oil giant Shell used to import and sell actual shells. But these companies and the eight others on our list adapted with the times, evolving their product lines and business strategies to stay one step ahead of their customers’ needs. In business, it’s better to be a chameleon than a great white.”

Source: How Stuff Works, “10 Companies That Completely Reinvented Themselves”

Check out the link above for some great examples of companies that have done that successfully. As the article points out, the trick is recognizing that you are at a “stall point” and taking action before you have stalled for very long and that can be a difficult thing to do.

Project Management History

To understand the transformation that is going on, its useful to look at the history of project management and how we got to where we are today:

Early History

Project Management could probably be considered to be one of the world’s oldest professions. Think of the Egyptian pyramids and the Great Wall of China.

  • The level of “project management” at that time may have been very crude and they probably didn’t call it “project management” at all but large efforts like that don’t just happen without some kind of planning and organization behind them.
  • In the US, the development of the Transcontinental Railway in the late 1800’s is another example of a very large effort that had to have some kind of planning and organization behind it.

Scientific Management Approach

Around the turn of the century, along came Frederick Taylor and his co-worker, Henry Gantt. Frederick Taylor started developing new theories on how to organize workers and Henry Gantt created his famous Gantt Charts to describe the order of operations in work.

World War II and the 50’s and 60’s

World War II resulted in the Manhattan project which was another huge effort and the 1950’s and 1960’s had more large scale efforts such as the Polaris missile program and the Apollo program to put a man on the moon. PERT and CPM were invented and then in 1969, PMI was founded.

The Next Generation of Project Management

The general approach for doing project management hasn’t changed significantly since that time and the big question is “What’s next?” and also “Why Now?”

  • Has the project management profession reached its peak or is there yet another major phase of growth that is just beginning to take place? I believe it is the latter.
  • Here’s why I believe it there is some level of urgency to rethink the way we think about “project management” – the diagram below shows how the adoption rate of new technologies has changed over the last century.
Consumption of New Technology Trends

“Source: Mulbrandon, Catherine, Visualizing Economics – Adoption of New Technology Since 1900, http://visualizingeconomics.com/blog/2008/02/18/adoption-of-new-technology-since-1900

This data only goes through 2005, but you can be sure this trend hasn’t slowed down since then. (Think of how quickly smartphones have evolved as an example) This rapid proliferation of new technology calls for a new approach to project management – the traditional, heavily plan-driven approaches of the past can’t keep pace with the speed that technology is changing in many areas.

This dynamic and rapidly changing environment calls for a more adaptive project management approach but that doesn’t necessarily mean that we need to throw out everything we’ve learned about traditional, plan-driven project management and start over again but it does create some significant challenges for individual project managers and for the project management profession, as a whole.

What’s the Impact on Project Managers?

This “raises the bar” for project managers significantly:

  • In the past, if you had a PMP certificate, that was as far as you needed to go for many project management roles.
  • PMI has now created the Agile Certified Professional (ACP) certification and that’s not an easy certification to get, but that’s only the beginning, in my opinion.
  • I think the PMI-ACP exam is good certification but it doesn’t go far enough. It is really mostly a test of terminology – it doesn’t really test whether you know how to integrate Agile and traditional project management principles and practices in the right proportions to fit a given situation and that’s the real challenge for project managers, in my opinion.
  • A good Agile Project Manager also needs to be a strong cross-functional leader – he/she cannot be just a coordinator or administrator. That means he/she needs to have some credible knowledge of the functions included in the project.

What Needs to be Done to Address These Challenges?

This is a huge challenge to transform the project management profession and broaden our thinking of what a “project manager” is and it will take some time. However, I believe that the alternative of ignoring these trends and continuing to think of a project manager in the narrow context of someone who only does traditional, plan-driven project management approaches will seriously degrade and undermine the project management profession over time. Here’s what I think needs to be done to address this challenge:

1. Acknowledge the Need to Make a Change

The first step in any twelve step program is to acknowledge that we have a problem – we cannot deny the impact of Agile on the project management profession and think that traditional, plan-driven project management approaches as we know them will go on forever and Agile is just a fad that will go away.

2. Get Past Sterotypes

There are many stereotypes about what traditional project management is and about what Agile is that we need to overcome and change our thinking to see both Agile and traditional project management approaches as complementary to each other rather than competitive.

3. Redefine Project Management

We have to better define and develop the concept of what an “Agile Project Manager” is and better define the role that an “Agile Project Manager” might play. In my view, an “Agile Project Manager” is not someone who only does Agile projects; it is someone who has a deep knowledge of both Agile and traditional plan-driven principles and practices and knows how to blend them together in the right proportions to fit a given situation.

4. Develop Agile Project Management Training

We need to develop training programs and resources to help project managers reach the goal of becoming an “Agile Project Manager”.

5. Influence Enterprise-level Management Practices

Project Managers are a product of the environment that they work in. For example, many project managers take a heavily plan-driven approach to controlling costs and schedules of a project because that’s what their organizations expect of them. To change the behavior of project managers, we change the expectations of what companies expect of project managers and that can require some significant changes in organizational culture.

Additional Resources

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

I encourage any project manager who needs help in making this transformation to check into my online training courses and to contact me directly if I can be of help.

Was Steve Jobs an Effective Agile Leader?

Was Steve Jobs an effective Agile leader? I watched the movie “Jobs” this weekend about the life of Steve Jobs and his career at Apple and it was very thought-provoking. 

Steve Jobs was absolutely brilliant, embodied a lot of Agile values, and he was enormously successful in developing some very innovative products in a relatively short amount of time that made Apple very successful;  but he was ruthless, tyrannical, and very insensitive in his relationships with people. 

I was thinking – is that style of leadership really consistent with Agile and is it an effective style of leadership for an Agile environment?

  • Much of the thinking behind Agile is based on the idea of empowered and self-organizing teams where the product definition bubbles up rather than being driven down from above,  Steve Jobs’ leadership style doesn’t seem to be very consistent with that model, but he was very successful in getting things done.
  • Another thing that seems to be not entirely consistent with Agile is that Agile is based on the idea of teams working at a “sustainable pace” and it was apparent that many of the teams that worked under Steve’s direction at Apple worked incredible hours to get things done but they were very passionate and dedicated to their work.

Here are some quotes from Steve Jobs that indicate his values that are related to Agile:

  • Focus and Simplicity – “People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things…
    “That’s been one of my mantras – focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”
  • Planning – “Again, you can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something – your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.”
  • Quality – “Be a yardstick of quality. Some people aren’t used to an environment where excellence is expected.”
  • Innovation – “Sometimes when you innovate, you make mistakes. It is best to admit them quickly, and get on with improving your other innovations.”
  • Requirements and Customer Needs – “You can’t just ask customers what they want and then try to give that to them. By the time you get it built, they’ll want something new
  • Seeing the “Big Picture” – “A lot of people in our industry haven’t had very diverse experiences. So they don’t have enough dots to connect, and they end up with very linear solutions without a broad perspective on the problem. The broader one’s understanding of the human experience, the better design we will have…To turn really interesting ideas and fledgling technologies into a company that can continue to innovate for years, it requires a lot of disciplines.”
  • Continuous Improvement – “I have a great respect for incremental improvement, and I’ve done that sort of thing in my life, but I’ve always been attracted to the more revolutionary changes. I don’t know why. Because they’re harder. They’re much more stressful emotionally. And you usually go through a period where everybody tells you that you’ve completely failed.”
  • Tools – “It’s not the tools that you have faith in – tools are just tools. They work, or they don’t work. It’s people you have faith in or not.”
  • Leadership Style – “It’s not about charisma and personality, it’s about results and products and those very bedrock things that are why people at Apple and outside of Apple are getting more excited about the company and what Apple stands for and what its potential is to contribute to the industry…The people who are doing the work are the moving force behind the Macintosh. My job is to create a space for them, to clear out the rest of the organization and keep it at bay.”

And one of his most famous quotes that really sums up his values is “Stay hungry, stay foolish”. 

Overall Summary

My thoughts on this are that:

  • Steve Jobs definitely had some “rough edges” in his relationships with people but he embodies many of the characteristics of an effective Agile leader
  • There probably isn’t one leadership style that is effective in all situations and some “out of the box” thinking is definitely worthwhile rather than implementing some kind of “textbook” Agile approach in all situations

Additional Resources

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