Initial Agile Envisioning: Getting Going in the Right Direction

Agile teams, at least the disciplined ones, explicitly invest time in initiation activities. One of those activities is initial envisioning, collaborative high-level exploration of both stakeholder requirements and an architecture strategy to address those requirements. This envisioning effort is streamlined, producing just-barely good enough (JBGE) models. The goal is to do just enough up-front thinking to get their initiative going in the right direction.

Initial Envisioning Within The Agile Lifecycle

Envisioning can occur at any point in the life cycle. This article focuses on initial envisioning, which occurs early in the agile project life cycle, depicted in Figure 1. Initial envisioning occurs during the initiation phase, also known as Sprint 0, ideation, inception, or simply start up. The concept of a phase may seem to be “non agile,” but I prefer to focus on pragmatic concerns rather than purist concerns.

Figure 1. An Agile Project Lifecycle (click to enlarge).

Even when a team is organized as a long-standing product program, or initiative, there is still some form of initiation for that team. The point is that although Figure 1 depicts an agile project lifecycle, this concept is still applicable for non-project agile teams.

As you can see in Figure 2, which depicts a high level view of the initiation process, all of those activities are applicable to initiating any type of software initiative. It shows that there are two modeling aspects to initial envisioning, initial requirements envisioning and initial architecture envisioning. Initial planning could also be considered an aspect of initial envisioning although that is out of scope for this article given that our focus here is on modeling.

Figure 2. Activities during the initiation phase (click to enlarge).

Figure 3 depicts the Agile Model Driven Development (AMDD) lifecycle, which focuses on modeling and implementation issues. It also shows how initial envisioning is recommended before you get into any sort of evolutionary development, regardless of whether you are taking a project-oriented or product-oriented approach.

Figure 3. The AMDD Lifecycle (click to enlarge).

Initial Requirements Envisioning

The goal of initial requirements envisioning is to sufficiently explore the scope of your initiative. This includes identifying both what you were expected to accomplish as well as what you are not. The goal is not to create a detailed requirements model, although in a small number of situations that may be required. Typically, what you need right now is a high level vision of what is required of your team.

The potential artifacts that you will want to create to capture your initial requirements depends on the nature of the problem that you face. For example, an agile team that is building a phone app might choose to create a collection of user stories, some user interface (UI) sketches, a UI flow (wire frame) diagram, and a business vision canvas. A continuous data warehousing team might decide to create a collection of question stories, a high-level domain model, and a vision canvas. Different teams, taking on different problems, will create different artifacts. So in other words, it depends.

Initial Architecture Envisioning

The goal of initial architecture envisioning is to identify a viable architecture strategy for your initiative. Similarly, the goal is not to create a detailed architecture model, although once again in a small number of situations that may in fact be required. In most cases, you will simply need to create slim models, often whiteboard sketches, that capture your ideas.

As with requirements, the models that you create to capture your architecture strategy also depend on the nature of the problem that you face. For example, the agile app team we’ll likely create some type of free-form architecture diagram or perhaps a deployment diagram. The continuous data warehousing team, might create a deployment diagram and a logical flow diagram, as well as initiate the development of a taxonomy and metadata describing existing data sources.

Agile Envisioning in Practice

I have found the following advice to work well in practice:

Comprehensive envisioning. Ideally, explore the requirements, the architecture strategy, and the plan (including both schedule and finances), simultaneously. These three aspects affect each other, and a change in one may affect the other two, requiring trade-offs to be made.
Get an Obeya room. An Obeya room is a large room with lots of white board space. Obeya rooms are ideal when to get your stakeholders together physically to collaboratively model together. It enables you to capture several models, each on different parts of the whiteboard. Thus you are able to iterate easily between different views, evolving them in parallel as your understanding evolves.
Active stakeholder participation. Envisioning work is best performed in a collaborative and inclusive manner with your stakeholders as they are the ones who best know what they need.
Facilitate the modeling sessions. Your stakeholders are unlikely to have the requisite modeling skills for this. They will need the help of a facilitator to elicit and capture their needs.
Embrace change. Your stakeholders may change their minds at any point, requiring flexibility and patience on your part.
Expect to take several days. The amount of time required for initial envisioning varies based on your context. Very straightforward situations you may only require a few hours. I have personally been involved with very complex initiatives where we were able to perform initial envisioning within a week. This of course required significant planning to get the right people into the room when they were needed. The logistics of gaining access to stakeholders requires executive support in many organizations. To summarize, the “real work” can be done in hours or days, but organizational challenges can extend that period to many calendar weeks.

How Much Agile Envisioning?

It depends! Your context will determine the amount of envisioning that you need to do. For example, teams that face straightforward problems will need to do less than teams that face complex problems. My experience is that you need to do enough modeling so that you can answer the following questions:

What do stakeholders want? To answer this question, you need to do just enough initial requirements modeling. Your goal is to identify both what your team is to do and not to do. In other words, identify what is in and out of scope for your initiative.
How are we going to do that? To answer this question, you need to do just enough architecture modeling. Your goal is to identify a strategy that your team believes will work.
Can we safely get going on do so? To answer this question, both your team and your stakeholders must agree on the answers to the first two questions. And of course your team must be given adequate support to do so.

You are done when your models are just barely good enough (JBGE) to answer the questions above. The challenge is that JBGE is qualitative in nature. In other words, it depends on your situation. Figure 4 summarizes the factors that affect this decision. Factors such as complexity, risk, regulatory compliance, and an artifact culture (where people believe that more documentation is better) motivate you to do more modeling. Factors such as the skill and experience of the people you are producing the model for, the ease of change of what is being modeled, access to stakeholders who can answer your questions, the ease of collaboration and communication within your environment, and the likelihood of what you are modeling changing, all motivate you to do less modeling. These factors are described in detail in the article When is an Artifact Just Barely Good Enough (JBGE)?

Figure 4. When have you done enough envisioning? (click to enlarge)

Initial Agile Envisioning

In this article I have argued that the goal of initial agile envisioning is to explore the initial scope of, and to identify a viable architecture strategy for, a software development initiative. To do this, you will create a collection of agile models that are appropriate for your context. This modeling effort will enable you to answer the questions “What are you going to do?” and “How are you going to do it?” The answer to these two questions, along with the answers to “How much will this cost?” and “How long will it take?” are required to secure funding and support for the rest of the initiative. Furthermore, being able to answer these questions enables your team to get going in the right direction from the beginning. This increases the chance that your team will succeed at whatever mission it has taken on.