Most of the studies that discuss failed software development projects find misunderstood requirements and inadequate change management among the leading causes of failure. These failures can’t be adequately addressed just through more rigorous documentation or web based tools. Generating shared understanding is a social act – therefore, one of the elements of improving requirements is through improving the related social interactions or conversations.

But how do we go about improving conversations? Where are the engineering practices or process improvement techniques we can apply to consistently achieve improved performance? John Searles has written several books that break down conversations into a series of speech acts and even has a notation for describing a conversation. I found Searles work on Speech Acts to be very interesting. There is value in classification and understanding of patterns in conversations. But I am not sure this translates to an easily digestible approach. I also believe that conversations have flows and states, but I am also not sure that a process flow is an effective way to represent a conversation.

I can’t break the process of the flows and states a cake baking in the oven goes through down to detailed steps. I can tell you when it might be appropriate to bake a cake, when we are ready to put the cake in the oven, what happens during the baking process, and I can tell you how to check to see if a cake is done. So the approach I am advocating here is to be able to know when a specific conversation is called for, what it takes to be prepared for a conversation, how to approach the conversation, and how to check and see if the conversation has been performed.

Conversations for Shared Understanding

A conversation for shared understanding often involves one person on the project learning something new from someone else on the project. Conversations for shared understanding are important between different functional groups and when defining expected outcomes. For example, requirements documents define what needs to be done on a project. The requirements documents by themselves are typically not adequate. The gap in understanding leaves room for the development organization to build something that is not optimal either from a development or a requirement standpoint.

I love college football. One Saturday when I first got married, I was watching a game on TV. I planned to head over to my friend Steve’s house later in the day to watch the afternoon game. My wife called down from upstairs to ask me to take out the trash. I agreed to do it, thinking I could grab it out of the kitchen on the way out the door after the current game before I went over to Steve’s house. Her context was very different from mine. She meant, right now – all the trash in every room of the house – and clean the bathroom’s while you are at it. So, while I agreed to her requirements, we didn’t have a shared understanding of the request.

When is a Conversation for Shared Understanding called for?

Anytime a lack of shared understanding slows down the project or creates rework or other waste. A lack of shared understanding happens all the time in projects – particularly between functional groups and early in a project. So a conversation for shared understanding is important early in a project. Typically, these early conversations should be around the overall context and objectives of the project. A conversation for shared understanding is also called for with each specific feature or request. On software development projects it is important everyone involved in delivering, verifying, or accepting a feature or project deliverable has a shared understanding. Conversations for shared understanding should be at the outcome and context level. They are not intended for the technical implementation details to be explained to business stakeholders. The point is to establish context and understanding of the outcomes necessary to optimize the performance of the project performers.

What does it take to be prepared for a Conversation for Shared Understanding?

The mood and perspective of the participants in the conversation will impact the ability to successfully perform these conversations. So each participant must have an intention to have a conversation that results in a shared understanding. They should be willing to put in the effort to review or understand any artifacts produced to seed the understanding. They must bring a belief that the other person’s context matters. Additionally, participants need to put some thought into the boundaries of the conversation. The performer will want to think about what they need to understand to be most effective in delivering this request. The requestor will want to consider what parts of the context, what outcomes, and what language is particularly important to ensure they get what they intended to ask for.

How do we approach a Conversation for Shared Understanding?

1. The participants present their expectations and boundaries for the conversation.
2. Each participant explains their understanding of the context, targeted outcomes, and significant language. The other participant(s) will note where their understanding varies.
3. The discrepancies should be discussed, evaluated and resolved. Sometimes, the details of one participant will not be important. Sometimes, more specific discussion is necessary to gain clarity.
4. The participants will agree when they have a shared understanding.

How can we check to see if the Conversation for Shared Understanding has been successful?

At the end of the conversation the participants should be able to present an understanding of context and outcomes in common language. As soon as either participant identifies a gap in understanding they should revisit the conversation. Over time, the participants establish a common background that reduces the effort required to establish a shared understanding.

