On February 11-13, 2001, a group of 17 people came together and created the Agile Manifesto. This launched a decade of dramatic change in the way software projects are delivered in many organizations. A decade later, on February 11-12, in the same resort in Utah, 33 people got together to discuss the Agile Manifesto and talk about what is next. There was a lot of  great discussion and a lot of agreement. What was interesting to me was that there was a lack of agreement on what the last bullet,

“Maximize Value Creation Across the Entire Process”

even means.

Working Code as Value

The first principle behind the Agile Manifesto is:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

To many in the software development community – including many of the attendees at the 10 Years Agile workshop, value means working, tested, deployed code. I agree that this is important, but this is not value. Working, tested, deployed code is captured in the first bullet:

“Demand Technical Excellence”

But does this deliver any value? Quality software is necessary but not sufficient for value delivery. Some in this community view quality software and software craftsmanship as the final purpose. There are some that feel that this was all that in the control of the members of the Agile community. I don’t share this perspective. Value not only has a broader meaning than this, but this limited perspective can actually be value destroying.

Organizational and Personal Values

When we were defining Value-based Development – it was marked up to be Values-based development by someone. Within the agile community, there is a metaphor of software development teams as pigs surrounded by chickens and seagulls. The pigs are committed to development the chickens are involved and the seagulls just fly in a crap all over everything.  The pigs are management and the seagulls are management.  This metaphor comes from the difficult organizational environments that many developers have worked in.  There are some in the community that consider value to be improving the conditions that people work in every day. This is captured in the second bullet:

“Promote Individual Change and Lead Organizational Change”

This is valuable, but does this deliver any value? Improving the environment that individuals work in is really important. Software development is a creative endeavor, it is critical to create an environment where people feel safe and motivated so they can do great creative work. Some in the community view this as the real motivation behind the Agile community. They feel that Agile software development is about what’s in the best interest of the developers. Organizational and Personal values are key – but they aren’t value. In fact, a singular focus on improving personal values can be value destroying.

Value as Customer Value

There is a strong movement emerging in the Agile community, or the post-agile community, that agile is about customer experience. Customer experience is critical to get people to use your product. Customer value is the difference between what a customer gets from a product, and what he or she has to give in order to get it. Customer value is really, really important. Google is my favorite search engine. They absolutely understand what customer value is. But they don’t stay in business on customer value. They make money from advertising and a lot of other things other than search. Again, customer value is necessary but not sufficient. Too narrow of a focus on customer value can lead to a failure of the business. I agree that customer experience is underserved in the Agile community. I believe that Customer Value is a key component of the fourth statement “Maximize Value Creation Across the Entire Process.” But, it is not the entire story.

Value as Economic Value

Eli Goldratt, in “The Goal” defines the making money today and into the future. This is about economic value. There are multiple views of economic value.

Business Value: Increase or Project Revenue, Reduce or Prevent Costs, Improve Service, and Maintain Compliance in alignment with the organizations strategy.

Cost of Delay: the cost to bear as a result of delay in investment.

Risk: An obstacle to Business Value.

Businesses are economic enterprises. Any view of Value that doesn’t acknowledge this is short-sighted. Agile is about quality software, organizational and personal value, and customer value. But at the end of the day, Agile is about improving the ability of the organization to improve economic outcomes.

Summary

Just like Agile, value is not well defined. And different people have different perspectives of value. Even when faced with the options, they decide that some of them are not important. I am a strong advocate of all the aspects of value – and Agile organization’s must setup guard rails to ensure that technical, personal, economic, and customer value are held in high regard. But they are a means to an end – not  an end unto themselves. There are parts of the Agile community that not only view these as an end unto themselves, but that promote the idea that a focus on economic value is actually bad. I don’t share this perspective. Agile is about improving economic outcomes. Technical, personal, economic, and customer value are enablers of this end. Doing these right helps deliver economic outcomes. Focusing on these outside the context of economic value is destructive.

I recently posted a presentation, Agile Foundations and Agile Myths, at www.slideshare.net/dennisstevens. My goal in the presentation is to juxtapose destructive behaviors arising from a predictive approach and destructive behaviors from an agile approach. This is a deliberately provocative presentation – finding flaws with the common interpretation of both sides of the discussion. Glen Alleman over at Herding Cats responded to my presentation in his post More Agile Claims. He took offense to my “strawman” arguments against the predictive approach.

Predictive Approach to Improving Software Development

What I am calling the Predictive Approach addresses the “mental scaffolding” or underlying assumptions I see everyday in companies practicing what they believe they are guided to do in the PMBOK®, OPM3®, CMMI and DoD . The Predictive Approach describes the practices that arise from the overzealous and misguided belief that the following approach is the best way to improve software delivery.

• Standardize processes
• Optimize resource utilization
• Perform rigorous up-front design
• Produce comprehensive documentation
• Get up front commitment to a definitive Scope, Cost and Schedule
• Enforce strict adherence to the detailed plan

