Tag Archives: Agile Project Management

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

What is an Agile PMO? Is it Possible? How Would it Work?

Background

I recently saw a question on a LinkedIn discussion group asking: What is an Agile PMO?

  • There are many people in the Agile community who might say that there is no role for a PMO in an Agile/Lean environment and
  • That the whole concept of a PMO is inconsistent with Agile.
  • That opinion is based on a stereotype that the role of the PMO is heavily associated with controlling and enforcing rigid, waterfall-style policies for selecting and managing the execution of projects and programs.

In that kind of environment, a PMO might require:

  • Very thorough and detailed upfront planning to justify the ROI on projects to support rigorous project/product portfolio management decisions
  • Rigid control of project execution to ensure that projects meet their cost and schedule goals and deliver the expected ROI

There is no doubt that some PMO’s have played that kind of role to some extent in the past; however, it is a stereotype to believe that is the only possible role for a PMO to play.

Understanding the Truth About “Agile versus Waterfall”

The key to understanding this issue is to first understand that there is not a binary and mutually-exclusive choice between “Agile” and “Waterfall”.  It is better to think of this as a range of alternatives between heavily plan-driven at one extreme and heavily adaptive at the other extreme. That looks something like this:

Range of Agility

And, the right approach is to fit the methodology to the nature of the project and business environment rather than going in the other direction and attempting to force-fit projects and business to some kind of canned approach (whatever it might be – Agile or not).

What’s the General Role of a PMO in Any Organization?

The general role of any PMO is to:

  • Align the selection and execution of projects and programs with the organization’s business goals. That includes:
    • Project/Product Portfolio Management,
    • Providing oversight of project execution and
    • The overall interface for management and reporting of projects and programs to senior management and the business
  • Coordination, guidance, and training to project teams as needed in the organization’s methodologies and standards for project management.

Those general functions probably don’t change in an Agile/Lean project environment. However, how a PMO performs those functions may change significantly depending on the organization’s overall strategy 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 may also may not be the best solution

It may be a mistake to believe that you have to force a company to do an extensive, top-to-bottom Agile transformation in order to adopt an Agile process at the development level.  There are many ways to adapt an agile development process to a company whose overall business may not be totally compatible with an agile approach at the enterprise level.

If you accept the notion that you need to tailor the approach to fit the nature of the business, it should be evident that:

  • The design of a PMO should be consistent with that approach and
  • There isn’t a single “canned” solution for what an “Agile PMO” is.  However, there are some general guidelines that should be useful.

What Does a Traditional PMO Look Like?

A traditional PMO organization that is oriented around a heavily plan-driven approach might look something like this:

Typical Traditional PMO Structure
Reference: Cobb, Charles, “Making Sense of Agile Project Management”, Wiley, 2011

In this kind of environment:

  • The PMO typically takes almost complete responsibility for the execution of projects on behalf of the business sponsors
  • The emphasis in this kind of organization is typically on planning and control of projects

This kind of organization would be consistent with a heavily plan-driven approach. However, how does that role change as an organization moves towards more of an adaptive approach?

What is an Agile PMO?

A more adaptive version of a PMO organization might look something like this:

What is an Agile PMO?
Potential Agile PMO Structure
Reference: Cobb, Charles, “Making Sense of Agile Project Management”, Wiley, 2011

Key Differences

Here’s what some of the key differences might be as an organization moves towards more of an adaptive (Agile) approach:

Advisory Role

The role of the PMO becomes more of an advisory role and a consultative role rather than a controlling role. The function of the PMO should be to:

  • Put in place well-trained people coupled with
  • The right process and tools
  • To make the process most effective and efficient and
  • To keep it well-aligned with the company’s business

Primary Responsibility

The primary responsibility for providing direction to projects:

  • Shifts more to the business side represented by the Product Owner in the projects and
  • There is a much more of a closer coupling with the business side, and
  • There is more emphasis on the PMO providing business value rather than simply managing project costs and schedules

Role of Functional Organizations

The role of the functional organizations (Development, QA Testing, etc.) also changes to providing more of an advisory function as the resources are more committed to project teams and the project teams become more self-organizing

Key Challenges

This model can be a very big change for many businesses because:

  • It puts a lot more responsibility on the business side of the organization to provide direction to projects. And, the business organization may not be well-prepared to take on that responsibility
  • It requires developing a close collaborative relationship between the project team and the business rather than using a PMO as a “middle-man”
  • It also relies much more heavily on self-organizing teams