Today, when my wife asks me to take out the trash I understand what she wants. We also have identified when it may be important to have a conversation for shared understanding. For example, when she sends me to the store for milk I ask her to take a minute and think about what else I should get while I am there. My experience is that she has a lot of background information that I am not aware of. If I go to get milk and don’t get the eggs and butter she needs I will be heading back to the store. Taking the time to have conversations for shared understanding will almost always accelerate the effective pace of the project.

Knowledge based projects, like software development,  are performed by people.  So the way people learn, collaborate and interact is more impactful in knowledge based projects than in traditional projects like building a bridge or a satellite. If Agile software development and Project Management 2.0 have introduced anything new, it is an explicit focus on the social aspects of performing projects. Traditionally project management methods focused explicitly on the processes, tools and techniques of projects.

The traditional tools and processes are still important to the success of projects. We still need to clearly define scope, coordinate project resources, and manage commitments and acceptance of work. But these are social endeavors – and they can’t be accomplished with tools and processes alone. They require an intentional focus on the social aspects of the project. The shift toward the social focus is reflected in the Agile Manifesto’s first value, “Focus on individuals and interactions over processes and tools”. This shift in explicit focus is not an abandoning of processes and tools – rather an intentional focus on achieving these purposes to include people and interactions.

Project Conversations

How do we manage these social aspects? It is through conversation. Conversations are the use of language to exchange thoughts, ideas, or information. Understanding, Coordination, and Commitment within the team arise through conversations. John Searles wrote about how conversations can be defined with clear outcomes and broken into specific series of acts. Gordon Pask wrote in Conversation Theory about how understanding arises based on our interpretation of another person’s behavior.

Using these approaches we can construct ways to improve project performance through improving conversations. But, this isn’t a touchy- feely effort. For each specific conversation there is a specific set of outcomes and a specific set of “speech acts”. Intentionally deciding what conversations need to occur, when they need to occur, and what they look like when they have been completed will  improve the performance of interactions on Agile teams. Over the next week I will be discussing various conversations around understanding, committing, and coordinating. I will present a starting point you can use within your teams to have the meta-conversation to improve these conversations. Then I will build on each of these conversations at each order of scaling (small team, multi-team, program, enterprise).

You may already know that Mike Cottmeyer and I signed a contract to produce a book that describes situation specific approaches to scaling Agile in the Enterprise. This book is based on the work Mike and I have done over the last 10 years or so in helping organizations improve their ability to deliver value to their customers. While we have done the customer engagements separately, we think about this in a similar way and have been able to consistently deliver results to our clients.

Mike and I need to write about 157,000 words over the next 9 months to produce the content for the book. We will be blogging most of the ideas as we write the book and really look forward to your comments and feedback on our approach. Learning to tell the story so it resonates is really important to achieving our goal of writing a book that is very valuable to managers in organizations who are facing the Scaling Agile challenge.

Common Capability Model

A Capability is “an ability or capacity the organization relies on for a specific purpose or outcome”. We focus on capabilities because we are initially interested in What and Why, not on How. Getting caught up in How without clarity on What and Why is common in methodology debates. We Call this the “How Trap”. Using a capability analysis approach we have been able to get people out of what we call the “How Trap” and get them thinking about purposes and outcomes.

As a core part of communicating how managers can develop situation specific strategies for scaling Agile, we are building out a common capability model. Why not use an existing model? Well, we are working from the understanding that there is no single model that is outcome/purpose focused that can be used to build out the scaling. We need to build that base – not by recreating it from scratch but by building on top of traditional models that have worked at the enterprise level, like CMMI and PMI, as well as Agile approaches that have worked at the team level like Open RUP, Scrum, and XP.

As I introduce this capability model, I will start from a Scrum/XP perspective even though those methods are based on practices and not Capabilities. For example, iterations in Scrum and short releases in XP are about Limiting Work in Progress. So is incremental development in Open RUP. I will introduce the Big Agile Capability Model in terms of  Agile practices. I will show how they are complementary to the traditional models and how this outcome-based understanding helps us develop a situation specific approach to scale. Finally, I will talk about common dysfunctions in organizations that limit effectiveness.

Capability Analysis

I have been working on this consolidated capability model for a few years. At a number of clients, I have used an approach based on a consolidation of CMMI, OPM3, XP, and Scrum. More recently I have included Kanban and the Open RUP in the model. At higher levels of scaling I rely on some other capability models like the Process Classification Framework, ITIL, Pragmatic Product Management, and the Business Architecture work I did at Microsoft. The goal is always to find a way to talk about outcomes and purposes before we talk about implementation.

