Phase: Envision

< Day Day Up >

Phase: Envision It is rare to discover anything in the realm of human behavior that occurs with great consistency.… Therefore, it was surprising to find that in every case, without exception, when an effectively functioning team was identified, it was described by the respondent as having a clear understanding of its objective (Larson and LaFasto 1989). It's the vision thing again! Visioning and goal setting have been identified time after time as key ingredients of project, and general management, success. But how does this need for a clear vision jibe with the exploratory nature of product development, which we have just gone to great lengths to describe as volatile and fuzzy? This apparent dichotomy is resolved by the fact that while the details of requirements and design can be volatile and fuzzy, the overarching business goal or product vision must be clear. In fact two critical aspects of a vision are clarity and an elevating goal that makes a difference and conveys a sense of urgency to the project (Larson and LaFasto 1989). Absent a clear vision, the exploratory nature of an agile project will cause it to spin off into endless experimentation. A clear vision must bound exploration. If everyone knows that creating a clear, compelling vision is so critical to project success, then why do so many teams suffer from lack of vision? The answer is that creating a clear, compelling vision is hard�it takes work, and it takes leadership. In the process of developing a new product there are so many options that creating a clear path forward can be daunting. This is one activity in which effective leaders lead�they help cut through the ambiguity and confusion to create an effective vision. Compounding the problem is the fact that there is no fixed rule for creating a good vision statement. It's one of those "I'll know it when I see it, but I can't describe it" phenomena, in part because the essence of a good vision is the leader's articulation of it. The purpose of the envisioning phase is to clearly identify what is to be done and how the work is to be accomplished. Specifically, this phase answers the following questions: What is the customer's product vision? What is the scope of the project and its constraints (including the business case)? Who are the right participants to include in the project community? How will the team deliver the product (approach)? For small projects, much if not most of the work of the Envision and Speculate phases can be accomplished in a single "kickoff" week. For larger projects, requirements gathering, additional training, resource procurement, and architectural work may take longer and can be included in an Iteration 0 (see Chapter 6). For large- to medium-sized projects there is normally a debate and discussion period required in order to obtain agreement about the product vision. During the Envision phase the vision constantly evolves based on new information. After the Envision phase it needs to be reviewed periodically to ensure that the team continues to understand the vision. Depending upon the situation, the information available to an Envision phase will vary, but the key outputs remain constant: product scope, project objectives and constraints, project participation, and project approach. While there are other important aspects of initiating a project, such as budgets, staff organization, and reporting needs, without a commonly held vision the project will falter. Envisioning begins in whatever feasibility study initiates the project. Because the APM model as shown is not a portfolio or total product lifecycle model, it uses information provided by the feasibility study and extends it. Many companies conduct feasibility and marketing studies prior to initiating development projects, while others use only brief project requests. Figure 5.1 depicts the evolution of a project plan�from vision, to scope, to features�utilizing three simple but powerful practices: the vision box, the project data sheet, and the iterative feature plan (accomplished in the Speculate phase). Each of these artifacts is simple in concept, powerful, and low ceremony (informal), and each operates on the principle of limited "real estate." The vision box exercise forces the team to condense information about a product vision onto the limited space of a box. The project data sheet forces the team to condense key project scope and constraint information into a single page. Feature cards force the team to condense the key information about a feature onto a single 4x6-inch index card. Limiting the space in which we record information requires focus and selection�it demands collaboration and thinking, and it compels the team to make effective tradeoffs. Figure 5.1. Evolution of a Project Plan In the Envision and Speculate phases of APM it is particularly important to remember that: The team members should constantly ask the question, "What is the barely sufficient process and documentation that we need?" All the practices related to "how" a team delivers are subject to tailoring and adaptation to improve performance as the project progresses. The project community and its processes and practices will evolve. For example, as the product architecture evolves, the team structure may need to evolve also�nothing is fixed. The practices explained in this chapter fall into four categories: visions for product, project, community, and approach (see Figure 5.2).[1] [1] For additional information on project envisioning, see (Highsmith 2000), Chapter 4. Figure 5.2. Envision Phase Practices Product Vision Product vision box and elevator test statement Product architecture and guiding principles Project Scope (Objectives and Constraints) Project data sheet Project Community Get the right people Participant identification Customer team-development team interface Approach Process and practice tailoring

< Day Day Up >