For those reasons and others, a totally adaptive approach may not be the right approach for all businesses. And, even if it is, it may take time to migrate an existing organization to that kind of approach. Fortunately, there are many ways to develop a hybrid approach to blend a traditional plan-driven approach with a more adaptive approach to fit a given business and project environment.

Hybrid Environments

The role of the PMO should be aligned with supporting whatever the overall business strategy is. That might require a hybrid of an Agile and traditional plan-driven approach. For example, here are some of the ways that a hybrid approach might be implemented:

Project/Product Portfolio Management

The PMO may still be the focal point for Project/Product Portfolio Management. However, a more agile approach might be used to perform that function.

  • Instead of very rigorous upfront planning that might be required to analyze project ROI to support a more traditional, plan-driven project/product portfolio management approach,
  • A more dynamic decision-making process might be used at that level with a much more limited amount of upfront planning and less-detailed ROI analysis.

Project Execution

In the other functions related to managing the execution of projects, the PMO:

  • Probably would probably delegate more responsibility to project teams and
  • Play more of a facilitative and consultative role to support the project teams rather than playing a controlling role.

Overall Summary

In summary,

  • Agile certainly forces some rethinking of the role of a PMO. However, it doesn’t necessarily make the whole concept of a PMO obsolete and irrelevant
  • There are a wide range of strategies an organization can choose for implementing an Agile transformation at an enterprise level. It isn’t necessarily a binary choice between a pure “Waterfall approach from top-to-bottom or a totally “Agile” approach from top-to-bottom. You have to choose the right approach to fit the business rather than attempting to force-fit the business to some kind of “textbook” approach.

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.

Additional Resources

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

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.

Learn the Truth About Agile versus Waterfall – Are They Really Complementary?

Agile Versus Waterfall

How many times have you heard people compare Agile versus Waterfall? It happens a lot, I do it myself, and I keep hearing presentations that talk about how Agile has displaced Waterfall. But, if you really think about it, I don’t think that’s a very meaningful comparison and it’s out-of-date. The result of this confusion is people tend too see these two alternatives as binary and mutually-exclusive choices and try to force-fit a project to one of these extremes’

Agile versus Waterfall

What is Waterfall?

True “Waterfall”, as a methodology, died a long time ago for most projects outside of some specialized areas like construction; yet people continue to make that comparison. The problem is that the word “Waterfall” is used very loosely and indiscriminately. In many cases, when people use the word “Waterfall”, they’re not using it to refer to the specific “Waterfall” methodology that was originally defined by Winston Royce in the 1970’s, they’re using it loosely to refer to a general style of project management that emphasizes some level of planning, predictability, and control over agility.

Here’s an example – iterative methodologies such as the Rational Unified Process (RUP) became very popular in the 1990’s and early 2000’s and many people would consider that to be “Waterfall” just because they are somewhat plan-driven, but they don’t really fit the full definition of “Waterfall” at all.

What Is Agile?

The word “Agile is also used very loosely. When most people say the word “Agile”, they really mean “Scrum”. When they make the comparison between “Agile” and “Waterfall”, it sounds like both “Agile” and “Waterfall are individual, discrete methodologies and that is not the case.

Don’t get me wrong – I think Agile has huge benefits. I just want people to objectively understand the benefits of Agile versus Waterfall and the sloppy use of terminology to compare the two is often misleading and confusing.

An Example of Sloppy Terminology

Here is an example I’ve taken from a real world source that is considered fairly credible to illustrate what I mean by sloppy use of technology when people talk about “Waterfall”:

Blue Line

From the 2011 Chaos Report: “Agile Succeeds three times more often than Waterfall” The report goes so far as to say, “The agile process is the universal remedy for software development project failure.”

What do they mean by “Waterfall”? (Are they talking about a specific methodology – like the Waterfall that was defined by Winston Royce in the 1970’s or are they talking about a broader range of plan-driven methodologies?

How did they define how “success” was measured?

How can anyone possibly say that “The agile process is the universal remedy for software development project failure”?)

Blue Line

