In Agile, many techniques can be used to improve different aspects of the processes. Many of them may on the surface appear to be similar in purpose. But when you look closer, there may be a distinction that favors one over another for specific situations.
So, how do we determine which technique is appropriate to address the specific issues we are seeing?
When deciding which technique to use, the three factors I look at are the Horizon, the Audience, and the Context.
In other articles, I’ve talked about the Three Horizons – Strategy, Initiative, and Delivery. Understanding which Horizon we are dealing with impacts which set of techniques is available.
Some of the usefulness of some techniques spans across all Horizons. Others may be in two or only one. Appropriate understanding requires understanding the purpose of each Horizon, remembering that a Horizon is not so much a time frame as it is a level of decision making. Decisions can impact an initiative from any of the Horizons.
For example, if a project is actively being developed, the Strategy Horizon can realize there needs to be a change in direction. Just because we are actively delivering the product does not mean Strategy has ended. In Agile, all three Horizons can be active simultaneously.
And that feedback can go both up and down through the Horizons. So understanding which techniques are appropriate to each decision-making level – to each Horizon – is essential.
Below are 4 charts which identify the various techniques as well as which source they are discussed – the Agile Extension or the BABOK Guide
Next is the Audience. Answering the question of “Who,” the Audience can be condensed into two broad groups:
- Part of the team
- External to the team
So, Who is the Team?
In Agile, the team is considered to be those involved in identifying and delivering a solution to a problem. The team may be further broken down to those working at a specific Horizon – for example, those working with organizational strategy are part of the team, but they are not delivering the product. One would be the Strategy Team, the other the Delivery Team. But for our purposes, that distinction is covered when you consider the Horizon in choosing a technique.
Those that are external to the team is everyone else. External to the team can include individuals such as Customers, Subject Matter Experts, Vendors, Regulators. These would be anyone who is both interested in the success of an initiative, but not involved in bringing the project to life. And they may or may not be part of the organization.
Now we are getting to the heart of the matter – why do we need this technique. Context is another way of asking, “What is the purpose?” or “What do I hope to achieve?” It is the “Why” of the decision process.
There are five categories of Context.
- Process Analysis
- Product Management or Refinement
- Requirements Management
- Understanding Your Customer
So let’s look at each of these.
Techniques that fall into the Communication context when, not surprisingly, the point is to communicate information. The receiver of the communication is determined by the Audience, which I mentioned above.
Some examples of Communication techniques would be things like Planning Workshops, Portfolio Kanban, Visioning, Retrospectives, Backlog Refinement, and Reviews.
Process Analysis involves looking for ways to improve processes. This may be processes involving the team, or in the solution itself.
For example, a Process Analysis may find gaps in the solution.
Another example, Process Analysis may reveal that the team is getting bogged down at a certain point in delivery. Perhaps the team needs to adjust to prevent that from continuing.
Some examples of techniques useful for Process Analysis include Value Stream Mapping and Impact Mapping.
Product Management or Refinement
Here we are concerned with delivery schedules or other items associated with defining the product. These answer questions like:
- What is necessary?
- When do we make a decision?
- How does this align with our objectives?
- When will features be delivered?
Examples include Minimal Viable Product, Product Roadmap, Purpose Alignment Model, Real Options, and Kano Analysis.
For Requirements Management, the concern isn’t the requirements themselves so much as how they are collected, sequenced, reviewed, prioritized, or refined. For analysts involved in Agile, this can be a large portion of the work.
Several examples of this context include Relative Estimation, User Stories, Job Stories, Spikes, Story Elaboration, Story Decomposition, Story Mapping, and Behavior Driven Development.
Understanding Your Customer
The context of Understanding Your Customer involves techniques in which details about the usage or motivations can be conveyed to the team. Many times, understanding the motivations can have an impact on the final design.
Some examples include Personas, Storyboarding and Value Modelling.