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