Saying that “Agile is better than Waterfall” is like saying “A car is better than a boat”. They both have advantages and disadvantages depending on the environment that you’re in. When people use the word “Waterfall” like this, I’m tempted to ask, “Which aspect of ‘Waterfall’ are you referring to?”

  • Are you referring to the phase gate approach where a project is broken up into phases and there is a phase gate for approval to transition between phases? I don’t think that approach has been widely practiced for years for software development projects and even Winston Royce himself had reservations about it
  • Are you referring to an over-reliance on documentation? That is a more legitimate comparison because Winston Royce did come out very strongly in support of a lot of documentation, but that shouldn’t imply that an Agile project has no documentation whatsoever.
  • Are you referring to the tendency to plan an entire project upfront before starting the project and then manage changes to the project requirements through change control? That also might be a legitimate comparison, but it also shouldn’t be meant to imply that an Agile project shouldn’t do any planning upfront.
  • Are you referring to the practice of attempting to complete all of the project requirements all at once? Long before Agile became well-known, iterative approaches like the Rational Unified Process (RUP) provided a way to solve that problem and break up a project into iterations.

A More Meaningful Comparison

A more meaningful and more objective comparison is between an “adaptive” approach to project management and a “plan-driven” approach to project management.

  • “Plan-driven project management” is a style of project management that is applied to projects where the requirements and a detailed plan for completing the project can be defined to some extent prior to implementing the project.
  • In contrast, an “adaptive” style of project management starts the implementation of a project with a less well-defined plan of how the project will be implemented and the requirements and plan for the project are expected to evolve as the project progresses.

No project is ever totally plan-driven or totally adaptive; you won’t find many projects that start out with an absolutely rigid plan that is not expected to change at all, and you won’t find many projects that have no plan whatsoever of how the project will be done. There is a broad range of alternative approaches between those two extremes as shown in the diagram below:

Increasing Agility and Adaptivity

It is a matter of choosing the right level of upfront planning to be applied to a project based on the level of uncertainty and other factors in the project and it takes some skill to do that.

How Do You Choose the Right Approach?

There is nothing inherently wrong with either of these approaches (adaptive or plan-driven). They both have advantages and disadvantages for a given project and they should be seen more as complementary approaches rather than competitive. Instead, many people see “Agile” and “Waterfall” as binary and mutually-exclusive choices and that causes people to try to force-fit a project to one of those extremes rather than selecting and tailoring the approach to fit the project. Here’s an article with more detail on that:

How Do You Choose the Right Approach to Fit a Project?

It takes much more skill to fit a methodology (or combination of methodologies) to a project – you have to know a broader range of methodologies and you have to understand the principles behind the methodologies at a deeper level to know how to tailor the methodology and blend different methodologies together to fit a given situation. Some people are primarily skilled in one particular methodology and tend to implement that methodology mechanically “by the book”. It’s like being a carpenter and the only tool in your tool bag is a hammer.

Overall Summary

The impact of misusing the word “Waterfall” is significant:

  • It causes people to “throw out the baby with the bath water”. By misusing the word “Waterfall” and categorizing all plan-driven approaches as “Waterfall”, people tend to dismiss any form of plan-driven approach and to regard any kind of upfront planning as inconsistent with an Agile project.
  • It has caused a lot of polarization between the traditional project management community and the agile community. The perception is that project managers are associated with the Waterfall approach and, as a result, project management skills are not needed because the Waterfall approach is an out-of-date approach for many projects.

The true Waterfall approach has been obsolete for many projects for a long time (the exception being some selected industries like construction where it is still very useful and relevant). So, I don’t think comparing Agile to Waterfall is very meaningful any more, but its very difficult to get people to stop thinking in those terms because it has been so prevalent for such a long time.

The difference between a highly adaptive project and a highly plan-driven project is how much of that planning is done upfront in the project rather than being deferred till later. It’s not a black-and-white decision to have a totally plan-driven approach or a totally adaptive approach and it requires some skill and judgment to determine what level of upfront planning makes sense in a given project. When people present this decision as “Agile versus Waterfall” it distorts what the real decision is and makes it look like a binary, all-or-nothing choice and that’s not the case.

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.

Managing Conflict in Agile Teams – Is Conflict Normal?

I recently saw a LinkedIn post from someone who was requesting advice on managing conflict in Agile teams. One response was to remove the people who are causing the conflict from the team.

  • That may not be an appropriate solution – some level of conflict is necessary and healthy in a high performance team.
  • A team where everyone always agrees with everyone else on the team would probably not be a very high performance team.
  • In this particular situation, the conflict was occurring over estimation and that’s an area where you certainly want to bring out opposing views and attempt to resolve them rather than suppress them.
