Over the last month I have presented or participated in several user groups and conferences. There was Southern Fried Agile in Charlotte, Agile 2010 in Orlando, a PMI Atlanta professional growth event, meetings of Agile Atlanta and the Atlanta Scrum Meet-up, and Product Camp Atlanta (not surprisingly in Atlanta). These conferences give me an opportunity to meet with people doing, or attempting to do agile in the enterprise. There are a lot of common patterns that I am seeing. One of the most common patterns is that we are doing QA all wrong in most companies.

Imagine if someone approached you up front and said “I have an idea. Let’s design our product development system like this. First, development is going to take in less then precise requirements. Then development is going to build something from the requirements. Then we are going to deliver this to a separate group that will then figure out how to test it for accuracy. Then that team will test it. When the product doesn’t pass the test we just defined we will return it to development for them to fix it.”   Is this the way that your test organization operates with your development organization? Does the relationship between QA and development seem reasonable? Why are challenges between QA and development so prevalent in our organizations?

We Don’t Understand Quality Assurance

Quality Assurance and Quality Control are different things. We have Quality Assurance organizations – but most often they are involved in Quality Control control activities.

Quality Control: Find defects. These activities are focused on validating the deliverable. They are performed after the product (or some aspect of the product) has been developed. It also enforces fit to specification. This protects production and our customers from getting defective deliverables that do not meet the specification. But when done on a completed product it isn’t doesn’t enable flow and defects found downstream of the deliverable result in rework in development.

Quality Assurance: Prevent defects. These activities are focused on the process used to create the deliverable. They are performed as the product is being developed. So, Quality Assurance should be helping us improve our processes so we don’t create defects in the first place. A key point to this is that creating a common understanding of the specification and how we will validate it up front is really important to eliminating defects.

If your Quality Assurance activities are primarily focused on finding defects and ensuring fit to requirements after the fact then your QA group is primarily doing Quality Control. Getting QA involved in improving the specification communication process through is a good place to start. A specific technique might be exploring communicating acceptance criteria to development with the same examples QA will use to perform acceptance tests.

We Don’t Understand the Cost of Rework

Finding defects after the product has been delivered ensures that you will generate rework. Rework from failed QA tests are extremely expensive to flow. Sending work back into development interrupts work in process. This has a dramatic effect on cycle time across the system – which results in increased cost of every item in the system.

After the fact testing is also typically done in batches when a release or iteration is delivered to QA from development. Defects uncovered in these batches create bottlenecks at development.  Just like when traffic backs up on the highway, bottlenecks in product development result in a long term cost to the overall system.

We can dramatically reduce the cost and adaptability of the system by reducing this rework. One way to address this defect bottleneck is to perform quality control frequently – not in batches. Another way is to prevent defects through effective quality assurance in specification understanding and in development. This will reduce the number of defects produced that escape to Quality Control.

We Have Designed the Product Development System Wrong

We used to teach that there needed to be a separation of testing and development. Having them both report to the same person was like having the person that wrote the checks in accounting also reconcile the check book. It was too easy to cheat.  We created QA teams that were completely separate from development – and that reported up through different management structures. I was talking to the director of development at a company where the QA and development chains of command meet at the CEO. When you design the organization to QA and development in different silo’s you will make it very difficult to have effective Quality Assurance involvement. You will ensure Quality Control behavior.

This separation made sense at one point (I think). It doesn’t make as much sense today – especially as the resulting silos result in slower delivery times and increased costs. What has changed in the last 10 years is:

• the cost of setting up testing environments is much lower
• our ability to rapidly and frequently produce testable deliverables for these environments is much greater, and
• our ability to perform acceptance, integration, regression, performance, load, and stress testing frequently is enhanced.

Quality Assurance needs to be part of the development team and process. We need to change our thinking around this.

So we need to integrate Quality Assurance very early in the process. We need to ensure early arrival of acceptance test examples to development. But, we still need independent test teams when we are doing large or complex projects that require integration of many team’s outputs. Independent test teams can be running parallel testing or test-immediately-after delivery. When they are getting high quality components, they focus on user experience, performance, load, and stress testing.  Move everything you can into the development teams (enhanced with quality assurance) so you can produce low defect escape rates. Then eliminate the defect bottleneck and increases in cycle time by treating most of the defects at the independent test team as new specifications to development.

