3 things to make a giant leap towards Agility

I believe there are three things you need to do regardless of the framework, methodology or program you are embracing with your organization. If you don’t take decisions, focus on the outcome and get things done? Your transformation program, Agile Way of Working implementation, Lean initiative or whatever you do, will end up with all those other frameworks you have tried to apply before. You will never achieve the agility that was promised to you (by those expensive consultants).

Get ready for a free, simple and honest piece of advice. You might not like it. It might be a little painful. But it can save you a lot of money, frustration and people leaving, just by reading this post. Let’s start off with some statements that might sound familiar:

“Our organization is doing Agile”,

“We adopted the Agile way of working”

“We do some elements of Agile”

as said by many leadership teams or recruitment agents

I have no idea what these statements mean! I have no clue what ‘the Agile Way of Working’ is. What I do know is when I start a conversation about Agility with these companies. They don’t do any of three things I will describe in post. And to be honest. It doesn’t have anything to do with Agile. 

Take a decision

There is scarcity on almost everything. Resources, budget and people, there are never enough available in organizations when looking at the amount of work to be done. This forces organizations to take decisions on which things to focus. On paper this task should be done by leadership. In practice, no decisions are taken! Therefore not chance of agility! Let me describe the average response I get when I train people.

Too much to do

Let’s say you have the capacity to work on 5 items. But, there are 8 items to be done. You need clarity on what needs to be done first. However, if you don’t have clarity on the order of the work that needs to be done, how can you ever be successful?

Ever wondered why so many people are burned out? This is why! People feel very responsible for the work they do. Are committed to deliver the best results possible and will go through great lengths to achieve that. A workaround many people use is to just work harder, put in more hours to try and finish all 8 items. This puts pressure on quality delivered but especially on the people. What people need from their leaders? Clarity on what needs to be done first and what later!

You have other things to do?

And I know, as a leader you a very busy too. Your agenda is overbooked, you run from meeting to meeting! So there you have it, there is your problem! If you are unable to decide on your own agenda, what does that say about your ability to take decisions for you organization? 

Outcome over output

I want an app! We need to create a platform for that! They want a decision tree!

said no one ever

That’s not what your customers want! These all define an output. Your customers need an outcome, something they really want to be able to do. 

Below three examples:

Log in

A classic, the ability to ‘Log in”. Not a single user to any system ever wants to log in! Log in is an output. What a user actually wants is they enter a secure environment, where they only see information that is relevant to them and not anyone else’s information. That is what they want! An output to achieve this outcome is creating the ability to log in.

Brakes on my car

I do not want to have breaks on my car, that’s an output. I want to be able to reduce the speed of my car. So maybe deploying a parachute or throwing a big rock out of the back of my car will give me the same outcome…it will slow down my car. 

Agenda for a training

When organizations ask to provide a training course or workshop, they ask for an agenda. I never provide an agenda! I always reply with this question: What would you like to get out of this training. What result would you like this training to have? That is what is really important! A student or customer should not care on how I would deliver the training. But they want something else! With their response I can determine if, with the time available, I can achieve the desired outcome or how much time it might take to achieve the outcome. 


This is a very difficult concept to grasp and requires a lot of practice. But, if you are able to define the desired outcome, it will create a lot of freedom for the specialists in your organization to deliver this outcome with the least amount of output. 

Get stuff Done!

The amount of unfinished work in organizations is overwhelming. Since we work on as many things at the same time as inhumanly possible (burning out people!), we hardly get the opportunity to finish stuff. We care more about maximizing the output we deliver than we care about the outcome delivered. 

Ask yourself, does your organization care more about getting 4 things almost done (maximize output) or finishing 1 thing (maximize outcome)? 

Meanwhile, many metrics, KPI’s or triggers we have within our organization focus on maximizing the output. How many hours did you make this week? How many projects do we deliver within scope, time and budget? What is the number of issues solved last week? All output metrics. Not that they are not important to look at, they are but if you are able to save your organization 5 million with 5 minutes of work. Who cares what you do the rest of the week?

Raw chicken

Finishing stuff that are of good quality. Not delivering a predefined output, but the outcome desired and that includes quality! For some reason, we are not ok when we get raw chicken served in a restaurant. But as an organization, we are fine with delivering bad quality, as long as we meet the deadline or stay within budget. Let’s stop doing that!

In short, having clarity on what needs to be done first creates focus for your organization. Knowing the desired outcome and only asking for this, creates the freedom for your organization to deliver the outcome with the least amount of output. However, this comes with an obligation to the people in your organization to get stuff done (that also includes quality). Then it doesn’t matter anymore if you use Scrum, Kanban or Prince2. They will all work!

Business Decision Making Vlog

Magic Estimation Matrix – estimating effort and value in 15 minutes!

The best way to negotiate is with torsos angled, often at 90 degrees to one another. This avoids the face-to-face confrontational element whilst also allow looking at the other person’s face. This position enables having an open conversation. What we thought, would this approach also work with large group estimations on effort and value? But without the time-consuming conversations, and here is the magic estimation matrix.

There usually is a (un)healthy tension between those who are passionate about the value of features on a product backlog and those who have a slight idea on the effort involved in creating this feature. One of the techniques frequently used to create an initial estimation on the effort for an entire product backlog is Magic Estimation.

Using this technique you get a quick feel on the perceived effort of the items on the product backlog. In a nutshell this works as follows: Get a Scrum team together and have the Product Owner print each product backlog item on a separate sheet. The development Team does the estimation and without talking or non-verbal communication they have 15 minutes to estimate the entire product backlog.

We have often used this technique also for stakeholder to collaboratively create an initial insight in the priority of product backlog items. Since stakeholders tend to like talking even more (most of the time it’s what they are paid for), this has proven to be a great technique for filtering those items they all agree upon, this saves tremendous amounts of time.

Together with Ron Eringa, we thought if it would be possible to do this exercise simultaneously? Why not? This is how you would do this:


  • Product backlog items, each on a separate post-it or page in hard copy
  • Plenty of space to move around and place items on the floor
  • A sheet with the sequence of numbers inspired by the Fibonacci sequence for effort. For value add an extra zero, just to make it look important(see the image below what this could look like)



  • Briefly explain the rules of the game
    • Stakeholders and development team plays, PO watches
    • Spaced out estimation cards one axis for effort other for value
    • The Development team members each get a set of PBI’s
    • Rule 1: No talking
    • Rule 2: No non-verbal communication
    • Each participant’s estimates by placing item @ points. The Development team starts and as soon as there are about three items estimated the stakeholders will plan on value
    • Each participant checks estimate and if necessary re-estimates
    • Product Owner marks fall-outs
    • Discuss fall-outs until agreement is reached

This way you have a great initial estimation of your product backlog on both value and effort. And as a by-product stakeholders and development team get to know and understand each other a little better.