On a recent Digital Focus client engagement, the IT group was struggling with an enormous backlog of development work, including bug fixes, enhancements, and new features. While the backlog items had already been prioritized by the business owners, neither the budget nor the IT team's capacity were sufficient to address even the quot;criticalquot; items. Furthermore, the problem had been left completely for IT to solve - no representative from the business side was actively discussing the issues, working behind the scenes to help, or pushing for more money to support new development.
This is not uncommon. In every organization the business, wish list far exceeds the actual capacity of the development organization. Creating an environment where the business and IT staff jointly own the problem and work effectively to prioritize their efforts is the only way for the organization to effectively employ IT resources to maximize value. Agile practices provide a framework {sidebar id=1} to establish and build the trusting relationship required for a partnership to blossom.

Barriers to Business Support
Building a strong IT/business partnership can be difficult. When introducing agile to an organization, it is often the business staff that is most resistant. Over the years, we have trained our business partners to think and behave in a manner that is inconsistent with agile development. For the last 20 years we have explained that development:

• Is too complicated for a novice to understand (therefore, the business users#39; role is only to define what they want and IT will decide how those needs are met);
• Must be completely defined up front since any change will be costly and difficult (therefore, the business users must anticipate every potential use of the application because they only get one shot); and
• Always takes longer than expected and delivers a reduced scope (therefore the business users should ask for more than they needs and sooner than they really need it).

Each of these behaviors are logical responses to a development process that demands getting it right up front, defers risk to the end, and provides little visibility into the process. Given that this has been the predominant approach to software development for the last 20 years; it is no surprise that these behaviors form the basis of a typical IT/Business relationship.

Another key barrier to overcome is the misconception surrounding agile development's quot;variable scopequot;approach. Business owners interpret that as not requiring IT to commit to providing necessary functionality or to meet a required date. Finally, the issue of lack of trust between business and IT must be broached, given that trust is a crucial underpinning of the agile approach.

The agile evangelist in such a business must overcome and ultimately change these behaviors. He must convince the business staff that it is both their responsibility and in their best interest to change the development process.

Gaining Business Buy-in to Agile Development
Fortunately, agile approaches provide the means to rapidly establish the IT/business partnership. The key is to focus on the ways to build trust from the start. At Digital Focus, we have found four key steps that help bridge the IT-Business divide:

1. Define the vision.
2. Let business own the release plan.
3. Consistently deliver - particularly in early iterations.
4. Respect the time of the business owner.

Define the vision
The first step in building trust is to ensure that both the IT and business staff have a common vision of what the application will be like when it is complete. The business counterparts on a project need to have confidence that the IT folks understand their goals, objectives, and timeframes. We have found that outlining the vision in terms of user roles and high-level user functions is very helpful. When appropriate, visualizing the functionality in the form of a static prototype is a powerful tool to prove to business owners that the IT people understand the needs.

Many agile approaches fail to focus on the importance of this up front conversation. There is a valid fear that it too closely resembles an up-front requirements phase. To ensure it does not become one, the team must:

• Rapidly push through this analysis, focusing on high-level functionality and avoiding becoming mired in the details;
• Constantly reinforce that the prototype is a vision and that the first release will likely contain a subset of the functionality discussed; and
• Gain enough of an understanding that a first release timeframe and high-level scope can be articulated during release planning later.

The duration of this activity depends on the complexity of the application and the willingness of the business owners to accept change during development. When initially building the trust relationship, more time is necessary before the business owners are comfortable that IT has heard them, adequately understands their needs, and can build a release plan that is believable. But two to three weeks should be sufficient in most cases.

Let the business users own the release plan
All agile approaches emphasize that a business owner or product manager is responsible for determining the specific functionality of a release. In practice, we have seen too many times where an IT project manager develops the initial plan and then explains the plan to the business constituents, including what is in and out of scope for the release. The project manager then leaves with the mistaken belief that she has sufficient buy-in to move forward. This type of plan is still IT's plan.

We have found it is critical to involve the business users actively in developing the release plan. IT provides the planning velocity for each iteration and sizes each story, but it is the business users who physically place the cards into iterations and build the plan an iteration at a time. (While this is best done in a room with cards, using tools such as cardmeeting.com can enable the same type of interaction for remote business users.) By having the business staff build the initial release plan, they begin to understand the effort and timelines required to develop the application and gain visibility and confidence. Furthermore, it becomes obvious to them how their decisions impact the project timeline. All of this builds trust.

Consistently deliver, particularly in early iterations
We all understand that the best indicator of the amount of work that the team is able to accomplish is by looking at what the team has accomplished in the past. However, when first introducing agile there is no past to base velocity on, and so the team guesstimates and in pure agile fashion adjusts based on performance.

Keep in mind, though, that in an environment where the team is trying to establish a trusting relationship with the business owner, it is very important that the team delivers the stories committed to in the early iterations. Missing the first couple iterations reinforces the traditional belief that IT won't deliver what it says it will. Therefore, the team needs to make an extra effort to hit its velocity estimates if at all possible–even if it requires some "stretching" for an iteration. Consistently delivering in each iteration what the team said it would deliver is the fastest way to ensure the initial trust established during release planning begins becomes entrenched. Once trust is built, the team can focus on ensuring that the velocity reflects a truly sustainable pace.

Respect the time of the business owners
The final point is not specific to agile development, but agile practices provide good guidance on how to do this. Agile requires active involvement of the business owners throughout the development process. Optimally, one or more business users would be in the team room with the team. In reality this is rarely the case. Therefore, teams use business analysts or other team members to serve as proxies for the business owners, setting up specific processes and meetings to ensure that functionality details are captured. Good facilitation is important in these meetings to make sure that the time spent with the real business users has clear objectives and is efficient.

Continuing to building the trust relationship is crucial for agile approaches to be effective. Leveraging the iteration retrospective to proactively ensure that the process is working for the development team and the business partner is a good way to ensure the partnership grows. Understanding the business staff's needs and creatively changing the process to help the business owners remain involved and committed can ensure that the partnership will flourish a long time.

Conclusion
The years of missed dates, fights over scope, and inability to adjust to changing business demands has broken the trust relationship between IT and business. To effectively sell agile to business leaders requires a working partnership between the IT and business staff. Focusing on rebuilding trust at the start of a project is therefore the key to selling agile to the business, and agile practices are good mechanisms to do that. The good news is that the business leaders will be strong advocates of agile development once they see it work for them. 

About the Author
Dave leads the agile practice for Digital Focus. Dave brings over 15 years of experience in organizational change management and project management. For the past four years, Dave has served as an agile coach and change leader in helping Digital Focus and its clients adopt agile practices. Dave specializes in helping client leadership adopt a different way of thinking about IT, focusing on delivering continuous value by working in short cycles that maximize ROI.