We have the Wrong Expectations

We Expect Perfection – Not Improved Value

Our QA organizations tend to be focused on defect identification and perfection in delivery. The focus of QA, and everyone in the organization, needs to be on producing value-add and delighting the customer – not on defect-free code. This doesn’t mean that defects are okay – but every application has some defect or limitation. Unless you are building aircraft navigation systems or other critical systems you are going to deliver some defects. Make sure the defects don’t block business value – but there is a point where it is more important to the customers and business to deliver value.

We Expect Local Optimization – Not Flow

Rather than perfecting Quality Control, QA can add a lot of value helping the organization enhance the flow of value through the entire product development system. Delivering a unit of value requires analysis, development and testing. There is no value delivered internally. The local optimization problem of improving one area at the expense of another is not useful. Crossing the boundaries between analysis, development, and testing is needed to optimize flow of value. The various teams need to figure out how to do it together – not just improve their area.

Expect our Current Constraints to be Permanent

Organizations labor under the belief that their constraints are fixed. Find a way to break down the barriers that lead to your constraints. Don’t accept the current constraints as permanent. Increase thinking at the system level to find ways to improve the product development process.

We Don’t Use the Tools Available to Us

There is an impressive amount of automation and related techniques available at very low cost to help build the QA environment that allows for fast feedback, building on progressively tested levels, and improving opportunities for frequent testing. Developers should be using tools that support automated unit testing and only checking in code that passes all their unit tests. This provides a basis for validation and refactoring. Test driven development or test  just after development should be ubiquitous – but it is not. Continuous Integration environments that ensure that each check-in results in a valid and testable platform help teams perform integration and build validation. This helps everyone work on a stable build and ensures that no one gets way off track. There are automated tools for acceptance testing and some levels of UI testing. When the tools are combined you can build a very powerful regression testing environment that can also rapidly perform performance, load, and stress testing.

The lack of general adoption of these tools probably has multiple roots. Sometimes it can be difficult to leverage all of them with legacy systems. They require new skill sets and generate new artifacts that have to be maintained. On the surface, they automate tests that are currently performed by QA groups and so their is fear and organizational threat. But some subset of these tools should be broadly adopted by each team. QA teams can focus their efforts on valued added items like Exploratory Usability Testing and Release Validation.

Summary

Most organizations are doing QA all wrong. It is time to start doing it right, the cost of low quality in dollars, time, customer satisfaction, and the engagement of employees depends on it.

• Switch their primary focus to Quality Assurance
• Help the organization reduce re-work
• Integrate QA and QC with analysis and the development organization and work to eliminate defects – not just identify themF
• Enable value, flow, and ongoing improvement
• Leverage proven tools and techniques across the Product Development Organization to increase the value delivered

The status quo is not sufficient to meet the needs of most organizations. While not all of these approaches will be right for every situation, the rate of adoption is too low to be justified. There is far too much latent value being tied up in organizations because we are doing QA all wrong.. What obstacles do you see in your organizations?

There is a nice summary of Kanban at http://www.kanbandistilled.com/. It shows Feature Requests going into the Software Development Pipeline and Improved Software coming out.The article does a great job of showing how Kanban helps improve the flow of software development. Getting better at software development is important and Agile methods have been helping teams achive this goal. This is the first bargain of Agile-delivering software faster and with much higher quality then ever before. In most organizations however, this is only a small part of the business equation. Even when development is successful, a narrow focus on software  development narrows the value an organization will achieve. We also need to align of development with the most important needs of the business, balance development with adoption, and ensure improved business performance is achieved.

Feeding the Software Development Pipeline

Unless a company is a software development service provider, its business is not about software development. Software likely enhances the businesses ability to create value for it’s customers. So, while Agile development helps teams get better at software development – the goal is to get better at creating value for it’s customers. The focus of Agile software development is upside down. The focus should be on the capabilities of the business. Aligning development with the needs of the business requires understanding  which business capabilities will benefit from improvement and prioritizing these needs based on business value.

