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 things are not totally compatible with each other; but that doesn’t mean that they are incompatible. It just requires some skill to blend them together in the right proportions to fit a given situation.

Here’s an example, I attended a presentation at an Agile Boston meeting last night by Michael Nir who talked about “The Agile PMO” which was based on his book of the same name. Michael indicated that a key potential role of an Agile PMO is to reduce waste in an organization and that goal is very consistent with Lean. An example of that could be under-utilization of people in the organization – under-utilization of resources or less than optimum utilization of resources could certainly be a major source of waste in an organization. There are a number of ways that could happen:

  • The utilization of shared, specialized resources such as DBA’s that are not dedicated to project teams is not well-planned and coordinated across teams.  As a result, project teams may be idle waiting for these specialized resources or the specialized resources might not be fully-utilized waiting for work from project teams.
  • Project portfolio management is not well-managed.   As a result, allocation of resources to project teams may not be not well-aligned with company business goals and priorities.
  • Individual projects are not well-managed and are allowed to go off track.   As a result, the allocation of resources to projects may not be optimized to maximize the business results for the company.
  • The development process is not well-defined, tools aren’t adequate to support the process, and/or project teams are not well-trained to execute the process.  As a result, the execution of the process is not consistent across teams and is not as efficient and effective as it could be.

It seems clear that all of these things could result in wasted resources and could be considered legitimate areas that a PMO could add value to but how far do you go with that?  Carried to an extreme, a focus on simply reducing waste could easily become dysfunctional.  Michael mentioned that waste in some organizations could be as high as 95%.  What would happen if you attempted to reduce waste to 0%?

  • First, it probably would not be successful because reducing waste to 0% is probably an unrealistic and impossible goal just because no business is totally predictable where everything is known in advance to enable perfect prioritization, planning, and scheduling of resources
  • Second, at some point, putting too much emphasis on reducing waste would tend to run counter to Agile because it would mean superimposing a level of control and standardization on projects that would likely be inconsistent with achieving the flexibility and adaptivity required by an Agile approach

So, what’s the right answer?  This is not necessarily an easy problem to solve and it will take some skill to figure out what is the right blend of (1) focusing on lean and reducing waste and (2) preserving the flexibility and adaptivity that is required by an Agile approach.  There clearly seems to be an optimum point between the two extremes of focusing on those two extremes individually and a PMO could probably perform a value-added role in helping an organization find that optimum point.

This is yet another example of the need for “systems thinking”.  Here’s a previous post I wrote on that subject:


People many times like to over-simplify what is really much more complex and reduce it to a simple, binary choice between two extremes, which it is not.  “Agile” versus “Waterfall” is one example of that and “Lean” versus “Agile” is yet another example.  On the surface, those approaches might appear to be in conflict with each other; and, if you pursued each approach individually and mechanically “by the book” without really understanding the principles behind it at a deeper level, they could easily be in conflict.  It takes some skill to take a systems thinking approach to understand these seemingly disparate approaches at a deeper level and see them as complementary to each other rather than competitive but it can be done.

Michael made a key point last night that it is a matter of focusing on value versus control and he’s absolutely right.  Better defining processes and tools, providing training to people, and doing some level of project portfolio management and resource planning of people is something that can definitely add value if it is done in the spirit of adding value; but it does take some skill to determine the optimum point beyond which is stops producing value and starts to become dysfunctional.

Making Agile Work for Your Business


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?” The answer seemed obvious to me but it really stimulated my thinking – one of the key things that differentiates an Agile approach from atraditional 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.

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:

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

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.

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

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.

Multi-Dimensional Project Management

I recently wrote a post on “Adaptive versus Plan-driven Project Management”. It occurred to me that this same framework would be useful to help people understand the migration that I believe is happening in the project management profession. Here’s how I see the migration to a new multi-Dimensional project management approach that is likely to take place in the future:

Project Management Transition