Managing Conflict in Agile Teams

How Do You Manage Conflict in Agile Teams?

The right way to manage conflict on an Agile team is not to try to stifle conflict but to accept some values among the team to listen to the views of others and treat them with respect and consideration if you disagree with them.

  • Each person on the team also needs to put their own ego and emotions aside and instead of focusing on who’s right and wrong, focus on working collaboratively with others towards what is in the best interest of the team and the business.
  • Some times people become argumentative and pursue an argument just to have the last word or try to prove that they’re right and others are wrong – that behavior can be very counter-productive.
  • Having a clearly-defined set of values that everyone on the team agrees to is a good way to minimize that kind of behavior.

Tuckman’s Stages of Group Development

I suggest that anyone who wants to learn more about team dynamics do some reading on “Tuckman’s Stages of Group Development”. It’s an excellent model for understanding the stages teams go through in the journey to becoming a high performance team. Here’s a brief summary – Tuckman’s model consists of four stages:

1. Forming

The first stage is called “Forming”. In this stage, “Individual behavior is driven by a desire to be accepted by the others, and avoid controversy or conflict. Serious issues and feelings are avoided, and people focus on being busy with routines, such as team organization, who does what, when to meet, etc. But individuals are also gathering information and impressions – about each other, and about the scope of the task and how to approach it. This is a comfortable stage to be in, but the avoidance of conflict and threat means that not much actually gets done.”

2. Storming

The next stage is called “Storming”. During this stage, “Individuals in the group can only remain nice to each other for so long, as important issues start to be addressed.

  • Some people’s patience will break early, and minor confrontations will arise that are quickly dealt with or glossed over.

  • These may relate to the work of the group itself, or to roles and responsibilities within the group.

  • Some will observe that it’s good to be getting into the real issues, whilst others will wish to remain in the comfort and security of stage 1.

  • Depending on the culture of the organization and individuals, the conflict will be more or less suppressed, but it’ll be there, under the surface.

  • To deal with the conflict, individuals may feel they are winning or losing battles, and will look for structural clarity and rules to prevent the conflict persisting.”

3. Norming

As Stage 2 evolves, the “rules of engagement” for the group become established, and the scope of the group’s tasks or responsibilities are clear and agreed.

  • Having had their arguments, they now understand each other better, and can appreciate each other’s skills and experience. Individuals listen to each other, appreciate and support each other, and are prepared to change pre-conceived views: they feel they’re part of a cohesive, effective group.

  • However, individuals have had to work hard to attain this stage, and may resist any pressure to change – especially from the outside – for fear that the group will break up, or revert to a storm.”

4. Performing

The final stage is called “Performing”. “Not all groups reach this stage, characterized by a state of interdependence and flexibility.

  • Everyone knows each other well enough to be able to work together, and trusts each other enough to allow independent activity. Roles and responsibilities change according to need in an almost seamless way.

  • Group identity, loyalty and morale are all high, and everyone is equally task-orientated and people-orientated. This high degree of comfort means that all the energy of the group can be directed towards the task(s) in hand.”

There are several important things to recognize about this model:

  • You can’t just jump past the “Storming” stage and go right to the “Performing” stage unless the people on the team have a lot of maturity on working in other teams. You have to progress through these stages to some extent to make progress. For that reason, conflict should be viewed as a sign of progress that you’ve moved past the “forming” stage.
  • You don’t necessarily always proceed through these stages in a strict sequential order…sometimes a team will regress and fall back to an earlier stage and start over from that point and you might go back-and-forth like that over a period of time.
  • The natural progression for a team that is in conflict is to move to the “norming” stage and you do that by adopting rules and values of how the team interacts with each other. Those rules and values are like “training wheels on a bike”. After teams have reached a point of maturity, those rules become just a natural part of people’s behavior and the team reaches the “performing” stage which is similar to riding a bike without the “training wheels”.

Source: “Stages of Group Development”

Overall Summary

One of the key points in this model is the conflict is a normal and necessary stage of progression on the journey to becoming a high-performance team. For that reason, you shouldn’t try to stifle conflict – the best approach is to manage it by setting values so that it doesn’t become destructive.

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.