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.

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.

In Leading Change, Kotter talks about four aspects that must exist for a successful change program: A Compelling Story – because employees must see the point of the change and agree with it; Role Modeling – because employees must see the colleagues they admire behaving in the new way, Reinforcing Mechanisms – because systems, processes, and incentives must be in line with the new behavior, and Capability Building – because employees must have the skills required to make the desired changes.

So many change management programs go about telling a compelling story about how great the business will be, they spend time enrolling champions of the cause and promote their successes, they align financial compensation and metrics with the change, and they launch massive training programs to support the change. And yet, in most instances, beneficial change is still painful and slow.

Resistance to Change isn’t Rational

That is because resistance to change is almost never rational. People are smart and they understand the benefit to the business immediately. What we have found is that resistance to change doesn’t have its roots in a lack of understanding regarding benefits. Resistance has its roots in fear, embarrassment, and loss.  These have their roots in people’s innate desire to be successful. They are probably built-in very deeply to our survival mechanisms from when being successful meant staying alive. For most of us, these deep motivators extend beyond ourselves to include the people we feel responsible for – our tribes. Our tribes can include our teams, our families, the company, our customers, and society.

Fear deals with uncertainty about the future. A person may realize that there is potential to do things better than they are currently doing it. But if the way they are doing it isn’t getting them fired and they aren’t completely certain they can be at least as successful in a new way, they will resist the change until their fear is addressed.

The important thing about addressing fear is that fear is in the perspective of the person who is facing the change that matters, not the people initiating the change. Historically, we keep doing what we have always done because it kept us alive.

Embarrassment deals with admitting that the way we have done things isn’t the best way to do it. People have a very strong drive to be right and to be appreciated. When you point out that they aren’t doing things the best way, they tend to become defensive. You don’t understand how things got that way. It sure is easy to come in after the fact and point out the problems. You must think they are stupid if you think they don’t understand the flaws in how they do work.

Embarrassment is dealt with by letting people tell their story. Let them know it is clear that they made the best choices they could over time. Its ok that things got the way they are because the got the way they are.

Loss is much broader. People have made an investment into developing the competence that they have been rewarded for and that gives them influence. Any of these points can be an emotional sticking point, loss of investment, competence, rewards, or influence.

Explaining how things will be better for the business on the new .NET platform doesn’t help the guy who spent the last 20 years becoming the absolute expert in the COBOL application. Explaining the focusing benefits of social marketing techniques doesn’t make the sales person who spent the last 20 years developing relationship more valuable. The manager who has thrived in chaos and been rewarded for it will resist the effort to put in stabilize the environment.

Everyone has Their Own Story

When we change the way we do things, we can’t replace the investment made by individuals in developing the competence that has led to reward and influence. We pull that out from under them. Loss is the most difficult challenge to deal with. We can commit to supporting a new investment, although it is difficult to replace 20 years of experience. People want to be valued. Try treating them with a great deal of respect and recognition for what they have accomplished. This will help with the transition, but won’t necessarily set them up for a complimentary level of success in the new way of things.

The bottom line is that overcoming resistance to change is critical to the success of most strategic changes. Typical change management approaches teach us to communicate, communicate, and communication again. But, notice how of the sources of resistance are all at a personal level. Explaining how the change will benefit the business, or the manager, or even the customer isn’t sufficient.

Next time you are facing resistance to change, don’t push – listen. The person resisting understands the benefit to the business. It is fear, embarrassment, or loss that is motivating the resistance. Often it is a combination. Often their fear, embarrassment, or loss extends beyond them to what they perceive as their tribe. Spending time understanding and addressing resistance at its root may seem like an unnecessary investment. However, the investment is almost always less than the cost of the resistance itself.

This article is an updated version of an April 2007 Synaptus entry. I was inspired to update and reprint this post based on this McKinsey Quarterly newsletter.

The McKinsey Quarterly-The irrational side of change management