If we accomplish one thing in Big Agile, we hope it will be to provide a way for people to think about what they are doing and create a learning framework for being able to do it well and take it to scale.

We don’t want to try to present the one right path you have to follow – because we think each situation will require distinct strategies.  But we also want to get beyond the intuitive approach. Just saying, “Eliminate waste, identify and remove impediments, and write code better” is not enough guidance to create a reliable and sustainable approach that can be scaled .  So, what is a structured way to think about being good at Agile that supports getting big? Part of the answer is to focus on outcomes and purposes using capabilities. But how do we apply these and where do we start?

First off, teams are the organizational units that actually produce value.  So  getting small teams highly productive is the right place to start.  Then, as we scale, the principles that make the small team function well scale into different instances of the same principles. The objective is to add the least amount of overhead possible at each order while maintaining the productivity of the small teams.

Today, I present the (draft) Big Agile Learning Framework. This reflects the approach  I have intuitively used when approaching this problem. The three dimensions are Value, Velocity, and Context.  The capabilities of the organization operate together in an interdependent way.  Understanding how each one plays in this model, and how they impact each other, is a key to developing situation specific strategies for taking Agile to the Enterprise.

The Big Agile Learning Framework

Value, Velocity, and Context

Value: What the product development team provides back to the business that the business might sell to an actual customer.

When we look at value, we want to identify what Jack Welch called the value nub – the intersection where low-cost and just-the-right-features intersect. Moving up on the value axis means moving towards the nub. In Agile, we leverage the ability to get a working product to the customer frequently to continue to narrow in on the value hub. This helps us reduce the costs and risks associated with a granular up  front requirements effort.

Velocity: The rate that work is moving toward its objective.

Confusion over the distinction between speed, utilization and velocity is a common problem. Velocity is speed in one direction. The car driving 60 mph on a straight road has much higher velocity than the one going 60 mpg on a winding road.In Agile we increase velocity through finishing what we start, coordinating hand-offs to remove delay, improving quality, and continually removing waste from our processes.

Context: The environment that the team operates it. It is shaped by the team, the organization, the goal of the effort, and the sphere of influence of leadership.

Software development is a knowledge-based endeavor.  People need room to think and innovate.  Difficulties in the context can compromise efforts to improve Value and Velocity. In Agile we improve context through commitment to a productive environment, empowered teams, disciplined compliance with the team standards, working toward individual mastery, bringing in external knowledge, and managing expectations.

Each of the dimensions in the learning  framework are interdependent. Let’s take the capabilities around requirements as an example. In once case, we put in an up front focus on detailed requirements. We think they are perfect and they take a long time. So the capability is high on value but low velocity. As we move along on the project, errors in the original assumptions and evolving customer preference degrades the actual value, moving the capability down on the value axis. If we take an Agile approach, Agile recommends a lightweight, progressive elaboration approach to requirements. This would be farther right on the Velocity axis but potentially not as high on the Value axis. Over time, as we uncover specifics and move towards the value nub, the capability raises on the value axis. We also know when to stop adding things not valued by the customer – so we don’t begin to slide down the value axis again. Experience in software development shows this is effective, but the organizational context has to allow for this approach.

The Thinking Framework is a way to frame the development of strategies as we scale. As we develop situation specific strategies to scale Agile the way that we can impact Value and Velocity become more complex But keep in mind that we must not sub-optimize small team productivity. Top down approaches have not been consistently successful in scaling agile up into the enterprise. Just replicating the same practices up through the organization hasn’t worked either. Basing our work on capabilities and leveraging the thinking framework, we are able to develop appropriate strategies.

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.

I want to share the presentation I did in the Open Jam at Agile 2009. I got good feedback from some of the thought leaders there like David Anderson, Chris Matts, Eric Willeke, Chris Shinkle, and Mike Cottmeyer.  Ok, enough name dropping. A common theme at Agile 2009 was, “Now that we are pretty good at small teams developing software, what’s next?” One of the answers is making sure the developers are working on the stuf that provides the greatest value back to the organization. A lot teams aren’t very good at this.