This is where Glen takes offense. He points out that nowhere in the PMBOK®, OPM3®, CMMI or DoD literature are we instructed to apply these in the value destroying way that I discuss. In fact, he charges that I am just “making it up.” But, Glen misses the point. I am not arguing about the literature – I agree with Glen’s interpretation. And I am not making it up. Every day I go into companies that are applying this approach in value destroying ways. In the last year I have been in multiple companies whose documented methodologies prescribe:

• linear-document driven "over the wall" process thinking
• assigning resources to multiple projects
• comprehensive upfront design with detailed documentation
• commitment to definitive scope, cost, and schedule, and
• strict adherence to precise start and stop dates for individual tasks

I am not debating the literature – it is an issue of practice. Glen suggests in our discussion in the comments to his post that even the government sometimes exhibits this value destroying behavior.  My points aren’t straw man arguments against the literature – they are attacking a common set of misguided underlying beliefs that the value destroying practices arise from.

In fact, the Agile Manifesto itself arose as a response to common practice – not as a set of new practices. As of the writing of the Agile Manifesto, the writers (and many others including Glen Alleman and myself) had been practicing software development in an “agile” way for a decade or longer. Read the agile manifesto as a response to value destroying practice that is trying to bring attention back to what is necessary to successfully deliver software projects.

The Agile Manifesto

• Individuals and interactions over process and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Agile Approach to Improving Software Development

And now, … the rest of the story.

The Agile literature rails against too much planning, non-value added documentation, misguided change control, de-humanizing linear process, and layers of bureaucracy.  There is clear recognition in this faction that these are value destroying. But the overzealous and misguided application of these beliefs lead to the other common set of value destroying practices I frequently run into.

• No Planning
• No Documentation
• No Estimating or Commitments
• No Process
• No PM, BA or QA

Again, I don’t see the core agile literature advising these practices either. Alistair Cockburn, Jim Highsmith, Mike Cohn, Jeff Sutherland and Kent Beck all prescribe effective practices that support appropriate and progressively elaborated planning, documentation, commitment, and process. They all support the roles of project management, business analysis, and quality assurance when they aid in managing complex products. So the second part of my presentation addresses these misguided practices and presents finding a responsible and situation specific approach to delivering software that focuses on responding to change, enhancing flow and delivering value to the customer.

The Core Discussion

Glen’s response highlights an interesting challenge. My suggestion that current project management practices are value destroying brought out a strong response against agile. I have had the same response from the agile community when I suggest that agile beliefs result in value destroying behavior. Businesses need to be able to make informed business decisions – so we need predictability and planning (Check out Glen’s immutable principles). At the same time we need to manage the work in a way that protects and optimizes value. What is missing in many organization’s is a way to have the responsible discussion exploring underlying assumptions. Companies need to finding ways to make the situation specific changes necessary to balance predictive planning and agile execution.

What is keeping corporate executives up at night? Is the CxO laying awake wondering if her company is good at project management or software development? Probably not. AMA says that the top issue facing executives is executing their strategy.

“The practice representing the largest difference between higher and lower performers is demonstrating the ability to quickly and effectively execute when new strategic opportunities arise.”
~ AMA, The Keys to Strategy Execution, 2007

So what are the keys to executing strategy? Recent research from PMI shows that when we align projects with the business strategy and clearly communicate the strategy to the team, then projects are delivered at a much higher rate.

“The single most important factor influencing project success is the project’s link to the organization’s business strategy and the project manager’s understanding of how the project supports the business strategy.” 
~ CIO Magazine-November 2009: Business Strategy: The "Best Determinant" of Project Success

So it sounds easy, we need to focus on executing the projects that advance our business strategy. And we need to communicate this strategy across the organization and the project team. How well do the ways that we select projects and communicate their strategic significance accomplish this?

How Do We Select Projects?

So how do most organizations decide where to invest? Projects are selected for the portfolio based on local ROI’s calculated by business managers, or by spreading investment across the organization based on head count like peanut butter, or by charging IT organizations to run IT like a business with departmental reimbursement. Are these the best ways to handle this? Probably not. None of these connect the projects to strategy – and none of these make the connection between strategy and the project explicit.

ROI’s are almost impossible to estimate. Local ROI’s don’t equal organization level benefit. For example, one organization spent $10 million implementing an automated solution to allow them to scale for seasonal demand. The $10 million was justified through service improvement and reduced labor in the department but it shifted significant costs from departmental budget to the IT department for customizations, maintenance, and ongoing licensing. In addition, ROI’s don’t provide an effective way to communicate the underlying assumptions about how the project supports the business strategy.

Spreading investment based on head-count assumes that all improvements are equal or that we can do enough in each area to raise the whole ship. The is no way we can make all the improvements in the organization, there is a limited amount of capacity for change and there is a limited amount of resource to invest. It is extremely unlikely that all problems will result in the same benefit to the business. In fact, this approach, while extremely common, ends up being destructive. It spreads limited resources too thin, it creates excessive demand for the enabling functions (IT, training, project management, support). And it obfuscates business strategy.

Running IT like a business sounds great, but it is another case of local optimization. IT is an enabler of business value. Some of the investments the business needs to make will have short term costs but they will return long term value for the business. When IT is run from the view of short term profitability you will often miss out on the most important investments. In this case, IT’s strategy – making profit from its resources from the business – it not aligned with the business strategy itself.