After using a business capability approach to need identification and prioritization, the business needs must be appropriately scoped and communicated to development. Over the last month I have been writing about Making Agile Requirements Work. need to make sure the requests that go into the Software Development Pipeline are clear and appropriately defined. Following the six principles of Agile Requirements That Work help with this feeding of the Software Development Pipeline.

1. Articulate Purpose and Outcome
2. Establish a Shared Language
3. Provide a Stable View of the Business
4. Support Progressive Elaboration
5. Testable
6. Prioritized and Reflect Business Value and Risk

Gaining Business Benefit

The other part of the equation is to ensure the organization adopts and supports the improved software. Once the Software Development Pipeline has produced Improved Software, it still isn’t valuable until the Business Capability has achieved the intended performance improvement. Just as the elicitation and analysis of requirements has to match the cadence and needs of Software Development. Software Development has to match the cadence and needs of the organizations ability to adopt and support Improved Software. Part of the overall feedback to the organization includes ensuring the capability improvement is achieved.

Risk

At every step in this equation different risks may exist. identifying, prioritizing, and scoping feature requests have risk associated with a lack of understanding. Software Development has risk associated with the Ability to Execute and Verify the delivered software. Benefit realization has risks associated with achieving adoption and being able to sustain and support change in the organization. These risks should be explicitly managed and feedback mechanisms should be in place to recognize the realization of risks. Failing to understand and manage risks in an integrated fashion will also diminish the organization’s ability to maximize benefit from it’s investment.

The Real Agile Bargain

The real agile bargain is the maximizing of economic outcomes by increasing the speed and focus an organization can improve and respond to the market. The Agile Business Value Equation is solved at the Business Capability Level. The ability to rapidly develop high quality software moves Technology from a change obstacle to become an change enabler. This happens at the intersection of Feeding the Software Development Pipeline, Developing the Software, and Gaining Business Benefit. Solving any of these parts independent of each other does not result in optimizing business agility.

On many software development projects, teams that are interested in getting started writing code early start by building the things they understand first. While this gets code started and in front of the customer as soon as possible, it isn’t necessarily the shortest time to value. This approach also sets the team up for the later stages of the project to be wrought with uncertainty and pressure from the business.  Two keys to successful Agile projects are focusing on early learning (mitigation of risk) and then rapid time to business value.  This is achieved by prioritizing the order that work is performed by the team.  When requirements analysis doesn’t clearly communicate the areas requiring risk mitigation and clearly identify those requirements that are most valuable to achieving the business outcome, then the team can’t appropriately prioritize the work.

Requirements reflect business value and risk

On most software development projects, not every requirement is equally valuable to the business. Some requirements are core to achieving the business outcome expected for the project and some are critical because they are  deliver on the brand of the business. But others, while valuable to the business, may address edge conditions or be nice to haves. Requirements need to be prioritized so that unknowns are addressed early, then higher business value requirements are addressed, then the remaining requirements. Part of the requirements analysis process should include an assessment of business value and risk.  If the prior principles have been applied, but the requirements are not worked with an eye toward risk mitigation and business value priority, the team will not be optimizing investment or time to value.

Because software development has some level of uncertainty, it is likely that a project will reach the end of its budget or time estimate before delivering on all the requirements expected. If you haven’t prioritized business value and risk, you may have to report, “We are really, really close. For just a little more investment or time, we can deliver something that meets your needs”. It is far easier report at the end of the time constraint or budget and say, “We have delivered on the most critical features and addressed the primary risks. At this point you can use the system we have delivered to address (most of) your business need. However, if you want to continue to invest, we can add additional capability.”

Many projects wait until the project is in danger to begin the trade-off analysis. Early work is done to a great deal of detail and late work is rushed through. The time to triage the requirements is at the beginning of a project. Then at each stage of elaboration, the detailed requirements should be further triaged. Requirements must reflect business value and risk – and the work should be prioritized based on these factors.

I hear a lot about emergent outcomes, and progressive elaboration, and self organization on Agile projects. These are slippery slope concepts, and far too often are applied irresponsibly. Emergent outcomes don’t mean we have no idea what the business is paying for – they have a pretty clear idea of the problem they are investing to address. Progressive elaboration doesn’t mean the team will figure out what they are doing as they go along – it means they will gain clarity on mitigating risks and meeting the technical and customer experience aspects of how to solve the business problem as they move forward. Self organization doesn’t mean the team can work on whatever it wants – it means that the team collectively decides the best way to focus their efforts and skills on a specific effort.