I don’t think that anyone today would disagree that “Project Management”, as we’ve known it, is heavily defined by plan-driven principles and practices as shown by the oval in the left-hand column of this diagram and there are many stereotypes that heavily associate “Project Management” with plan-driven practices. What I believe is likely to happen within the project management profession in the future is this:

  • At a team level, a large percentage of project management roles are likely to migrate towards a more adaptive approach over some period of time. That means that many of those project management roles might disappear and project managers who are only qualified to do plan-driven project management at a team level may have to move in one of two different directions:
    • Move up to assume a higher-level enterprise-level role managing larger, more complex projects
    • Develop more adaptive project management skills
  • Project Managers who are already managing larger, more complex projects and enterprise-level projects may be less impacted by this migration; however, even at that level, the demand for project managers who only know how to do plan-driven project management will likely decline significantly.
    • Some of these new roles may not even be recognizable as we know project management today and may not even have the title of “Project Manager” associated with them. For that reason, I think we need to shift our thinking about what “Project Management” is. Instead of thinking of it as a narrow vertical column that is dominated by plan-driven thinking, what I believe is needed is more of a broader, multi-dimensional view of project management that goes beyond just doing traditional, plan-driven project management functions and also embraces a more adaptive approach to project management.

      In my opinion, project managers of the future will need to take on a broader range of roles and must be able to operate in either a plan-driven role or a more adaptive project management role and should be able to select the appropriate blend of those two approaches to fit a given situation rather than force-fitting all projects to a plan-driven approach.

      It seems to me that the Project Management profession needs an image makeover to shift the image of how people think of what “Project Management” is to prepare people for this migration that I believe is likely to happen. I think that there are a lot of people in the project management profession who are in “denial” and seem to think that the way we’ve been doing project management will go on unchanged into the future. I hope this post has helped people more clearly see this migration trend.

Learn the Truth About “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. Learn the Truth About “Agile” versus “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.

An Example of Sloppy Terminology

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

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. For example,

  • If I were to set out to try to find a cure for cancer and I attempted to apply a highly plan-driven approach to that project, the results would probably be very dismal
  • Similarly, if I tried to use an agile approach for building a bridge across a river, the results would be equally dismal

Why does that happen? 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

I’ve created a free online training course that provides more information on this topic:

Learn the Truth About Agile versus Waterfall

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. Most often, what they’re talking about 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 an Agile development process such as Scrum. 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”.

Beyond that; however, there is a different kind of Agile coaching role at an enterprise-level that needs to be better-defined and differentiated from a normal team-level “Agile Coach” role. The enterprise-level role is someone who works at a more strategic level to integrate an Agile development process with a company’s business. That role is not well-defined at all and the difference between the team-level role and the enterprise-level role is also not clearly differentiated. It is assumed that someone who has “Agile Coach” on his/her resume can do all of that and I don’t believe that is necessarily correct.

What often happens in applying Agile at an enterprise level is that an “Agile Coach” attempts to plan and organize an enterprise-level agile transformation. However, that person is probably only trained in Agile from a team-level development process perspective and makes 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. I don’t believe that either of those assumptions is necessarily correct.

The problem is this – 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 and it is very easy to apply an Agile development process in that environment. It is much more difficult to apply an Agile development process in a company who is not in the primary business of developing products and is in some other kind of business where 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 whatever the critical success factors are for the business that they are in. 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 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 trying to force-fit the company to some kind of overall Agile approach.

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

I’ve developed some on-line training that should be helpful to people who want to understand this better:

  • Mastering Agile Project Management for Project Management – addresses this from a project management perspective to help project managers see Agile and traditional project management principles and practices as complementary rather than competitive and to learn how to blend the two together to fit any given situation.
  • Making Agile Work for Your Business for Executives – addresses this from a business management perspective and provides some essential principles and guidelines of how to successfully develop a well-integrated enterprise-level approach for any business.

Agile Lessons We Can Learn From Sports

I think there are a lot of lessons we can learn from sports – particularly about the importance of character, integrity, teamwork, and values.