If your projects are anything like most of the development projects I’ve been on you are likely to run into cost and time pressure near the end. Our story might be something like, “We can’t meet your needs for the planned cost or by your expected time-frame. We have been telling you from the beginning there was uncertainty in the requirements and that development is fraught with risk. You will just have to pony up.” Customer’s don’t like this but they have come to expect teams to be late and over budget.

If you had the foresight and tools to understand how to focus on eliminating risk on the front end and then building the highest value things first, you can go to your customer with a story like this, “Even though there is a lot of uncertainty in the requirements and exactly how we would build the software, we have a working product that meets all of your most important business needs. In fact, I bet you didn’t know that over half of all the technology built is never even used in the end. We would love to continue to build out the remaining features after we get this adopted by your customer, but we bet addressing what they think is important will be more valuable than building out elaborate and potentially unused features.”

I have used this approach on about a dozen efforts and have found that it promotes far better communication between the team, product owner, and customers. It provides clarity on what needs to be build, why it needs to be built, and how we can do acceptance testing on what is built. It is also low friction to maintain if the product or project strategy changes in flight.  It is a sustainable artifact that connects Ivory Tower discussions about business value and risk to the developers context.

Typical Business Analysis techniques have high transaction costs and high coordination cost while still not getting the key points across to development. We end up with lagging risk, too much rework, missing critical requirements, lack of testability, and over engineered products. This is very expensive – both in terms of what is spent to deliver to our customers and in terms of meeting the needs of the customers. Once we change the conversation from “What can we get done this week?” to “How can we optimize business value and manage risk responsibly?” we are on the right track to Feeding this Agile Beast.

There continues to be discussion about Scrum (as a brand) vs. Kanban (capital K) vs. Crystal vs. FDD, etc. If fact, I received a comment today on a March post discussing the Scrumbut test. My comment became to long and is so relevant to recent discussions that I turned it into a blog post. From my perspective these method wars tend to fall into “How Trap” discussions. How Trap discussions are not about specific outcomes you are trying to achieve and developing a situationally specific approach to achieving those outcomes.

Take a look at the Scrumbut test I learned about from Jeff Sutherland. Whether you are doing (or even like) Scrum – when viewed through an outcome lenses, these questions lead to discussion regarding clearly important outcomes. Below, I list the question category from the Scrumbut test, then the outcome that is desired from the practices described in the Scrumbut test, then a hopefully clarifying description.  The practices are detailed at the Scrumbut link.

Question 1 – Iterations: Limit Work in Process – don’t start anything you can’t finish

Question 2 – Testing within the Sprint: Maintain Code Quality – Shorten quality feedback loops to zero to maintain code quality and reduce the waste of rework

Question 3 – Agile Specification: Communicate Business Needs to Development – Ensure developers understand outcomes while minimizing coordination and transaction costs, maintain traceability to business need

Question 4 – Product Owner: Maintain Product Roadmap – The business communicates a plan of what is being built

Question 5 – Product Backlog: Prioritize Investments Based on Return – the business prioritizes work based on a current understanding of business value

Question 6 – Estimates: Provide Meaningful Effort Estimates – Understand rate the team can produce work to support planning, investment decisions, and customer commitments

Question 7 – Burndown Chart: Communicate Release Schedule – Be able to predict content and timing of future releases. This clarifies corrective action, next most valuable investment decisions, marketing decisions and customer commitments

Question 8 – Team Disruption: Maintain Productive Work Environment – Management understands and supports the focus on rapid delivery. Trust is established that the team will be able to meet current and future commitments.

Question 9 – Team: Develop an Empowered Team – The team feels empowered to make decisions about how to move forward. Management has provided sufficient guidance and direction that they trust the team will make operational and tactical decisions aligned with the best interest of the business.