The business is willing to make an investment, to solve a specific problem, within a specific timeframe. In the first four posts of this series we discussed that the way that requirements are captured should express the purpose and outcome, they should establish a shared language that communicates context and intent, is should be a stable view of the problem, and it should support progressive elaboration. In addition, Agile requirements include clarity on what "done" looks like. Agile requirements also include identifying the impediments to getting to "done".

Agile Requirements should be Testable

Not having a clear outcome does not make a development effort Agile, it makes it irresponsible. If we don’t communicate requirements in a way that we can ensure the requirement is accomplished then we are being unclear about the value proposition we are trying to achieve. By testable, we don’t mean the “how” of implementation, we mean understanding what is not available or performing adequately what will be different after the requirement is delivered. If the business can’t communicate to the developer how to make sure they know when they are done – the project will meander. Even with lots of customer involvement during development – it is likely that development will be less focused than it could be.

What does it mean to be testable? I have a client that had its development team develop a “data-warehouse” to provide management reports. The developers spent eight months defining all the data in the business, developed programs and processes to consolidate the data into a central repository, and started building reports against the data. Eight months later the manager’s biggest problem is that they don’t have the information the need to manage the business. How is this possible? The business wanted a data warehouse and they got one. They have been intimately involved in the data gathering process. They have been asking for reports through the system for months.

The problem is that no one stopped to understand how they would test the requirement. How would they know if the business need was met? The business need is met when the manager had the information needed to manage the business. When the requirement is communicated as a granular “how” – and there is no way to verify it has met the need of the business – the business is unlikely to get what they expect.

Dictionary.com defines a requirement as “that which is required; a thing demanded or obligatory”.

BABOK® is consistent with this. It defines a requirement as:

1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective
2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
3. A documented representation of a condition or capability as in (1) or (2).

The purpose of documenting requirements is not to document detailed steps that someone performs – it is to communicate the outcome needed to achieve an objective. One problem that arises is when requirements are expressed as a document of the existing process – typically through a review of existing process documentation or through observation of people doing the job. As I have discussed in previous posts, just documenting process can lead you into the How Trap and it can fail to generate a useful shared understanding. These problems arise when the focus is on how stakeholders are currently doing the work and not on understanding the challenges, problem or objective.  But, focusing on process is a problem in another way. It is an unstable lens.

Unstable

Modeling processes early in the elicitation process is not helpful to creating an appropriate understanding of the effort. Process reflects how people say they ought to do a task in perfect circumstances. The work is almost never consistently performed based on process documentation – or even how you observe the process being performed. Exceptions, reorganizations, changes in personnel within or adjacent to process, new tools and technologies, and innovation will change the process view. Even just asking five different people what the process is will likely produce five different results.

The process view can also propagate flawed understanding on the part of the people doing the work. You have likely heard the story about the recently married young women who was cooking her first Thanksgiving dinner in her own home. She had invited her family over the beautiful house she shared with her husband to show her parents how successful she had become and to demonstrate her gratitude to her parents. As she brought out the turkey for dinner her mother noticed the young women had cut the tail off of the turkey. The mother asked her daughter why she had cut the tail off the turkey. “Because that’s they way you always did it, Mom.” The mother smiled and replied, “That’s because the only pan we owned was too small for the turkey.”

A process based view hides assumption, complexity and is an unstable representation. The real requirement doesn’t change based on who you ask, who is doing the job, or the most recent reorganization. Basing requirements on unstable views doesn’t reflect the intent of the solution. This may result in an expression of the solution that doesn’t meet the needs of the business. As you observe a process or review process documentation ask why each step is important and what the intent of each step is. Consider what would happen if the steps were done in a different order or something was left out. Creating a stable, purpose driven view of the objective will provide valuable input to the development organization that will result in an improved solution.

This is the final post in my review of the impact of Agile on the tasks within the knowledge areas of the BABOK®.  There are some interesting findings from this exercise. The implications are that while some business analysis tasks are performed within the development team, the business analyst role itself is more strategic and challenging on agile projects. A clear understanding of the BABOK tasks and how they should be addressed on Agile projects will dramatically increase your ability to deliver value through Agile projects.

