Category: Initiative Horizon

Techniques: Real Options

Techniques: Real Options

Real Options focuses decision makers attention on the items that need to be decided now, at the last responsible moment.  By focusing on the appropriate time for making a decision, items which are not needed can be delayed making the decision process much simpler.

Think of it this way, to be agile, we need to have flexibility.  However, the criticism is that with flexibility comes chaos. How can we bring in the latest information and use it for decisions in an orderly way – without disrupting everything we’ve been planning? We need a way to make a decision based on a logical framework, and Real Options is one of the techniques that has been developed to do just that.

It starts with the question, “What is the latest point at which a decision can be made?”  Anything before that means we may have missed important late breaking information.  Anything after that, and the decision is made for us.

In other words, there is a valid reason for Procrastination.

Elements

Agile Extension to the BABOK®  Guide – section 7.12

It’s a little different from how we normally think about problems and decisions.

First, An option is only an option if it can expire.  Otherwise there’s never a reason to decide.  So by definition, options have a point where they can expire.  That can be a point in time, or an event that triggers a decision point.  So long as it can expire.

Next, if this option is taken, one or more other options are excluded.  This is a choice of one out of more than one, with one choice winning.  If a competing option is still available after the choice, then it was not paired with the right option.  In other words, it wasn’t understood correctly.

If there’s a “cannot” phrase associated with the option, then it isn’t an option either.  Options are only options if they can be put in place.  If there’s a reason it cannot, then it isn’t an option.

That sounds intuitively true when you think about it.  But we don’t usually think about it that rigorously.

In addition, options must exist within organizational commitments, such as standard tools, acceptance criteria and delivery.

As mentioned, they must have a means or time when they expire, after which the choice is made for you instead of by you.

The earliest option defines the end date for the collection of information in order to maximize the ability to make a decision.

Description

Agile Extension to the BABOK®  Guide – section 7.12

There are 3 statements that are important to remember, highlighted in the Process section here.

  • Options have value
  • Options Expire
  • Never commit early unless you know why And this belongs to the Product Management or Refinement context, directed toward the Internal Team.

Usage Considerations

Agile Extension to the BABOK®  Guide – section 7.12

As we stated at the beginning, Real Options simplifies decision making by allowing the decision-maker to focus on decisions that are needed now, instead of the entire project upfront.  This removes complexity and allows decisions to be prioritized based on events, time, or other constraints.

But it isn’t the most intuitive way to think about decisions, which means – though it simplifies the decision itself, the process supporting this technique is not so simple.

Techniques: Planning Workshop

I’ve heard many people say that Agile is against planning. If you’ve read many of my articles, you’ve probably seen me say something like, “It’s not that planning doesn’t occur in Agile. It’s just done differently.” The question is how.

Instead of laying out every detail upfront and measuring against that plan, Agile plans in chunks as time goes along. And this article is going to talk about how that is done – in the Planning Workshop.

Whether you are using Scrum, DevOps, Lean, or some other flavor of Agile, the Planning Workshop is used to communicate what can be delivered in a time frame.

With a title like Planning Workshop, there might be a tendency to think this is a session for the client. Instead, the goal is to determine what to work on next.

Elements

There are 5 elements to the Planning Workshop.

  • Input to the Workshop is an Estimated and Ordered Backlog. 
  • The team velocity, based on previous experience and projected schedules.
  • The goal to be achieved. Often this is an outgrowth of the Ordered Backlog.
  • There is the process of selecting the items from the backlog.  This can include bug fixes, research (Spikes), or any Product Backlog Item.
  • Finally – task planning, where the team breaks down their work and makes individual assignments.

Some important things to note. Most people think of Planning Workshops in the Development Horizon. That’s Sprint Planning, not a Planning Workshop. The Workshops are for the Strategic or Initiative Horizons.

Leading up to the Planning Workshop, no matter which Horizon, the team has estimated the Features in the backlog. 

Also prior to the Planning Workshop, the client or their representative has reviewed the backlog. We know this because it is ordered. This is a session for the Strategy or Initiative teams to decide what can be done in their next cycle, and the results to be communicated with the client.

Description

Planning Workshops are a critical piece to most Agile frameworks.  They are utilized to align initiatives with organizational goals at the strategy horizon or to decide prioritization and sequencing at the Initiative horizon.  Here is where we align features within releases.