The trick is in translating these jargon specific detailed models into something straight-forward that facilitates the development of situation specific strategies for scaling Agile. This is a challenge that Mike and I are working through now. Before everyone pukes on the idea of basing our approach on a capability based model, I want to cover a couple of important things.

First, I am not a big fan of staged models. I get the concept of CMMI’s levels of maturity – it is important to establish maturity in the lower level processes to gain benefit from the higher level processes. But I believe an organization can make progress on higher-level processes while they don’t have all the lower level processes in place. The capabilities are interdependent and so can’t be addressed in a linear manner.

In OPM3, the model is not staged. You pick an area of focus, such as project cost or program risk, and the model will walk your though capabilities related to that strategic area. Like OPM3, our model is not staged or prescriptive in nature. We talk about these in an order, but in reality, the team needs to be focused on improving capabilities based what makes the most sense for a specific situation.

Second, I don’t like the idea that Product Development, Project Management, and Software Engineering (http://www.dennisstevens.com/2009/03/12/project-management-product-management-and-agile/) are evaluated separately and independently of other the rest of the organization. They are too tightly integrated in real life once you get past the small team to be treated separately. At the end of the day, there is no point in getting better at any of these areas if it doesn’t result in an improvement in delivery of value to the customer.

Finally, one problem I have with formal capability models in adoption is that these models come off as overly complicated, prescriptive, and aren’t typically treated as situation specific. Typical models drive the conversation, “What do I have to do to pass an audit”. We want to change the conversations in the business to, “What is the next most important thing we can focus on to improve our ability to deliver value to my customers”.

The Big Agile Capability Model

The model that Mike and I are working on starts with Small Team Agile. We build this out to Horizontal Scaling, where you have multiple teams doing Agile development on distinct outputs. Then we build out to First Order Scaling, where multiple Agile teams are working together on a single product. At Second Order Scaling, multiple Agile teams are working on multiple products. At Third Order Scaling, we are working to leverage the ability to rapidly deliver working software across the Enterprise. Wrapped around this is a set of common capabilities that apply to every level of scaling. Over the next several days I am going to describe the capability model we have derived from our experience and research. As with everything else in the book, this model is subject to change.

I am going to describe the Small Team agile capabilities over the next few days. Over the next few weeks, I will go into the capabilities associated with Horizontal scaling, then First Order, Second Order, and Third Order scaling.

As we go through our approach, please share your thoughts – good and bad – with the approach and how it is being communicated. We need to make sure this is valuable contribution to the body of works hoping to improve our ability to deliver high quality products that meet the needs of customer.

Vasco Duarte over at Software Development Today has launched a grenade at the PMI Agile organization with his post PMI vs Agile, what is different, and why you should care.  He was responding to Lynda Bourne’s post Agile: The Great Debate. I started writing a comment that became really long so I decided to put this up as a blog post.

First, I must admit to having an advantage over Vasco in that I know Lynda Bourne. She is a talented and smart project manager who focuses on issues of engaging people in the right way. People in the Agile world would appreciate her sense of humor, empathy, and focus on treating people the right way. I don’t know Vasco. I like what he says on his blog for the most part, I see his tweets and comments on Twitter, and I think he is an intelligent experienced guy with a valuable point of view.

This conversation fascinates me for a number of reasons. First, one of the tenets of Agile is to value people and interactions over processes and tools. This manifests itself in respect for people and learning. One of the things I teach in my project conversation work is the importance of holding the other person as valid – believing what they have to say matters. Yet in this Agile vs PMI conversation there is a lot of not holding the other person in a very positive light. Another is seeking first to understand, the common approach is to point out what is wrong with the other persons world.

In her post, Lynda points out that there are three areas for discussion between PMI and Agile.

1. How do Project Management practices differ when interacting with Agile development vs. Waterfall development?
2. Can traditional Project Management learn from Agile?
3. What triggers choices between operational maintenance, development and projects and waterfall vs agile techniques.

I think these are good points for traditional Project Managers to understand as they make decisions about how to support a project with an Agile software component.

Vasco took offense about two points Lynda made in the first question regarding a PM moving to Agile from Waterfall. Remember as you read this that she is writing on PMI’s website to PMP’s.

• The need for robust change management and configuration management to track the evolution of the Agile project
• The critical importance of developing the correct strategy and architecture at the beginning of the Agile project

Vasco says these points reflect a lack of understanding at PMI regarding Agile. He claims her explanation to PMP’s that Agile projects have a strong dependency on change management and configuration management indicates she has no understanding of Agile. However, her reference to change management is in the same sentence as one to configuration management. She is absolutely referring to code. Since many PMI managers aren’t software development manager’s they likely don’t understand the critical nature a robust CI/CM infrastructure. In fact, many “agile” projects fail to implement these and this leads to project disasters. I feel her point is completely valid and Vasco’s retort is not helpful.

Vasco then says she is asking for BUFD. She didn’t say you need a Big Up Front Design. She said you need an Architecture and a strategy for delivery. Even the link Vasco refers us to agrees with Lynda. The first slide asks, “Architecture is a heavy-weight activity, and the magic of Agile makes it unnecessary to bother with up-front design, right?” Their response is, “False.” The presenters point out that this is a common misconception even among Agilists. I believe that Vasco’s retort reflects a bias against bad PM he has faced and does not reflect the validity of Lynda’s post.

Agile (Vasco refers specifically to Scrum) is about Software Development. In most organizations, software development is about 25% of the solution. People, processes, and management practices have to be addressed as well. And not just within the development and delivery of software, but across the entire organization. Project Management deals with this bigger world. The big opportunity is to learn from Agile how to align with and improve delivery outside of software and how to support Agile so the development team can deliver value to the organization with a minimal amount of friction.

I am not suggesting that PMI and all PMP’s have a clear understanding of Agile and how to implement it. I agree that there is a lot of discussion that needs to be held to make the two perspectives meet. I do think it is important that the perspectives meet. PMI is reaching out to the Agile community. They are making an attempt to understand and be understood. There is also a real need for us to bring these areas together in a way that drives value through our businesses.

Last week I became an OPM3® Certified Consultant. After spending almost three years as the Deputy Project Manager with the volunteer team developing OPM3 Second Edition, I spent a week taking the OPM3 Certified Consultant course and passed the final exam. I have received a lot of questions about what that means and whether there is any value in it. There are about 100 OPM3 Certified Consultants in the world. I want to talk about OPM3, project management standards, getting organizationally mature, and what being an OPM3 Certified Consultant means. This might not sound exciting, but hang with me. There are very few organizations that won’t benefit from getting better at implementing strategy.

What is OPM3?

OPM3 is a standard that was first published in December of 2003 by the Project Management Institute. OPM3 stands for Organizational Project Management Maturity Model. Per PMI, “Organizational project management is the systematic management of projects, programs, and portfolios in alignment with the achievement of strategic goals. The concept of organizational project management is based on the idea that there is a correlation between an organization’s capabilities in Project Management, Program Management, and Portfolio Management, and the organizations effectiveness in implementing strategy.”

[There is some conflict in the terms process and capability. I will use the term capability consistently through my discussion. A capability describes “what you do and why you do it”. A process describes “how”. PMI doesn’t describe “how” in their standards even though they call them processes.]

To put this simply, organization’s have to implement changes in their structure, processes, management practices, and/or technology to implement a strategy. This is difficult but there are some capabilities that have been show to support them in consistently implementing these changes.  These capabilities can be categorized into effectively and efficiently executing projects, the coordination of multiple projects to optimize resource utilization and project performance, and deciding which projects are the best ones for the organization to invest in based on the organizations strategy. These are Project Management, Program Management, and Portfolio Management respectively. OPM3 uses the capabilities identified in PMI’s Project Management Body of Knowledge-4^th Edition, The Standard for Program Management-Second Edition, and The Standard for Portfolio Management-Second Edition. More on standards in a minute.

OPM3 wraps a continuous process improvement approach around these capabilities. For example, when implementing a project you probably want to manage the scope of the project. Within most organizations -most of the time, that means you have to gather requirements, define the scope of the project, and create a work plan when planning a project. There are a lot of different ways to do this. It may make sense on some projects to do this once at the start of the project and on other projects, you should do it iteratively and in progressively more detail. What organizations that are good at executing strategy do is they define how they are going to manage scope. Then they pay attention to how well this works continue to improve their method over time. This is organizationally mature.  OPM3 breaks the capabilities down into Standardize, Measure, Control, and Improve.

OPM3 also includes a set of Organizational Enablers. These are the capabilities that must exist in an organization to support the implementation and ongoing existence of Project Management capabilities. These include things like project management training, project management sponsorship, and other structural, cultural, technological and human resource practices.

You can pick up a copy of the OPM3 standard from PMI’s website for about $100. This standard describes the approach in detail, lists all the capabilities, and includes a nice Self Assessment tool in the appendix.

Project Management Standards

The Project Management Body of Knowledge (PMBoK) is a catalog of capabilities (called “processes” by PMI)  related to the management of projects. When the first OPM3 standard was published, PMI had not published standards for Portfolio Management or Program Management.  These first versions came out in 2006 and have been significantly updated with the simultaneous release of new Editions of the standards for Project, Program, Portfolio, and OPM3 in December of 2008.

The new standards provide a comprehensive catalogue of the capabilities that cover Project, Program, and Portfolio Management. These standards show the capabilities that will work in most organizations most of the time. They are based on years of research and the input of thousands of volunteers. They give examples of existing practices within the capabilities.  Despite what some critics claim, they don’t tell you “how” to implement those capabilities, just “what” you should be thinking about. They also don’t tell you to do all the capabilities whether they make sense for you or not, follow a high ceremony waterfall process, or make the purpose of the organization about project management.

Getting Mature

Maturity is an interesting concept. It has a lot of meanings. Mature can be a show you wouldn’t like your kids to watch, a bill of exchange that is due, or a ripe or fully aged piece of fruit. The definition of maturity I am using here is fully developed. What makes organizational project management maturity an interesting concept in business is that fully developed is different in almost every business. It can also change over time within an organization as the needs for project management change.  The key to organizational project management maturity is not to try to implement every capability with a robust set of process maturity. But to implement the capabilities that are right for helping a specific organization implement their specific strategy. This includes implementing an appropriate level of continuous improvement and only the necessary organizational enablers.

I have written about this focused approach to improving project management performance here and here. Invest when it improves the organizations ability to drive value. The goal is not to get better at project management, it is to get better at profitably delivering value to your customers. Project Management maturity efforts should be tied directly to business results.

 OPM3 Certified Consultant

An OPM3 Certified Consultant isn’t just someone who understands the OPM3 standard. Just to get into the course OPM3 Certified Consultant course you must demonstrate comprehensive knowledge of the OPM3 standard through completion of a SAM assessment or an OPM3 fundamentals course. An OPM3 Certified Consultant has demonstrated significant program or project management experience, since a PMP or PgMP is an eligibility requirement. An OPM3 Certified Consultant also has significant assessing and/or consulting experience.

Once in the course, the consultant is trained on the OPM3 assessment methodology and tool set, and the improvement methodology and tool set. This is during an intense four day training course. The consultant must successfully complete an exam.  The handbook that walks you through this process can be found at the PMI website.

The Value of OPM3 Certified Consultants

Most businesses can benefit from getting better at executing their strategy. Improving Organizational Project Management Maturity is a method of improving the organization ability to execute their strategy. OPM3 provides a systematic approach to identify and implement Organizational Project Management improvements appropriate to each business. Project Management Maturity is a tricky thing – it requires insight and experience to focus improvements in project management so it improves the organizations ability to deliver value to its customers. An OPM3 Certified Consultant has an assessment and improvement methodology, a robust tool set, and has demonstrated the experience with identifying and implementing improvements based on PMI’s standards.

For me, the value of the certification includes the assessment and improvement methodology training I received, the time I have spent with other experienced Organization Project leaders, access to the assessment and improvement tools provided by PMI, and some branding. I can combine this with my experience in software development and IT Operations excellence and cost optimization to rapidly deliver value to organizations. For organizations looking for a way to rapidly improve the performance of thier projects, an OPM3 certified consultant with proven experience and expertise in your domain is a good option. Guided by a proven systematic approach, they can perform an assessment and create an improvement roadmap and tie the improvements to your business results. 

I have been having a lot of discussions lately with Mike Cottmeyer over at www.leadingagile.com about scaling Agile to the Enterprise. Today he has a great post, Teams are the Building Blocks of Agile. Mike is exactly right. In fact, teams are the building blocks of organizations. And promises are the glue between the teams. In realms of uncertainty such as knowledge work and software development, Donald Sull would say to focus on Promises over Process.

Managing the promises in an organization is called Promise-based Management. The primary idea in Promise-based management is that work moves through organizations based on a network of promises. And that the better the promising is, the faster the work will move. The whole business is a network of “if you can do this”, then “I can do this” promises. When this network works well, the business improves its ability to profitably create value for the customer. We can improve the performance of the network by improving the reliability of the promises made between teams in the organization.

If you read Mike’s post from a certain perspective, it sounds like Mike is saying the purpose of the organization is to make life easier for the developer’s. That isn’t what he is saying, though.  He is saying that for an Agile team to keep its promise, you have to set the Agile team up to be successful by providing the appropriate context and coordination.

The promise the agile development team makes is to rapidly produce high quality software for use by the business. This is probably so the business can keep the promises it makes to its customers and stakeholders. The Agile development team is willing and able to make these promises when the <Product Owner>Product Manager, Project Manager, Designer, Subject Matter Expert, Business Stakeholder, Business Analyst</Product Owner> is able to set the table for the team by getting the proper context and coordination in place. Mike defines this part of the promise on his blog. This context and coordination effort is the “If you can do this” part of the promise that the Product Owner and Agile development team make.

Once we set the Agile development team up for success, they will be able to much more rapidly produce high quality software for use by the business. The new capability to keep this promise opens up a whole new set of promises we can make to the customer. Exploiting this new capability is not just about software development, it requires us understand impact on the other processes, promises and teams in the organization. Scaling Agile to the organization isn’t about software development. It is about fundamentally changing the promises we can make to our customers.

Check out “Promise-based Management: The Essence of Execution” in Harvard Business Review. Glen Alleman talks about the HBR article. Hal Macomber’s site is a rich resource practical application of promises and promising and making work ready. Clarke Ching’s site is an excellent source of the application of promised based management to software development.

There is a lot of interesting conversation going on within the project management, product management, and agile software development communities. There is contention between (and within) the different communities regarding the value and benefit from the other domains. Sometimes one community is vying to prove their domain is superior to the others. Other times, a community is casting blame for limitations in their ability to perform to another domain. Much of the conversation is based on a limited understanding of what the other domains actually do. They also fall into the trap of generalizing a specific unpleasant experience to encompass the intent of the other community.

I believe this debate is counterproductive. At the end of the day, everyone’s interest should be to improve their organization’s ability to profitably create value for the customer. Each of these areas has something critical to contribute to this goal – but the benefits are only realized when the communities work together. I want to define a few terms, identify the overlap, and then suggest why this discussion is not just an academic exercise, but it an important part of the maturing of each domain.

First, some definitions:

Project Management

Let’s start with Project Management. The Project Management Institute has the following definitions of project, project management and project manager.

Project: A temporary endeavor undertaken to create a uique product, service or result.

Project Management: The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.

Project Manager: Person assigned by the performing organization to achieve the project objectives.

Project Management is not meant to be an obstacle to getting work done. In fact, the project manager is responsible for ensuring the project is successful.

Product Management

The Product Development and Management Association define product, product management and product manager.

Product: A term used to describe all goods, services, and knowledge sold. Products are bundles of attributes (features, functions, benefits, and uses) and can be either tangible, as in the case of physical goods, or intangible, as in the case of those associated with service benefits, or can be a combination of the two.

Product Management: Ensuring over time that a product or service profitably meets the needs of customers by continually monitoring and modifying the elements of the marketing mix, including: the product and its features, the communications strategy, distribution channels and price.

Product Manager: The person assigned responsibility for overseeing all of the various activities that concern a particular product.

So the Product has an ongoing aspect to it that the Project doesn’t. The Product Manager decides what needs to be built and also how the organization will sell it and support it.

A product has a life that lasts beyond any individual project.  The ongoing thing over at PMI is called a Program. Here is the PMI definition for Program and Program Management. Interestingly, PMI doesn’t define Program Manager in the Program Management standard.

Program: A group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually, Programs may include elements of related work outside of the scope of the discrete projects in the program.

Program Management: The centralized coordinated management of a program to achieve the program’s strategic objectives.

Project Management Isn’t Product Management

So project management isn’t product management. Neither is Program Management, However, there are projects to execute in the modifying of the product, so project management processes matter in product management.  Here is a Venn diagram that describes the relationship.

If you aren’t good at making changes to your product or the capabilities in your organization that relate to your product, you won’t be a successful company. So project management isn’t product management, but there is overlap in practices and both are important to your organization. Great ideas with no execution aren’t valuable.

Agile Software Development

Finally, let’s go with the Agile Manifesto as a definition of Agile.

Manifest for Agile Software Development

• Individual and Interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Despite the perspective of many in the project management and product management communities, Agile is also not intended to be no planning, no documentation, irresponsible software development. According to http://agilemanifesto.org/history.html :

 “The Agile movement is not anti-methodology; in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.”

Agile is not Product Management

Agile is specifically about software development. In fact, the Agile Manifesto is short for the proper title of Manifesto for Agile Software Development. Agile is an approach to software development that includes practices and principles that can result in dramatically faster and higher quality (therefore less expensive) development of software. But the product is not just software. If the right features, communications strategy, distribution channels and price are established being faster, cheaper, and better at software development doesn’t matter. Product Management is critical to getting value from Agile Software Development.

Agile is not Project Management

 In very few cases is the product that is being sold to an organization’s customers just software. We’ve discussed the relationship of Project and Product Management above.  You need to be good at Project Managing all aspects of change to the product and the capabilities in the organization that support and are affected in any way by the sale, delivery, billing, and support of the product to the customer. Also, Agile isn’t concerned with Procurement – but procurement is important to the profitability of the company. And while iterations are a Risk Mitigation tool, Agile does not have a specific Risk Mitigation aspect to it.

Why this discussion matters

The following Venn diagram depicts the interdependency between these three domains.  Value is not delivered by any one of these domains. It is through an effective coordination between these domains that value is delivered to the customer. Value is identified, shaped, and then communicated to the customer by Product Management. Much value is created by the Agile development team itself. Value is created through aligning the other capabilities within the organization and often actually delivering the product to the customer through Project Management.

Let me quote Jim Highsmith from http://agilemanifesto.org/history.html again.

“In order to succeed in the new economy, to move aggressively into the era of e-business, e-commerce, and the web, companies have to rid themselves of their Dilbert manifestations of make-work and arcane policies. “

Most of the organization’s that I have been involved with that are failing to deliver software to the business or the business’ customers are failing to receive value because of deficiencies in one or all of the domains in this discussion. Often, the deficiencies are the result of conflict and lack of coordination with another domain. Becoming great at one area, while remaining poor in another, is not value to the customer, the business, or ultimately to the members of the organization. 

The discussion we need to be having is not about how each domain contributes to problems for the other domain.  This is an interdependent problem, not one that has its roots in any one domain. Bunkering down, defending incompatible practices, focusing on local optimization at the expense of the business is not going to work. We need to work together to answer this question. How do we align the product management and project management practices with the rapid, incremental delivery of working software to optimize benefits for our customers and profitability for our businesses?

This is a slightly updated presentation of a talk I gave at Atlanta’s Project Developer Days a few years ago. After attending a two day training session with Jeff Sutherland, I believe that this concept is relevant to the Agile and SCRUM Project Management conversation.  From my experience, improving the performance of the conversations on your projects greatly improves the performance of the project team. When we say we want to get better at communications, I believe we want to improve the quality and effectiveness of the project conversations. The project managers job in leading projects requires us to be good at recognizing what conversations need to take place, and facilitating them to a successful conclusion.

If you aren’t familiar with the story of The Blind Men and The Elephant it is about six blind men that go to study an elephant. When they come back, they all report on the elephant in different ways. They variously report they found a wall, a spear, a snake, a tree, a fan, and a length of rope. They argue to defend their perspective. The discrepancy lies in the fact that each studied a different part of the elephant. The poem and the related illustrations at the link above demonstrate the story very well. The story is a metaphor about how we see the world from our individual perspective and have a difficult time understanding the bigger picture.

Delivering software and technology is a lot like that elephant. Over my career, I have been the blind man trying to figure that elephant out. I wrote code for the first decade, then began to study what great code and then architecture looked like. I joined user groups and associations and studied the engineering practices around software development. I studied function point counting and became a member of IFPUG. In the mid 1990’s Senge and Ackoff seeded my Systems Thinking perspective. My work at Perot Systems shaped my Business Process Re-engineering perspective. My degree is in Organizational Psychology and Development and I have been fascinated with the role language, knowledge creation, and team dynamics play in this area. I first read “The Goal” and “Critical Chain” in 1998 and have studied and applied the TOC thinking processes and CCPM to project scheduling. I have been greatly influenced by Theory of Constraints thinking. I have been around Agile development for over 10 years. I have a bookshelf full of eXtreme Programming and Agile books. I am also very involved with the project management institute as well, earning my PMP in 1998 and I spent the last couple years as the Deputy Project Manager of the Organizational Project Management Maturity Model - OPM3®.   I earned my Lean Value Stream Mapping certification from the Lean Enterprise Institute in 1999.

In each of these cases I went into the community trying to learn what they had to offer and figuring out how to responsibly help companies profitably deliver technology. One of the interesting things I have consistently observed is the disdain these communities hold for most of the other communities.  I was at an Architecture conference in 1991 where the various OOAD people were actually yelling about the best way to identify objects for a system. The TOC and Agile people really dislike the PMI people. Even inside the Agile community, the Lean and Agile groups are at each other’s throats. Engineers discount the human elements and the softer side of team dynamics.  Everyone is arguing for the importance of their view of the elephant. High ceromony scoff at the lack of maturity of the low ceromony while the low ceromony ridicule the waste of heavy and useless process and artifacts.

The problem is that the answer is not one particular part of the elephant. No one is completely right. We need to optimize the entire elephant and turn it into a sleek and agile race-horse. The battles between whether the elephant is a tree or a fan or a snake are not productive. They obscure the path to improving the ways that we can responsibly and profitably deliver value to our customers.

I spent last week at a course with Jeff Sutherland, one of the creators of SCRUM. The SCRUM he talks about is different than what I have seen on many SCRUM teams or read in books. Jeff incorporates aspects from Theory of Constraints, and Lean, and Knowledge Management. He promotes the items in the Agile Manifesto but incorporates elements from everything he has learned and observed. Jeff is trying to build a “big-tent” approach that brings responsible practices together while increasing performance and developing hyper-productive teams.

I encourage each of us to recognize our myopia in understanding this elephant. Try to understand the basic principles behind each practice and idea. Let’s agree that the way organization’s identify, manage, create, and deliver technology to organizations and customers is insufficient and put a lot more energy into improving. Technology plays a very important role in our economy today. We can’t get good enough fast enough right now, and dogmatic wars are too costly. What can we be doing to rapidly cross-pollinate and greatly improve our ability to profitably deliver value to our customers?

I was reading a post by http://pauldrasmussen.blogspot.com/2009/02/project-management-so-what-is-project.html. While I don’t agree with everything in the post, I like the point made that project management is an art and a science.  There is art in being effective when you have a temporary role and you are responsible for the leadership of change within an organization

My Dad is a physicist. Back in the mid 1960’s he worked at NASA as a contractor. They hired physicists to do engineering work because there weren’t clearly understood engineering principles around building rocket ships to go to outer space. They were figuring these out as they went. So Rocket Science at the time was part science and part art. I think we are pretty good at engineering rocket ships now. In fact, you can get a degree in engineering that teaches the principles they were proving in the 1960’s.

Project Management is where rocket science was back in the 1960’s. Theoretically we can get complex organizational projects done. Some people have even done them well.  But many of them have not been successful and the practices are not fully proven. Project Management is a science and an art.  It took 20-30 years for rocket science to move from theory to science to engineering.  Where are we on the spectrum in project management for organizations today?