You’ve got to think about big things while you’re doing small things, so that all the small things go in the right direction.

–Alvin Toffler

Vision Abstract

Few question the benefits of Lean|Agile’s focus on near term deliverables. Deferring decisions until the last responsible moment, limiting work in process, eschewing detailed requirements specifications, future proof architectures, untested code, detailed longer term plans, etc., and focusing on immediate value delivery are hallmarks of effective Agile teams. There is no substitute for focus and bias for action.

However, in the context of larger programs and the enterprises portfolio, we also recognize that every developer and tester makes decisions each day on what the software is to do now, and in so doing, also what will be easy—or not so easy—to do in the future. In this way, they ultimately determine both the effectiveness of the current solution and the economics of developing future solutions. To this end, there is no substitute for keeping all team members continuously apprised of the solution vision, for that is why they do what they do. Continuously communicating this vision to all team members is critical to creating a shared understanding of the programs goals and objectives, especially as those ideals evolve due to ever-shifting market needs and business drivers. In other words, “you’ve got to think about the big things ………….. so that all the small things go in the right direction”.

Details

The Vision describes the stakeholders view of the solution to be developed, in terms of stakeholders needs and proposed features. It captures the essence of the envisaged solution in the form of high-level features, non-functional requirements and design constraints, and provides an overview of the system to be developed. It describes the purpose for the program and provides the boundaries against which all future stories and decisions should be based.

Inputs to the Vision

In SAFe, the responsibility for the Vision (and Roadmap) lies with Product Management (or the equivalent business analyst/program content authority in your enterprise). They are uniquely empowered to synthesize all the inputs, integrate them into a holistic and cohesive vision, and convert that vision into prioritized Features on the Program Backlog, and plan the Roadmap of feature delivery. The primary sources of these inputs are highlighted in Figure 1. Each is described in the paragraphs below.

Figure 1 Sources of Vision Input

Investment Theme Driven Strategy. The value stream is derived/sponsored by the Investment Theme it represents. The context and purpose of that theme embody the strategy, which drives the primary vision elements.
Portfolio Epics. Cross cutting epics from the Portfolio Backlog also contribute to the features of vision. These are prioritized against other features with WSJF.
Customer/Value Stream Feedback. While there is always a directed strategy to serve a market or customer segment in play as driven by the investment themes and Portfolio Vision, this strategy is aided by fast and intimate customer feedback; just the kind of feedback that agile is optimized to elicit.
Architectural Features. Continuous evolution of Architectural Runway is necessary to support both current and near term feature requirements. Guidance for this is the responsibility of the System Architect, in collaboration with the Agile Teams and Product Management.
Team Inputs. And lest we forget the obvious, the foremost domain experts in the area of interest are the development teams themselves. Through the Product Owner, teams continuously communicate emerging requirements and opportunities back into the program vision.

Vision Representation

When it comes to representing the vision, in References [1] and [2], we’ve highlighted a number of forms of lighter-weight vision representation, including lightweight business case, preliminary data sheet, and RUP-like vision document formats. In our experience, however, these forms are not all that prevalent, even in effective agile programs. After all, they are not easy to develop, can be hard to maintain, and are, by agile definition, virtually always out of date. Instead, in their place, we more typically see what we would describe as rolling-wave vision briefings.

Rolling-Wave Vision Briefings

Rolling Wave Vision Briefings are routine, periodic, presentations of the short and longer-term solution goals. This is done face to face with the teams, on the cadence of the programs Agile Release Train PSI/Release Planning cycle. This large, typically face-to-face planning session brings most all the participants together every 8-12 weeks for two days to plan the upcoming PSI/ Release. In the standard agenda for such sessions, those responsible for the longer-term vision (typically line of business owners, product line managers, etc.) describe the big, future waves (the long, dramatic view) view—that is, the current competitive market situation, strengths, weaknesses, opportunities, and threats (SWOT). Those responsible for the nearer term releases (typically product and program managers, and product owners) describe the shorter waves (those objectives for the next 1-2 PSIs or releases) the teams will face next. This is often expressed simply in the form of “the Top Ten Features” on the current program backlog. In addition, since systems architecture is a first class citizen in SAFe, a System Architect typically presents the architectural roadmap so that current and future Architectural Features can be understood and implemented by the Agile Teams.

This combination of longer-term vision and shorter-term objectives (with the appropriate dash of systems architecture) can provide just about the right amount of vision necessary to optimize the decisions that agile teams make every day, within every sprint. For more about the mechanics and presentation of vision, see PSI/Release Planning.

Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.

Last update 24 March, 2013