Planning workshops determine the intended goal and dates needed, clarifying priorities and details about the features requested.  Once that is understood, the team discusses how to complete the work.

The context is Communications and the Audience is Internal Teams.

Usage Considerations

Some strengths of the Planning Workshop include:

  • Frequent communication
  • Can involve all stakeholders for guidance
  • Because it is focused on a small set of the overall project, it is easier to understand.

Limitations include:

  • The amount of time required to convey a proper understanding
  • How lack of understanding can affect results

Techniques: Kano Analysis

When looking to develop a marketable product, one of the first questions should be how to determine features that will distinguish the product from others. Kano Analysis is how those market movers are found. But more than that, it helps recognize which features are essential to gain customer satisfaction.

The point of Kano Analysis is to determine what will drive market demand in a product.  One thing that is interesting about Kano is that it isn’t a one time thing because the results shift over time.  Like most things in Agile, revisiting previous results can lead you to finding a shift in what drives vs what is expected vs what you should avoid.

Kano Analysis Graph

Here’s the grid for Kano Analysis.  On one axis is the Degree of Achievement.  The other is Customer Satisfaction.  So Kano measures things in 3 attributes:

Kano Attributes

  • Excitement – The more of this you do, the more excited customers get along an exponential curve.  These are the game changers
  • Performance – These are things that go along a linear curve.  People expect to see these attributes.
  • Threshold – These are things that don’t get people excited.  But if you don’t have them, they get disappointed.  Again, it is an exponential curve, but it flattens out as you Achieve it.  These are assumed without mention sometimes, and are absolutely necessary.

Additional Elements

There is a 4th characteristic called “Indifferent” Addressing these would be seen as wasteful.  They might be viewed as a negative – a downward arrow.  Kano doesn’t show these.

To determine which of these 3 dimensions a capability belongs involves a survey. On a 5 point scale 2 questions.  The Functional form question – how do you feel if this is present.  And the Dysfunctional form – How do you feel if it is not present.

The 5 point scale is shown ranging from “I like it that way” to “I dislike it that way.”

The answers are put on a “Kano Analysis Questions Grid” which I’ll show you in a minute.  And from there we can see what builds along the 4 characteristics we mentioned earlier.

Kano Analysis Grid

So if you’ve looked at a sample of several surveys, you will see a pattern on how the respondents like or dislike a feature.  For example, if most of the answers fit into Functional Expect and Dysfunctional Dislike – That would mean this feature is a T – Threshold.

If it is functional Like and dysfunctional Expect – that means they DON’T expect it (it is a dysfunctional expect), but they do Like it.  They’ve not seen this often, but they want it.  These are the big market movers.  If it is a Dysfunctional Neutral or Live With, these are still on the Excitement curve, but perhaps not as strongly.

You can see, this is a very powerful market analysis tool.

Description

Here is the Kano Analysis description.  We’ve covered this pretty well but I want to highlight the Context and Audience.

This is in the Product Management or Refinement context because we will use this technique to determine what to include or exclude from the product, as well as what has the highest priority.

And since the surveys are from External Stakeholders, this can be a great communication tool to find out from them what is desired, and communicate what we are going to address first.

Usage Considerations

One thing to highlight is, this technique is not to be used in a vacuum.  There can be other factors that determine priority.

Another thing is today’s perceptions may shift over time as features become more commonly accepted.  So the phrase “strike while the iron is hot” may be applied to the findings of Kano, meaning act while you can get ahead of the competition.

Announcing – AAC Certification Course on Udemy

Announcing – AAC Certification Course on Udemy

Hello everyone,
If you’ve not seen my announcement on LinkedIn, I have been very busy developing a course called Preparing for the Agile Analysis Certification Exam. It has been published on the Udemy platform, so it is available to everyone. This is a self-paced version of the course I have taught to Business Analysts across the US in association with the Bluegrass chapter of IIBA.

This covers the entirety of the Agile Extension to the BABOK Guide with over 3-1/2 hours of videos and several quizzes. The quizzes are intended to help foster the “Agile Mindset” and help you grow in understanding of the concepts presented in the Agile Extension.

If you are interested in learning more about Agile, becoming certified as an Agile Analyst, are curious about whether there is a career path for Agile Analysts, or just need some ideas on how to improve your projects – this is a great course to cover everything.

 

Goals of Agile Analysis at the Initiative Horizon