Yes, Jeff has a brand he is protecting. If you think you are doing Scrum and you aren’t achieving these outcomes then you aren’t doing what was intended. Bad Scrum and Scrumbut hurts the Scrum brand. In fact, since Scrum is a dominant Agile brand, it hurts all of us trying to move Enterprises towards improved software agililty.

But, Scrum isn’t the only way to achieve these outcomes. I can map these outcomes to mature implementations of XP, DSDM, FDD, Crystal and Kanban (etc.). Now the interesting conversations sound like –

• In what situations does Kanban reduce transaction and coordination costs more than Scrum?
• In what situation does one method lead to better adoption over another? Why?
• In a specific organization, what approach to developing empowered teams and upstream trust will be most likely to succeed?

The outcomes described in the Scrumbut test can be achieved by applying specific strategies that are consistent within an organization’s environment. When these outcomes are adopted development teams tend to become more mature, better at delivering software (many times dramatically), and improve their work environment. Regardless of method, you need to be focused on the outcomes that result in improvements in productivity and find the way that works in your organization to adopt and sustain the outcomes.

In my last post I talked about starting with business value. Remember that a business capability describes something the business depends on for a specific purpose or outcome. As Mike Cottmeyer talks about in his post, Falling into the How Trap (http://www.leadingagile.com/2009/08/falling-into-how-trap.html ), Capability Analysis helps you change your view from process and politics… how you are doing work… to the actual business outcomes needed.

This is important, because in many companies silos, inertia, and budgeting all contribute to problems in organizations getting to business value. Here is an example of how Re-Thinking using business capabilities led to dramatic results in a difficult environment. The client was a financial services client. They were in a very politically charged environment that arose from rapid growth through acquisition followed by rapidly changing market conditions. This client was moving in an unfavorable financial direction. There was a lack of cash, tremendous pressure on IT, and recent lay-offs had led to a loss of trust and historical knowledge.

We met with executives to make sure we understood their strategy and could articulate it simply. We then worked with the managers to create a business capability baseline from the capabilities in the organization. We identified those capabilities that were most important to achieving the core business objectives and the goals for the strategic project. Against this view we reconciled the budgeted capital projects budget and the IT related operating expenses.

Our results showed three significantly interesting capabilities. For the most part our findings were not new situations – but the capability analysis brought visibility to them. This is one of the real powers of capability analysis. By focusing on learning “What” they did, then understanding how they did them and where they were investing we were able to present the findings to the business in a way that overcame the politics driving most of the decision making.

The majority of the budgeted and in process projects were focused on Manage-Customer -Requests. At first blush, this was reasonable since there was a sizeable Customer Service group and this was their primary focus. All of the requests would have resulted in improving how the Manage-Customer -Requests capability performed. These requests were prioritized to the top of the list because the VP of Customer Service was influential. But given the current needs of the business, this capability performed suitably – there was no performance gap in this capability.

Although, there were only three budgeted requests against it, the largest capability gap existed in Negotiate-Customer-Terms. This was also high business value because keeping the right customers and getting valuable new customers with the right offers was the key to the survival and profitability of the company. This project was not budgeted.

We also found four separate Business Intelligence efforts focused on Analyze-Customer-and-Market-Data. Two of them had been brought in from acquisitions. One of them was a rogue project started by the marketing group when they felt IT was too slow to respond. All of these were used (or planned to be used) for internal analysis and none of them were integrated into the customer service platform.

Using our findings from the capability analysis we were able to get agreement to shut down the redundant BI projects – saving about $8 million a year. Despite the momentum on these initiatives, they were not currently delivering value, they were unfocused in their efforts, and they weren’t aimed at high business value/low performing capabilities. We were able to draw from the best of these projects for the most important effort.

We then used the findings to get the VP of Customer Service to agree to stop the Manage-Customer-Requests initiatives. Even though these projects were budgeted, and some were in progress, the VP realized IT needed to focus their resources more effectively.

We then focused IT resources on the Negotiate-Customer-Terms leverage point and the necessary data integration. Since our need was very clear, we were able to generate very tight business requirements for the BI and development teams. Leveraging Agile development techniques we were able to complete the development and integration rapidly.

In summary, through performing a ReThink using capabilities analysis, we found redundant investment of $8 million that we were able to recover almost immediately. Then, by laser focusing development efforts on the most important business capabilities, we were able to deliver an initiative that improved the company’s portfolio retention by over $15 million a year. The total project lasted less than 9 months, cost less than the savings from eliminating the redundancy, and delivered what was most important to the business.

Capability Analysis allowed us to overcome silos, inertia, and the politics surrounding budgets. We were able to find cash for the project, relieve pressure on IT resources, and overcome a loss of organizational knowledge. By building a common view of “What” the business did and identifying needs at the top of the Business Value/Performance stack – the business reached agreement on what was needed and aligned their efforts accordingly. There are probably a lot of ways to accomplish this type of alignment, but we have consistently found success using Business Capability Analysis.

Lots of people are talking about the importance of prioritizing the work your software development teams do. For a product development group, this means picking the right features to build in the best order. For many IT organizations, it means selecting the right projects to work on to create value for the organization.

• Mike Cottmeyer at Leading Agile is talking about agile portfolio management at http://www.leadingagile.com/2009/04/in-my-post-second-order-agile-scaling-i.html.
• Back in January, I was talking about how important it is to Focus on the Right Projects http://www.dennisstevens.com/2009/01/22/focus-on-the-right-projects/.
• In the ganthead article, “Tough PPM Decisions” Bob Weinstein calls for a “comprehensive understanding of the organization’s business and industry, along with finely honed business analytic skills.”
• Over at PMThink! They are discussing this issue as well. http://www.pmthink.com/2009/05/project-value-delivery.htm “Our historical challenge is being able to identify and articulate business value in the first place”
• Thinking for a change talks about estimating business value using a forced rank order method.

So this is clearly important. We need focus on the right projects and features – in a way aligned with our business model and how we create value for our customers. We need to have a forcing mechanism to overcome the tendency for everything to be a number one priority. And we need to be able to understand how shifts in strategy and market conditions impact the prioritization.

But how can you do it?

I use capability analysis to identify where to focus and to align everyone in the organization with the decision. A version of this work was published in the June 2008 Harvard Business Review article, “The Next Revolution in Productivity.” It is also covered from an executive perspective, in Ric Merrifield’s new book, “ReTh!nk: A business manifesto for cutting costs and boosting innovation.” I have used it over the last 10 years to support dozens of businesses and projects.

What is a capability?

A business capability describes something that the business relies on for a specific purpose or outcome. The focus is on what the business does rather than how it is done. Most organizations are not accustomed to thinking about the business as a series of outcomes and fundamental purposes. They think about what they do – not outcomes and purposes. Sending a fax is an example. Ask someone what they do and they will say “I send faxes.” While a business might ‘send a fax’, sending a fax is not a capability, it is a how. Sending faxes is one way of achieving the business outcome of ‘notifying vendor’ or ‘communicating with the customer’. Also, capabilities remain stable. For example Pay-Payroll, it doesn’t matter whether you do it manually, internally, or outsource it. It has the same performance criteria, regulatory constraints, and inputs.

Capability Analysis is presented here as a five step process.

1. Identify the capabilities within in your business
2. Identify the capabilities most critical to your company’s success (Business Value)
3. Identify the health of the business capabilities (Performance)
4. Identify the business risk and technical risk associated with the capabilities (Risk)
5. Prioritize opportunities to the smallest subset necessary to deliver value

Identify the capabilities within the activities in your organization

I usually start with six high-level capability groups within the typical enterprise: develop and manage products and services, market and sell products and services, deliver products and services, manage customer service, manage vision and strategy, and provide business infrastructure. Identifying the specific capabilities within the enterprise involves creating a capability hierarchy within the capability groups.

For example, market and sell products and services can be broken down to activities and these activities can then be broken down to capabilities. This isn’t functional decomposition, think of it as a tree of cascading purposes.

Capabilities

There are several sources to build out these models. One excellent starting point is the Process Classification Framework from APCQ (www.apcq.org). This framework provides a relatively complete list of capabilities across organization’s across industries.

Identify the capabilities most critical to your company’s success

Critical capabilities are indentified by assessing how closely each capability is tied to the execution of business strategy and the direct contribution of customer value.

• Is this capability directly linked to a strategic objective? (Yes/No)
• How does this capability contribute significantly to the profitability of the company? (High/Medium/Low)
• Does it have a strong connection to company’s brand or identity? (High/Medium/Low)

By assigning scores to each capability and totaling per capability you can rank order the capabilities based on business value. If the business strategy or market conditions change, the model can be rapidly re-evaluated.

Identify the health of your business capabilities

Capability health is evaluated by looking at performance, cost, and the tendency to be a constraint. The more factual and objective you can make this data, the better. But a solid subjective assessment that has been agreed to by the organization is a very powerful tool.

• How is this capability performing relative to expectations? (Above/Meets/Below/Far Below)
• Is the cost per for this capability acceptable? (Too High/Acceptable/Below)
• Is this capability ever a constraint in the organization? (Often/Sometimes/Seldom)

Again, you assign scores to the factors and use the resulting score as a force rank mechanism. It is important to focus on improving where you can improve the ability of the capability to meet the needs of the business, reduce the cost per, or eliminate it as a constraint. One nice thing about this evaluation method is that any initiative now has a very specific out. And that outcome can be tied directly to the business strategy.

Identify the business risk and technical risk associated with the capabilities

Finally, they are evaluated for the risk associated with changing (or not changing) them.

• Is the technology and the vendor stable and aligned with the IT strategy? (Yes/No)
• Is this a highly connected, highly regulated, or unpredictable capability? (Yes/No)
• Will this capability support any anticipated growth? (Yes/No)

Prioritize Opportunities

Now that you have clarity of your business model or product you can prioritize within specific portfolio segments. For example:

• High Business Value/High Performance/Low Risk: Operate
• High Business Value/Low Performance and/or High Risk: Invest
• Low Business Value/High Performance/Low Risk: Optimize
• Low Business Value/Low Performance/High Risk: Eliminate

The majority of your capabilities will fall outside one of these segments. You probably shouldn’t be spending everywhere all the time and these segments highlight where you should spend and what type of action to take. As you complete initiatives, capabilities will move into new segments. For example, the High Business Value – Low Performing capability better be moved out of the Low Performing segment at the completion of a project.

Visual Tool

The findings can be presented graphically in a heat-map fashion. In the heat-map the border is strategic value, the fill is suitability of performance, and the dot is risk. The red-colors means it is interesting, green means it is not something to evaluate.

For example, the capability above is strategically important, performs suitably, and has some risk. In future posts I will show a more detailed capability model with cascading capabilities. This type of Visual Tool serves to align an organization around a common vision. It also can highlight where there is a disagreement around the perspective. These conflicts should be resolved so management is focusing all efforts in a common direction.

Benefits of Capability Modeling

This is a high level look at capability modeling. Based on the complexity and maturity of an organization this approach can be established and maintained rapidly and with low friction. The approach facilitates:

• A clear connection of development work with business value
• Alignment of organizational and infrastructure decisions with business value
• A stable context for understanding and communicating across functional areas
• Requirements clarity and testability
• Negotiating the balancing of technical and business risk
• A progressive elaboration model that supports an Agile approach to improvement

This is a high level overview of how to execute a Capability Analysis. Most of the assessment will require a high-level of detail in the preparation of questions. You will also decompose the business or product to more detailed capabilities in those areas where it provides value. We have a new Yahoo group called rethinkbus you should join if you want to interact with people who are learning about and have done projects using this approach.

During the past several months I have been involved in a number of conversations regarding Lean, Agile, Kanban, and Traditional methods of software development. Most experienced people believe that there are appropriate practices from each of these methods and that each organization has to come up with their best implementation. In the discussions the question continues to come up whether it is more important to teach principles or practices to teams adopting new methods.  I think this is a premature discussion. Without an understanding of purpose – the direction you are heading will not be clear.

Start with Purpose

Principles and practices are both about “How”. Principles are about the theory of “How” and practices are about the mechanics of “How”. “How” discussions that happen out of context often result in dogmatic conflict. The right place to start is to focus on “What” you are trying to do and “Why” you are doing it. We need to focus on the purpose of what we are doing in the context of the business strategy. Then drill into appropriate principles and suitable practices to implement. All too often, teams are focused on “How” without clarity of the “What” or the “Why”.

Sounds great, right? So how do you do this? I have had dramatic success in helping organization’s achieve dramatic improvements in performance using a purposed based approach. The approach based on focusing on “What” and “Why” is called Business Capability Analysis.

What is Business Capability Analysis?

Business Capability Analysis is based on rapidly developing a model of the business to identify where to improve and facilitate discovery of the best way to improve. The common model gets everyone involved focused on the purposes involved and results in a shared understanding of what needs to be accomplished to achieve the business strategy. This understanding is critical before you start applying practices and principles.

Business Capability: a particular capacity or ability that the organization relies on for a specific purpose or outcome.

• Business Capabilities are purpose focused. Their purpose is to produce value for the organization. What are we trying to do and why are we doing it? How does this capability help achieve the business’ strategy and operating objectives?
• Business Capabilities remain stable – even when the implementation changes. For example, almost every business has a “Pay-Employees” capability. Regardless of implementation, the regulatory requirements, employee expectation, interface with accounting, and many other factors don’t change. What you are trying to do and why you are doing it remains the same whether you automate it, outsource it, or are doing it manually.
• Business Capabilities provide a common business focused model for other attributes. Ownership, cost per, timing, and other interactions are a sample of the attributes that can be captured within a capability. Business Capabilities can be used to align the organizational, technology, process, and information of a business.
• Business Capability performance is dependent on the interactions with other capabilities.

Business Capability Example

Let’s use “Travel-To-Work” as an example. The purpose of “Travel-To-Work” is to get where you need to be so you can do your job every day. It is important that you are on time reliably. Based on your objectives, you may implement this capability differently. This choice will drive organization, process, and technology decisions. Here are a few examples of implementing this capability based on differing objectives.

So the capability is stable even when the implementation changes. While we can debate on appropriate implementations, an interesting aspect of this approach is that it frees us up to discuss alternatives to achieving the purpose of the capability. Remember, the purpose is not to travel to work. The purpose is to be where you need to be to do your job. Why do we need to physically travel to work? Another approach might be to provide access to the computer systems and telecommunications. By looking carefully at the purpose of the Capability in the context of our objectives, we can come up with an innovative new implementation.

Capability Analysis Applied to Documenting Requirements

Let’s look at document requirements through the Business Capability lens. This is an area of significant conflict among the various software development approaches.  Agile advocates will tell you that there is no way to build perfect documentation up front – that this is a collaborative effort and any more than rudimentary documentation will result in waste. BUFD advocates will tell you that to the extent the project outcomes are knowable up front, it is irresponsible to fail to produce an appropriate requirements document. It is irresponsible because you don’t understand where you are relative to the promise made to the business relative to cost, time, and scope – you have no way to measure performance.

So, one of the purposes of documenting requirements in software development is to communicate what we want developers to build. Another is to establish a baseline so we can make sure we are on track to meet a commitment to the business.  There are two distinct capabilities here, Communicate-Needs-to-Development and Evaluate-Project-Progress.

In many software development organizations a highly detailed document may not be the best way to accomplish either of these.  Based on the nature of your organization’s projects and the level of clarity of the technologies and customer needs, these two capabilities will have different cycle times, different owners, and will interact with different capabilities.

The capability here is not Document Requirements. Documenting requirements is a means to an end. There is no business value in getting better at documenting requirements for the sake of documenting requirements. Conflict arises when the focus is on the “How” instead of the “What” and “Why”. Implementing practices or principles without a focus on purpose results in waste, conflict, and constraints to understanding. Taking the time to understand the actual capabilities and focusing on achieving the purpose will pay big dividends.

There is a lot of focus on Agile practices in software development today. This is because, when practiced successfully, Agile engineering, collaboration, and management practices improve the ability to produce valuable software reliably and continuously. These new practices also create new possibilities that can improve the organizations ability to profitably deliver value to the customer. However, if you plan to realize the benefits of Agile by focusing only inside the software development organization, you are likely to be disappointed in the outcome.

When implementing Agile, there is a lot of time and energy invested in improving software development teams. Businesses don’t make this investment because they want to get better at software development. They are trying to improve their capabilities from “Identify Customer Need” all the way through to “Fulfill Customer Need”. The Agile team is only one part of the business ecosystem.

Agile Impacts the White Space

Implementing Agile practices in the software development team impacts their interactions with the other functions in the business. The frequency, content, and context of the interactions are different in Agile. As much as the Scrum and XP practices help improve performance within the development team, addressing what happens in the white space between functions is the key to implementing Agile in an organization. In an existing organization of any scale, these white spaces can’t be hidden behind a Product Owner where the challenges self-organize themselves out of existence.

Agile Teams have to integrate with existing Product Management. Based on their understanding of the market and customer needs Product Management has to make promises on the timing and profitability of products to a CFO who reports those promises to a board and to the public. They still have to support the BUFD (Big Up Front Design) Teams. This work is important to the organization and the Agile Team has to interact in a way that allows Product Management to keep these promises.

Agile Teams have to integrate with existing Project Management. Project Management has to make promises on releases regarding cost and timing. They manage risks (external to the Agile team), track and report status, coordinate procurement, arrange for resources, and manage the performance of the project through the phase gates to the governance committee. This work is important to the organization and the Agile Team has to interact in a way that allows Project Management to be successful.

Agile teams have to coordinate with Sales and Marketing, Accounting, Operations, Human Resources, and Customer Support to make sure they are aligned with the features and timing of a product release. These functional areas are key to the operation of the business and the delivery of value to the customer. The Agile Team has to interact in a way that allows them to perform successfully.

Optimize the Whole Value Stream

In most sizeable organizations the development team is not on an island with no dependencies. They need to operate in a way that they can help the other functions of the organization be successful (and vice versa). Implementing Agile with a myopic focus on the development team and a lack of understanding of the interactions within the organization can actually increase the cost to the organization of meeting the needs of the customer.

To gain benefit from Agile, you need to understand how the capabilities fit together within the organization to create value for the customer. Focus on scenarios where Agile practices can improve the flow of value to the customer and create a competitive advantage. Identify the conflicts in the white spaces that are in conflict with the processes and metrics that currently exist. The decisions you make about these conflicts will determine the level of benefit you can get from implementing Agile. If your functional metrics, processes and incentives do not align behavior in the White Spaces you won’t get the benefit.

Mike Cottmeyer over at Leading Agile is talking about scaling Agile across multiple teams. This is an important conversation and must be addressed to get benefit from Agile practices. But to truly realize the promise of Agile an organization must intentionally improve the interactions in the white spaces as well.