How to Decentralize Decision Making

Why is it important to decentralize decision making?

Imagine the following scenario: you invest all of your budget and time into an idea that is supported by the HiPPO. And as you near the end of your budget (or time, or both), you realize that the project isn’t done; or even worse, nothing was accomplished.

You end up without the product you wanted, or with a product that doesn’t fit your market, and a huge disengagement from the team. After all, they spent their efforts on something that should’ve been something else. Wouldn’t it have been better if you’d done some form of risk management and validated your hypothesis before investing everything? By doing so, you’re able to correct the trajectory at any point, if needed.

Now that we know what this is and why we should be careful with it, let's see what we can do to address it.

How do you ensure the right decision-making process?

One way you can make sure decisions are based on data is by establishing metrics beforehand for measuring success.

Establish metrics and focus on data

See what value the HiPPO will bring to customers by setting up an expectation, a metric; something like “20% reduction in lead time" for example. Here, you can use the metric as a base to measure success. But which types of metrics should you use?

Actionable Metrics are metrics that allow decisions to be made (the opposite of vanity metrics). In other words, actionable metrics can show you how much time you’re saving for example or where your bottlenecks are.

Common actionable metrics include:

• Churn Rate: % of customers who have discontinued their subscription in a given period of time; it typically refers to users or revenue lost.
• Customer Acquisition cost (CAC): average cost of acquiring a customer; it’s the money spent on convincing a customer to purchase your product or service.
• Monthly Recurring Revenue (MRR): monthly projected revenue a company can expect to earn; it’s usually used among subscription-based/SaaS companies, but can also apply to services companies.
• Customer Lifetime Value: predicted amount a customer will spend on a service or product throughout its lifetime.
• Average Revenue per User (ARPU): measures how much revenue you’re generating for every active user; similar to MRR, but offers a more granular view.
  

In Jira, the CFD (Cumulative Flow Diagram) showcases how work items will flow through your workflow. To see it, go to your Jira board, then ‘Reports’, and select ‘Cumulative Flow Diagram’!

How do you read the CFD report?

The horizontal axis represents the time frame you’ve selected for the report while the vertical axis represents the amount of work items or story points you have, depending on what your team uses.

Colors represent the various statuses of your workflow, and can offer insight into your work items' approximate cycle time. The space between the lines is what can showcase problems you may have with the workflow.

• If bands are progressing in parallel, it means your throughput is stable. New tasks are entering your flow, while others leave.
  
• When a band is rapidly narrowing, it means that the throughput is faster than the entry rate; which might show that you’ve got more capacity than you’d need at this stage, and that you could relocate those resources.
  
• If a band is widening, it means that the number of work items entering that stage is higher than the ones leaving it; which could be cause by multitasking or some other waste activities that do not generate value.
  

Lagging and leading Metrics are metrics that can show you what happened (lagging) or where what you’re measuring is heading.

Examples of that are the Velocity chart and Burndown chart, which are also available in Jira under the Reports section of your board.

• The Velocity chart gives you the amount of work completed from sprint to sprint; which is more realistic when you wish to estimate the real work a team will be able to achieve in the future. There's a great article by Atlassian explaining how to read the Veloci chart report, you can access it here!  
  
• The Burndown chart allows you to track remaining work and calculate the likelihood of achieving your sprint's objective. It also gives you a view of possible scope changes and whatever was added after Sprint planning.

Here’s an introductory article to Burndown charts and how you can create them in Jira.

Pivot or Persevere?

Now that we’ve validated the results of our metrics, we can finally make a decision. Do we keep going with this initiative (persevere) or do we change course (pivot)?

What is pivot?

It is a  “…structured course correction designed to test a new fundamental hypothesis about the product, strategy and engine of growth.” - Eric Ries, author of The Lean Startup

There are many ways to do this; but what is most important to consider here is the data you’ve managed to collect so far, your decision should be based on that. Let’s say you’ve already spent 15% of your budget, but got nowhere; wouldn’t it be a blessing if you could pivot before having spent 100% of your budget? In this case, you’ve anyway already amassed some market feedback that can help determine the new direction you’ll be taking as you spend the remaining 85% of your budget.

To be able to achieve a shorter validation time, you can make use of a few Agile Project Management ceremonies:

• Sprint Planning
  Sprint Planning (or iteration, if that’s the name you use to define your team’s timebox) is where activities and objectives get defined. Remember that Sprint Planning is useful for short term objectives (1-4 weeks usually). The development team defines the capacity they’re able to absorb (this can be done based on data from previous sprints, if this isn’t the first).
  This is exactly where you’ll make use of your prioritized backlog to make sure activities undertaken are the ones to bring most value to your customer. If you want to know more about Sprint Planning meetings, the output they provide, and how to go about things, here’s a blueprint for you!
  
• Sprint Review
  The Sprint Review is where the Scrum team and stakeholders review what was accomplished in the Sprint, what changed, and what to do next. The result of a Sprint Review is a revised product backlog that defines the work for the next Sprint.
  
• Sprint Retrospective
  The Sprint Retrospective takes place after the Sprint Review, at the end of each sprint. It's a recurring meeting where the team discusses what went well and what to improve for the next sprint. It aims at continuously improving the processes.