Based on numerous studies, the leading obstacles to project success are related to scope creep and shifting requirements, inadequate and/or disappearing resources, and a lack of effective executive sponsorship. All of these are related to organization’s trying to execute strategy without a clear alignment between strategy and the projects in the portfolio. Local ROI’s, equal distribution of investment, and local optimization of IT don’t solve these problems. They don’t clearly connect project efforts to the business strategy. And they aren’t resilient to the real changes in the market that businesses have to be able to adapt to.

So What Do We Do?

We need a way to reflect the business model and the where the strategy impacts the business model. We need to be able to clearly articulate what changes need to take place to deliver on the business strategy. And we need to be able to adjust this model rapidly and communicate the real shift in strategy to everyone in the organization easily.

We use capability mapping to achieve this. A capability map, as discussed in an article I co-authored June 2008 Harvard Business Review "The Next Revolution in Productivity" http://hbr.org/2008/06/the-next-revolution-in-productivity/ar/1 addresses these challenges. It clearly articulates the business model in a stable way, let’s you directly connect the business strategy to the business model, and let’s you connect project efforts to the capability map. This provides traceability from project to business model to strategy in a powerful visual management tool.

Five Steps to a Powerful Capability Map

1. Articulate the Near Term Business Strategy.

We frequently use a model we have developed based on Patrick Lencioni’s “Silos, Politics, and Turf Wars” called a Thematic Goal Model. It is straight forward, powerful, and communicates clearly. We can provide input to this from a SWOT analysis, a balanced score card, or multiple empirical methods like QFD to determine strategic themes. The outcome is a clear statement of a limited set of the near term strategic themes. The next set of “big rocks” that need to move to advance the business strategy. The important thing here is to make it visible and to get buy-in from the organization.

2. Decompose the Business into its Constituent Capabilities.

Decompose the business into the activities or functions of the organization. The activities are performed for a purpose, to achieve some outcome or transformation the business needs to accomplish.  Then, interpret activities as capabilities. Capabilities are independent of how they are done, who does them, and the organizational structure. They are named in a “Verb-Noun” form and express the underlying business purpose. A common mistake is to treat a process, or a “how”, as a capability. For example, “Produce Invoice” is not a capability. The business purpose is not to produce an invoice. The purpose of producing an invoice is to “record a customer charge”  and to “request payment from the customer”.  You can decompose the capability map to whatever level is interesting for your particular situation. We will do a limited drill down to start and then build out a more detailed view as the business strategy dictates. This can keep you from getting stuck in an analysis paralysis. Develop the map collaboratively, you will want buy-in from the organization when it is time to make the tough calls about what to invest in.

3. Evaluate the Capability Map in the context of the Business Strategy.

For each capability you can ask a few questions determine the strategic significance. Is this capability directly related to the business strategy? Would a significant change in this capability directly help the business execute its strategy? This can be an interesting exercise because different people will have different perspectives on what is important. Be rigorous in the assessment. Everything in a business is connected at some level. You are looking for direct relationships between capabilities and strategy. When you get down to determining how to address any interesting capabilities you will get a chance to explore the other related capabilities. Keep bringing the focus back to the strategic connection – not to individual functions. Rank the capabilities on a scale of 1-5 with 1 being directly and 5 being not at all. The capabilities that end up being a 1 or a 2 are strategically interesting.

4. Determine Performance Gaps at the Strategically Interesting Capabilities.

Now, look at the strategically interesting capabilities. Determine the performance gaps you would need to close to achieve the business strategy. You are not looking to identify every potential improvement at the capability – you want to be specific about what improvement is needed at which capability to achieve the specific business strategy. Again, you have to be rigorous. The goal is to identify the smallest subset of changes needed to achieve the business strategy. Remember, this is a focusing effort.

5. Determine a Road Map to Achieve the Strategy.

Now, you have a very clear set of improvements to focus your improvement efforts on. Drive your portfolio decisions from here. Articulate these as a specific performance improvement, at a specific capability, to achieve a specific strategic outcome.  Initially, all of this is done at a relatively high level. Once you have your specific initiatives you can do more detailed discovery about the best way to accomplish the objectives. Lay these initiatives out across all the enabling functions. You want to balance the efforts against capacity to optimize time to strategic value.

Summary

Now we have a way to reflect the business model where the strategic impact is explicit. We can clearly articulate what specific changes need to take place to deliver on the business strategy. This model can keep us focused when we start to get pressure from multiple directions. But we can also adjust this model rapidly and communicate the real shift in strategy to everyone in the organization easily. Better than ROI approaches, better than a bottom up local optimization model, better than running IT as a business, we can focus our efforts on executing the projects that advance our business strategy. We can synchronize efforts across the various enabling functions to optimize time to strategy. And we can communicate this strategy across the organization and the project team. Each activity on every project can be clearly linked to strategy.

Here is the presentation I did at the Lean Software and Systems Conference in Atlanta. We combined Strategy Thematic Goal Models, Capability Mapping, Kanban at the strategy execution level with a cascading Kanban at the development level. The presentation was well received.