Category: Strategy 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: Product Roadmap

The Product Roadmap shows the direction of the product and how the product is intended to grow. It demonstrates alignment to needs and a plan to deliver over time. The Product Roadmap is built around the vision for a solution, it outlines how the vision will be achieved and is defines how to measure progress.

Elements

Elements of the Product Roadmap include:

  • The Defined Vision and Strategy – as an input
  • Another input are the Desired Outcomes
  • Maintenance of the roadmap is performed by the Product Management Team, which ensures it is current and remains aligned properly

  • The roadmap will focus on a collection of requirements or themes, or features.
  • And it deals on a high level of things expected to be valuable to the solution.

Example

Above is a simplified example of a Product Roadmap. It shows parallel development of some capabilities, some that are spread across multiple quarters, and some that may be delayed due to a dependency. This example shows that all capabilities are projected to be completed by Q4.

Description

Dealing so closely with vision, it’s no surprise Product Roadmap is used for the Strategy Horizon. It identifies each feature and positions them in columns related to projected timeframes. This makes it a good tool for projecting resource requirements. The context is Product Management or Refinement and the Audience is the internal Team.

Usage Considerations

Product Roadmaps provide a shared focus on what is needed and overall direction, including MVP discussions. It can be utilized for discussions on priorities or other options. Variations can be provided for a target audience.

However, if the vision is chaotic, this tool loses effectiveness. Also, there is a potential to view this as milestones instead of overall directional goals.

And if it’s too detailed, it can be hard to maintain, so keep things at a high level.

 

 

Technique: Portfolio Kanban

Portfolio Kanban identifies the status of each initiative, this can be a simple communication tool to give visibility across all initiatives, as well as to monitor and adjust resource allocations.  It is used to give visibility to the Process, Work In Progress, which helps in decision making and feedback on the strategy level.

Elements

The Portfolio Kanban will have columns for each step in the organization’s process from idea to completion. Each column has defined criteria for when the item can progress and has limits for entering the column or the work in progress.

The important thing is that each initiative is represented.

Additionally, there are regular meetings to discuss the Portfolio Kanban board and affected prioritization. Metrics are updated to help with prioritization. It is displayed in a place where everyone can see it.

Description

This is a vital tool for the strategy level because it allows decision-makers to have a visual understanding of all initiatives in the organization.  The information displayed can illuminate any bottlenecks and allow for decisions to re-allocate resources.  Also, utilizing Kanban principles, the organization may determine it is beneficial to place constraints or limits in certain cases, which actually increases speed.

The context is Communication and the audience is the Internal Team.

Usage Considerations

Some of the strengths of Portfolio Kanban are that you can set up varieties of this at the Initiative and Delivery horizons., and it allows Portfolio Management to be optimized. It increases feedback and visibility into what is in progress and where the bottlenecks are.

Some limitations are that it is a bit one size fits all at the strategy level – so if there are different paths for some initiatives, this would not work well for them.

And it doesn’t explain why an initiative is in one place or phase for an extended period, just shows that it is.

Techniques: Minimal Viable Product

Because of the title, many people are confused about Minimal Viable Product.

This isn’t the same as just getting by.  For example, if a new internal project is underway, the organization was already “getting by” previously. But the new MVP project provides essential coverage to meet a need without expensive “gold plating.”  If funding ran out and MVP was achieved, you would have a working product in the market or for your internal client and would be doing much better than before.  Additional features may be developed beyond MVP, but those are done after the product is viable. So, just because MVP is achieved does not mean the project will stop, just that it could and still be usable.

That is an important threshold to cross in product development.

Purpose

MVP is an important technique for Avoiding Waste.  When a potential capability or feature is added to the solution, one of the first things we should ask is whether this is necessary for a product to be viable.

And by viable, that means that it meets the minimum requirements for the early adopters of the solution.

Again, it isn’t that non MVP features will never get done.  Just that the MVP features will come first. In other words, it avoids waste by giving priority to what is necessary.

Elements

In defining the MVP, it is important to address the following.

First, identify who needs or wants this solution.  Then from that group, identify the early adopters.

Next, identify what needs to happen for the goal to be met and how you can verify that has been met.

Thirdly, as the solution goes along, actually measure the results to verify the intended need is being met by the minimum solution.

Finally, Define the requirements for each feature of the MVP solution.

Description

One interesting thing about MVP is how this focuses on early adopters.  If you do not satisfy them, you do not have a product.

Another aspect is this is not a static state – MVP can change over time.  As new features are identified, it becomes important to understand whether these are to become part of the MVP or whether they should be delayed for later – risking their exclusion from the product if there is not enough value.

That determination is how waste is avoided with this technique.

The context is Product Management or Refinement and the Audience is both Internal Teams and External Stakeholders.

Strengths and Limitations

Some of the things to be aware of for MVP Using are how it can be used to avoid unneeded or unwanted robust features.

Also, it’s important to realize the amount of research required to identify what is important for early adopters, and that sometimes features may be a best guess.  And if the solution is simple, going through all this might be overkill.

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.

 

Techniques: Visioning

Techniques: Visioning

Visioning is used to determine the desired outcome for an initiative worded in a concise and approachable manner.

Agile Extension to the BABOK®  Guide – section 7.24

When Patriots coach Bill Belichek meets with his team to begin practices, I would imagine that the first thing he says is something like “Our goal for this season is to win the Super Bowl.”

Everything else the team does is derived from that goal.  The team may not fully know how they are going to do that.  And certainly the other teams want to prevent them.  But everyone on the team knows that when Coach says “We’re going to win the Super Bowl” he knows they can succeed. And they understand what winning means.

Elements of Visioning

Agile Extension to the BABOK®  Guide – section 7.24

But there’s more to Visioning than simple inspiration.  Yes, it is a set of beliefs.  But it also is a SHARED set of beliefs.  Everyone gets there or no one does. That is called a Vision Statement

This shared set of beliefs comes out of facilitated vision exercises – or Vision Exercises. Finally it is expressed in detailed objectives to measure the goals – known as Impact Metrics.  These metrics show that the plan is working, but are not necessarily cause and effect related.

Back to Football, Coach may set goals for player’s strength, speed and skill.  Will those cause them to win?  No. Will they help? Yes. That’s the difference between correlation and causation.

Visioning Description

Agile Extension to the BABOK®  Guide – section 7.24

Visioning begins in the Strategy Horizon, where the organization determines which initiatives align to organizational goals. The vision for an initiative is set just before the beginning of the project and lasts through it’s duration.

The Vision Statement helps orient all those involved in the project toward the overall goal both of the initiative and the organization. It identifies how the resulting product will leave an identifiable mark on the products or services provided or on the organization as a whole.

One additional consideration is that Visioning may be associated with multiple related initiatives.

Finally the context is communication, and the audience is internal teams and external stakeholders.