Agile Solutions Are About Benefits, Not Process

Agile software development and the Scrum process are based upon collaboration — creating a tight union between the technical and business teams.

This appears to be a simple and obvious approach but it turns out to be one of the most difficult aspects of agile and Scrum development. Some agile/Scrum projects fail simply because the business would not actively participate.

What is active business participation?

To be actively engaged, the business must appoint a “Product Owner” (PO). That person must attend the daily stand-up meetings and help the team make decisions.

The PO is a liaison between the technical folks and the business folks. The PO should be empowered to make decisions. For difficult or complex questions, the PO will take the issue to the stakeholders and gain consensus.

It is not an easy role to fill but is critically important to a fast-paced, agile process.

The other critical area of business participation is evaluating the frequent software deliveries by the technical team. As often as every week, the technical team may ask the business users to evaluate the software and provide feedback.

While the PO can perform much of the evaluation, it is important get feedback from multiple end users to ensure that the software does what the business really needs.

Agile development is not agile business

Problems begin when the business team refuses to appoint a PO or they appoint one who is clueless. They may ask that the technical “Business Analyst” represent their interests to avoid having to assign someone.

The business may also fail to actively participate in the software evaluations. Their attitude may be “just let us know when the software is done”.

When these scenarios play out, you end up with a process that is agile for the development team and may result in better software — technically. However, it’s not agile for the business team and the end result may not meet their needs.

Agile is not the problem

Are agile development and the Scrum process to blame? Is something wrong with the whole concept of being agile?

Winning people over and getting them fully engaged are not intellectual problems. They are emotional ones. If the technical team hasn’t fully engaged the business team, it’s because the technical team has failed to create a powerful vision of change.

The business team will always react apprehensively to change. They will question the need for change and resist it. They will also resist taking on more work and responsibility. They have enough work to do — a business to run. They are not in the business of developing software. That’s your job!

Create positive emotion around the new software

To get passed this resistance, you need to create a vision for a new and better way of doing business that is powerful enough to overcome negative attitudes AND generate positive participation.

Sales people will tell you that buyers assess products intellectually but make buying decisions emotionally. This applies to software development as well. You need to create an emotional attachment to the software.

I can hear all the intellectuals (aka, software developers) reading this and thinking “you must be joking”. For us (yes, that includes me) intellectuals, this is a tough concept to grasp and even tougher to execute.

Think about it. Do you make buying decisions based solely on technical details? Be honest. Do you have an emotional attachment to Apple, Linux, Microsoft, Sony, Ford, GM, Google, or some other brand? I’ll bet you do. Marketers depend on it.

Come up with an agile pitch

Do yourself a favor. For your next agile project, spend some time brainstorming all the benefits the business will derive from the end result AND from actively participating in the process. Then, sell them.

Pitch the benefits. Build an emotional attachment to the effort. If you have trouble doing this, find someone on theĀ  business side to help. (You have an executive sponsor, right?) Here are 10 business benefits to get you started:

  • Cost Reduction / Avoidance
  • Increased Revenue
  • Productivity Gains
  • Service Level Improvements
  • Enhanced Product Quality
  • Marketplace Differentiation
  • Better / Faster Decision-making
  • Faster Customer Issue Resolution
  • Competitive Advantage
  • Regulatory Compliance

Like it or not, you need to sell the solution. Don’t sell agile; don’t sell Scrum. Sell the solution. Agile software development and the Scrum process are great tools but they can’t do it all. You need to sell the benefits.

Updated: February 6, 2011 — 9:43 pm