There’s been a lot in the news lately in the US about the conduct of some sports celebrities (Ray Rice of the Baltimore Ravens and others). Some people have questioned why we should hold sports celebrities to a higher standard than other kinds of employment. For example, a normal company wouldn’t necessarily fire an employee for beating their kids or having a public altercation with their spouse; but that behavior isn’t acceptable in a sports celebrity. I think there’s a couple of good reasons for holding sports celebrities to a higher standard.

  1. The first reason is that they provide an important role model for kids and others to follow. I just saw a short story on TV about Deandre Jordan (the center for the LA Clippers) that is a great example of that – it showed him working with a bunch of 9-10 year old kids on a basketball team to teach them the importance of character, integrity, and teamwork in sports. That’s the kind of positive role models we need in sports – people who go beyond what’s expected to try to have a positive influence on people in the communities that they are part of. Kids and others in the community look up to people like that and we need more role models like that.
  2. The second reason is probably more directly relevant to Agile Project Management. One of the important factors that binds a high performance team is that they share a set of values and a sense of purpose that goes beyond just showing up for work, doing their jobs, and going home at the end of the day. Their jobs are an extension of the way they live their lives and there’s a real sense of purpose and values behind it. They are also really true to those values – it isn’t just something that they practice in public and put aside when it’s not publicly visible.
  3. If we lower our standards to the level that it’s OK for people (particularly prominent sports celebrities) just do their jobs as long as they don ‘t do anything outside of work that might be considered a crime, it seems to me that we’ve let our standards drop too far. I’m proud to be part of the Agile Project Management community and part of some very dedicated and principled people who hold ourselves to a higher standard.

Are Corporate Culture and Values Really Important?

Are corporate culture and values really important? The controversy that is currently brewing in the Boston area over the “Market Basket” grocery supermarket chain is directly related to the conflict between Agile and traditional project management. “Market Basket” is a chain of about 71 grocery supermarkets in New England that generates about $4 billion in annual revenues – it has been a family-run business founded and managed by the DeMoulas’ family for several generations.