So, What’s New?

First off, the business analysis tasks are not just aimed at documenting requirements. There are three primary targets of analysis activities. Many tasks address the features of the product. These are aimed ensuring requirements are elicited, communicated, and the solution is verified. There are business analysis tasks aimed at understanding organizational readiness and transition requirements. Finally, there are business analysis tasks aimed at understanding and improving the ability of the organization to develop and deliver the solution.

Secondly, all the tasks are still necessary. However, unlike a traditional project, where many of the analysis tasks are performed up front, they are performed continuously throughout the project. The requirements for the solution, the ability to deliver, and the readiness of the organization are evaluated incrementally throughout the project and the approach is adapted to improve fit and performance.

Finally, the understanding of requirements, organizational readiness, and development capabilities is progressively elaborated throughout the project.  In Agile, the development team itself performs detailed business analysis activities within the development iterations. The business analyst continues to operate in front of and after the development efforts. Lightweight requirements documentation combined with an emerging understanding means the business analyst become an advocate for the product. They collaborate with the team to ensure a shared understanding unfolds. The business analyst also facilitates the understanding and implementation of improvements in the business analysis and organizational readiness processes.

Summary of Business Analysis Knowledge Areas

Business Analysis Planning and Monitoring.  The tasks in this knowledge area are still primarily performed on the front end. The team will agree on the approach it will take in business analysis tasks. This means agreeing on who and how. All the task purposes in the BABOK still need to be planned – but planned to support the cadence of the team and the emergence of understanding through the project. The way the business analysis tasks are performed are not cast in stone, they will be updated through inspection and adaptation throughout the life of the project.

Elicitation. This knowledge area occurs continuously in a progressive fashion and responsibility for the product requirements changes hands during each iteration.  These hand-offs associated with the various levels of elicitation can contribute to lost knowledge and increased transaction costs.  An approach that ensures continuity of understanding is critical.

Requirements Management and Communication. The existence of Requirements Management and Communication in a single Knowledge Area demonstrates the closely held traditional belief that documenting and tracking something is the best way to communicate it. It is important that the method of documenting requirements at the higher level is lightweight while still facilitating understanding, focus and priority. In Agile projects, communication should be viewed as completely distinct tasks. At the detailed levels, there is a transfer of context, purposes, and outcomes requirements that is best performed through conversation between the customer and the development team.

Enterprise Analysis. The business analyst will still carry primary responsibility for understanding organizational readiness, transition requirements, and solution verification.  They will need to communicate findings from releases back into transition requirements to improve release performance. Gaps in the fit of the solution will feed back into the requirements backlog. Enterprise Analysis is very strategic, outside the scope of the typical Agile development team, and critical to the successful realization of business value.

Solution Assessment and Validation. These tasks happen continuously in a progressive fashion. The Big Solution Architecture will still be developed with input from the Business Analyst as well as Architects. The Business Analyst will need to understand and address the impact that progressive elaboration has on the transition requirements.

Requirements Analysis. Prioritization and organization of requirements happens as part of backlog prioritization. The business analyst should make sure that business value concerns and risks associated with assumptions and constraints are clearly understood here. Like Enterprise Analysis these tasks are very strategic, often outside the scope of the typical Agile development team (presumed to be understood by the Product Owner), and are critical to the team’s ability to burn down risk early and get to business value fast.

Missing Tasks

I believe there are at least three areas regarding business analysis on Agile projects that are not addressed by the BABOK.

Enrolling Stakeholders involves making sure everyone understands how they will participate. Just documenting a process or developing some templates don’t ensure appropriate engagement.  Stakeholders may play a role making sure shared understanding of the product requirements exists, they may be responsible for development process feedback, or they may need to participate in the transition of the solution.

Understanding Requirements is the new task or set of tasks that deal with generating the shared understanding of context, purpose, and outcome that is necessary for successful projects. Since the understanding of what is being developed and how it is being developed will emerge over the course of the project specific tasks must be in place to establish this shared understanding.  This may sound like a subtle extension of communicate requirements but this is social in nature and is fundamentally different than the push of communicating requirements.