From the Strategy Horizon, we understand the overall purpose of an initiative and its intended impact. But there is a lot that remains undetermined at this point. The initiative may have the organization’s backing, but that doesn’t define exactly how it will work, what resources are involved, or how much it will cost. The role of the Initiative Horizon is to fill in those gaps, report back to the Strategy Horizon for decisions to continue or end research, and potentially provide the requirements to the Delivery Horizon.

So, look at this in more depth.

Identify Solution Options

Agile Extension to the BABOK®  Guide – section 5.3.2

One of the primary functions of the Initiative Horizon is to identify options that can potentially meet the organizational need determined by the Strategy Horizon. Implied in this is that there are options – more than one – which have that potential.

In determining these options, a clear understanding of the Strategy Horizon’s intended purpose will have to be established. If that has not happened, the analyst will gain clarification from the decision-makers in the Strategy Horizon. To eventually bring the desired results, clear and measurable objectives are communicated and evaluated here.

We need to consider “what is the shared understanding?” and “what are we assuming?” For example, one assumption may be that there is an affordable, workable solution. The analyst will need to discover if those assumptions are correct or not. If not, then that option will cease to be considered, and that result communicated to decision-makers in the Strategy Horizon.

Other considerations include “What could cause the project to fail, a delay, or a limited function?” To address this, the analyst needs to understand from a high level, what this optional solution does, and what constraints would make it not a viable solution. For example, a vendor product may meet the need, but it may not work in our environment.

Identify Components

Agile Extension to the BABOK®  Guide – section 5.3.4

Another element of the Initiative Horizon is identifying the components needed by the stakeholders and collecting information about its effect on the need, costs, and constraints. Collect enough detail to make informed decisions without wasting effort by going too deep.

The components are something that is reviewed and revised periodically though the duration of the initiative. Also, the components may be identified for all of the options, not just the one eventually chosen. This is because part of the decision will involve which features are included and how much effort those features require.

Size of Items

To determine the size of the items requires that the components are identified. These will often be referred to as Features. Each component needs an approximate size reflecting the expected work effort involved. At this point, it is a very high-level estimate.

Prioritize Components

Agile Extension to the BABOK®  Guide – section 5.3.5

Agile Extension to the BABOK® Guide – section 5.3.5

With those components identified, we need to determine the priorities and sequence components. This will be revisited often and influenced by feedback both from Delivery and Strategy

Prioritization can be impacted by several factors, such as the impact of the feature, cost, how the project is progressing, multiple levels of feedback, and others.

Features may be prioritized for options before a specific solution is chosen because the scheduling of resources required to bring prospects to reality will need to be discussed. Schedule constraints could tip the scales of one option over another.

Recommendation

Agile Extension to the BABOK®  Guide – section 5.3.3

In recommending an option, a simple way of looking at it is, “Which option gives the most for the least and still meets the need and constraints?” To decide that, we don’t need to know everything, but we need to know enough. And since we’re evaluating multiple options, we need to be consistent in what we use to make the decision.

To make the recommendation, confirm that our assumptions are valid. These could be organizational assumptions or assumptions about a 3rd party entity or product. We will need to see:

  • How difficult is it to do what this option requires to get it live. 
  • Are the impacts on the organization, either intended or not intended? 
  • How well does it meet the need? 
  • How high of a price?

Determine When Need is Met

Agile Extension to the BABOK®  Guide – section 5.3.6

The role of the Initiative horizon does not stop at determining a solution. It continues while the product is being delivered to determine when the need has been met. Again though, this is based on analysis, which leads to a recommendation. The ultimate decision does not belong to the analyst, but a responsible decision-maker or decision body.

Each delivered feature is an opportunity to determine if the need is met if more is required if changes are needed or the project canceled. The intent is to avoid waste by only satisfying the need identified by the Strategy Horizon.

Assess Viability

Agile Extension to the BABOK®  Guide – section 5.3.7

Along with determining when the initiative has met the need, a counter analysis also continues concerning the initiative’s ongoing viability. By viability, that not only means whether to continue the initiative, but also whether it needs to be altered in some way.

Agile is called agile for a reason – because it is built to handle change. So we have three options: to Continue, Change, or Cancel the initiative. The basis of that assessment is several factors that constantly change, such as the realized impact, success measures or KPIs, remaining work, constraints, feedback from delivery, and strategy.