(Source: http://en.wikipedia.org/wiki/DeMoulas%27_Market_Basket)

Arthur T. Demoulas is currently the CEO of the company and has been highly regarded by all company employees and customers for building a strong company culture based on the strong leadership and values. However, some other members of the Demoulas’ family who have an ownership interest in the company didn’t see it that way… They felt that Arthur T. wasn’t paying enough attention to the bottom-line and was putting too much emphasis on corporate culture and values including developing a clearly-defined brand image with very strong employee satisfaction and strong customer loyalty. So, they fired him as CEO and hundreds of employees who were intensely loyal to him promptly walked out of the company in protest. Customers have also started boycotting the stores in response to his firing.

The company has been paralyzed for the past few weeks in the midst of this controversy as deliveries by suppliers have almost stopped because there are no employees to accept deliveries and stock the shelves and customers have walked away. It appears now that Arthur T. is going to buy out the other shareholders in his family to gain a majority and controlling interest in the company. The Boston Globe magazine had several excellent articles on this on Sunday 8/24/2014 – here’s an excerpt of one of them:

“Under CEO Arthur T. Demoulas, Market Basket had a winning business model: He treated employees, managers, and customers as members of a common enterprise, from which everyone gained. Arthur T. rolled out a 4 percent discount on nearly all goods at the beginning of 2014, arguing his customers could use the money more than his fellow shareholders. He paid his employees and managers decent wages, and he treated them with respect. He made sure they understood the objectives, and then let them decide how to achieve them. The greed team that ousted Arthur T., by contrast, is running the company as if they’re take-it-or-leave-it martinets and everyone is losing.”

“At least one of the bidders who emerged to buy Market Basket was said to be offering more than Arthur T. was offering. They said they can squeeze more profits out of the company than when Arthur T. was CEO. They’re deluding themselves. Arthur T.’s business model worked precisely because he didn’t follow this route. Trying to squeeze out more profits will drive customers away, destroy employee loyalty, and increase worker turnover.”

“There’s abundant evidence that a company organized as a common enterprise does better over the long term than a company designed to maximize shareholder returns over the short term. Arthur T.’s business model wasn’t based on zero-sum thinking. He understood that giving everyone a stake in the business would generate gains for everyone, including the shareholders.”

“The reactions to Arthur T.’s ouster proves the point. Customers are staying away from Market Basket stores, even though its costing them, forcing them to buy more expensive food elsewhere. Striking employees are sacrificing paychecks and risk losing their jobs, but giving in means getting stuck with new CEO’s and a board that are likely to cut pay and raise prices. Local politicians have weighed in with some statements of support. This isn’t the age-old labor versus management conflict. It’s labor, management, customers, community, and fired CEO versus greedy directors – something rare in the annals of American business.

(Source: Reich, Robert, “Anatomy of a Meltdown”, Boston Globe, Globe Magazine, 8/24/2014, p 20)

What does this have to do with Agile Project Management? I believe that the conflict between a bottom-line, numbers orientation that focuses on results and a more systemic and holistic approach that focuses on people, culture, and values and other factors that drive results is also one of the key issues behind the conflict between traditional plan-driven project management and Agile.

In 2003 I published a book called “From Quality to Business Excellence – A Systems Approach to Management” which is directly related to this problem. The figure below is a diagram from that book:

Business Excellence Model

(Source: Cobb, Charles, “From Quality to Business Excellence, ASQ Quality Press, 2003)

The idea behind this is that many companies are very short-sighted and reactive – they focus primarily on bottom-line results and when the numbers in a given quarter don’t meet expectations, they try to take some kind of corrective action without really understanding the cause-and-effect relationships that drive those numbers. This can lead to erratic and unpredictable performance. Companies who take a more systemic approach and understand these relationships are able to be much more proactive by focusing on at a deeper level on the performance drivers behind the numbers rather than simply reacting to the end-results. That should result in more consistent, sustainable, and predictable performance.

This pendulum has swung back-and-forth – should a company focus only on bottom-line results or focus on the internal factors like customer loyalty and employee satisfaction that drive bottom line results? The Market Basket controversy here in the Boston area is a perfect example of that. In the 1980’s and 1990’s many leading companies and enlightened managers successfully developed this kind of softer leadership approach that Arthur T. Demoulas is noted for; however, over the years since then, increasing pressure to produce fast-paced, short-term results has caused many companies to lose sight of this concept. To some people, the focus on numbers and bottom-line results may seem incompatible with a focus on some of the softer issues like corporate culture and values; however, enlightened companies and managers are able to successfully develop what I call a “systems approach to management” to achieve both.

Traditional plan-driven project management is also very results-oriented and numbers-oriented with a focus on meeting planned costs and schedules and many people see that approach as incompatible with Agile that focuses heavily on a softer leadership approach, an emphasis on culture and values, and empowered, self-organizing teams. I don’t see those approaches as mutually exclusive and focusing on one of those extremes or the other is not likely to produce optimum results. I think it’s naïve to believe that you can focus on company culture and values and empowered employees alone and the bottom-line numbers will somehow come out right as a result; but its equally problematic to focus on bottom-line results only without an appreciation of the factors that drive those results. The right balance of these two approaches will vary from one situation to another but, in general, a focus on both is needed to some extent to achieve optimal results.

The Agile Product Owner Role

The Agile Product Owner role in Agile is not well understood and how it relates to a typical project management role. I’ve written a lot about “project management” and Agile projects – many people mistakenly assume that “project management” is not needed in an Agile project because there is no Project Manager at a team level. However, even though you may not see anyone with the title of “Project Manager”, the project management discipline is still needed. It’s just a different style of project management and the project management functions are distributed among several other roles rather than being performed by a dedicated Project Manager.

Product management” is another discipline that is equally important and is also often neglected. The role of a “Product Manager” is not well-understood – you typically find “product management” only in companies that market products for external sale such as Intuit Quicken or QuickBooks. You don’t typically see someone called a “Product Manager” associated with an internal IT application development project because the output of that kind of project might not be considered a real “product”. However, many of those applications are significant enough to be treated as a real “product”; and, although it may not justify a dedicated person with the title of “Product Manager”, some product management discipline is needed.

  • Sometimes a Business Analyst might take on some of those functions; however, a Business Analyst does not typically have the level of responsibility and decision-making authority of a true Product Manager.
  • A Project Manager might also take on some of those functions but many project managers are not trained to take on that role and many project managers may not have the decision-making authority to make the kind of business decisions that are needed. In a traditional development project, the Product Manager determines “what” will be built and the Project Manager typically determines the “how”.

Scrum has recognized the importance of this business direction and has created the “Product Owner” role to put more emphasis on providing that kind of discipline and business direction. The Product Owner in an Agile project actually takes on a number of functions that would normally be performed by both a “Project Manager” and a “Product Manager” in a traditional development project. That is actually a huge amount of responsibility that is not fully understood in many cases. When I took a Certified Scrum Product Owner (CSPO) course some years ago, it primarily focused on the mechanics of how the Scrum process works and what the Product Owner role is in that process. It was taken for granted that the students knew enough about both project management and product management to perform those functions in the context of an Agile/Scrum project.

In my experience, the Product Owner in an Agile project is a business person who has been thrust into that role and doesn’t necessarily understand all of the requirements and experience required by that role. The Product Management discipline and functions, in particular, typically are not well-understood because it has often been neglected in traditional development projects. Wikipedia.com defines “Product Management” as follows:

“The role may consist of product development and product marketing, which are different (yet complementary) efforts, with the objective of maximizing sales revenues, market share, and profit margins. The product manager is often responsible for analyzing market conditions and defining features or functions of a product. The role of product management spans many activities from strategic to tactical and varies based on the organizational structure of the company. Product management can be a function separate on its own, or a member of marketing or engineering.”

“While involved with the entire product lifecycle, the product management’s main focus is on driving new product development. According to the Product Development and Management Association (PDMA), superior and differentiated new products — ones that deliver unique benefits and superior value to the customer — are the number one driver of success and product profitability.”

In a company that develops IT applications for internal use, this same general discipline is needed but it is focused on maximizing the business value that the application provides for the company rather than maximizing the revenue from external sales of the product.

As I’ve mentioned in some of my other blog posts, Agile is forcing us to redefine what we think of as “project management” and this is another example of that. The “Product Owner” role is actually a combination of some “project management” and “product management” discipline. Many project managers seem to think of becoming a Scrum Master as a way of migrating their skills into an Agile project but that may not be the best use of a project manager’s skills. A project manager who has an Agile mindset and also has some strong business domain knowledge might be a very good candidate to migrate into the Product Owner role and that would probably be a better use of their skills than becoming a Scrum Master.

That may be a significant increase in responsibility for some project managers but it seems to be very consistent with my thinking about “The Next Generation of Project Management” where the project manager takes on a new emphasis of driving business value rather than simply managing the scope, costs, and schedules of a project.

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 what “project management” is. but there is a danger of broadening the definition of a “project” and “project management” so far that almost anything could be a “project” and that would make it meaningless. For example: Is an effort to provide ongoing maintenance and enhancements for a product a “process” or a “project”. I think it could be both because “projects” and “processes” are very inter-related. To eliminate potential confusion, I think we need clearly-defined and objective criteria for drawing a line between what is a “process” and what is a “project”.

I’ve summarized some distinctions below:

A “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".
A “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).
A “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.

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

Process ManagementProject Management
Process management is focused on managing a process such as a software development 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.
Project management is focused 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.
Process management has an emphasis 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).Project management has an emphasis 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.

In simple, terms, “process management” is focused on managing existing business processes as efficiently and effectively as possible – it’s associated with managing the current way the business operates. “Project management” is associated with managing some kind of change in the way a business operates effectively such as introducing a new product, implementing new processes, etc.