Organizational Learning extends Enterprise Analysis. Not only does the readiness of the organization to use the product need to be reviewed, the ability to develop, deliver, and support the product needs to be evaluated. This task includes the introspection, retrospectives, operations reviews, and outside review of best practices that the organization performs to improve its ability to use and deliver solutions.

Agile Business Analysis Summary

The common concept that Business Analyst’s add no value to Agile projects is flawed. It is true that some of the detailed business analysis activities will be best served through direct interaction between developer’s and the customer. The high level planning and coordination around these direct interactions should not be abandoned but should be managed to facilitate focus on business value and shared understanding while minimizing transaction costs.

Additionally, there are many critical business analysis tasks outside the scope of the development team. Particularly, the tasks involving Solution Validation, Enterprise Analysis, and the inputs to Requirements Analysis are very strategic, outside the scope of the typical Agile development team, and critical to the successful realization of business value. A clear understanding of the tasks and purposes in the BABOK® demonstrates the strategic nature of Business Analysis tasks, highlights where the tasks should be performed within the Agile development team, and will increase the ability of the development team to achieve its objective of rapid delivery customer value.

Today I am discussing the tasks from the BABOK® associated with Requirements Analysis. These are the tasks to organize, prioritize, and model requirements and risks. There are six tasks associated with Requirements Analysis. I show the BABOK purpose. Then I discuss the impact on who and how in projects leveraging progressive elaboration, incremental delivery, close customer engagement, ongoing learning, and self organization.

Prioritize Requirements

Organize Requirements

Specify and Model Requirements

Define Assumptions and Constraints

Verify Requirements

Validate Requirements

Agile Requirements Analysis
All of the tasks in Requirements Analysis are important on Agile projects. The primary distinction in this Knowledge area is the support for the emergence of the solution over time. Particularly interesting is Define Assumptions and Constraints. While many Agile teams focus on the impediments to delivering code, they fail to manage the bigger risks and constraints associated with getting to business value.

The Model I am looking at today is from “Creative Solution Finding: The triumph of Breakthrough Thinking over Conventional Problem Solving” by Gerald Nadler, Ph.D. and Shozo Hibino, Ph.D. I used a lot of these concepts as I laid the initial capability analysis input to Microsoft’s Business Architecture offering. The concepts support rapid development of a strategically-aligned and situation-specific solution road-map. The focus on solution context and including people in the design also encourages adoption by the end users. I believe the application of these concepts were instrumental in several successful transformations I have led.

Creative Solution Finding

There are seven principles in the model. These principles build on and support one another. Like the other models, none are complicated – but all are difficult to apply. In this case, you are stretched to think in some new directions. First, thinking about purposes in the context of the system. Secondly, thinking about creating solutions and not on studying problems.

Uniqueness: Every problem is unique. You can’t just copy a solution from somewhere else. Take time to understand the context of the solution.

Purposes: Always and continually ask the purpose of solving the problem. Expand the purpose question as far as possible. Focusing on purposes within purposes will high light the uniqueness of the problem.

Solution-after-next: Find solutions today that achieve the focus purpose, based on what might be the solution after next. Working backwards from some ideal target solution can stimulate innovation and high-light larger purposes.

Systems: Understand the elements and dimensions that comprise a solution so you can determine in advance the complexities you must address and the actions you must take in implementation.

Limited Information Collection: Before gathering and analyzing extensive data determine what will be achieved from the data. “What do we need to know to accomplish our purpose” is a powerful question to focus data collection on the solution. The goal is not to become an expert on the problem, but to study the solution.

People Design: Let everyone affected by the solution to take part in the development. People are interested in exploring purposes and solutions-after-next. The people involved will also make sure the system is addressed and the critical details are attended to.

Betterment Timeline: As you are building today’s solution, build in and monitor a program of continual change. A sequence of purpose-directed solutions and knowledge of the solution-after-next are bridges to successful adoption and a better future.

Creative Solution Finding and Enterprise Agile

This model is interesting because it gives guidance on how to create strategically-aligned situation-specific solutions. This is very relevant to implementing Agile – whether in a small team or at any order of scaling. Combined, these principles provide some guidance for leading a company toward Big Agile.

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.

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.