Dennis Stevens and Associates

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.

Tags: Agile, Capability Analysis, Innovation

This entry was posted on Saturday, June 6th, 2009 at 8:39 am and is filed under Agile, Capability Analysis. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.