Sunday, March 24, 2019

The six-step agile transition coaching model

What does a coach do - and how does a typical agile coaching engagement look like? 

This is my personal model - it may also serve as a discussion basis for others.

"What does an agile coach do?" - this model is an attempt at answering the question.

Stage 1 - Engage 

(with the as-is-system)
Judge not, that ye be not judged.
For with what judgment ye judge, ye shall be judged: and with what measure ye mete, it shall be measured to you again.
- The Bible, Matthew 7:1-2

In the first stage of a new client engagement, I engage with teams, management and business stakeholders. Even though I may have (deep) industry expertise already, I start with a blank slate. I look around, I listen, I ask. Regardless of what I encounter, I remind myself that people have reasons for doing what they do, for thinking what they think - for saying what they say.

I have no opinion in this stage. I am like a dry sponge, absorbing information.
In the Engage stage, my notebook fills rapidly, maybe 10-20 pages a day and not much precipitates, because nothing of what I write would be new for anyone who has been within the organization for a while.

The outcome of the Engage Stage is nothing more than a book of notes which nobody except me gets to touch.

How long does the Engage stage take? Depending on the complexity of the organization and intended change, anywhere from a few days to several weeks.

Stage 2 - Prepare

(the as-is-system for change)
Grace to accept with serenity the things that cannot be changed,
Courage to change the things which should be changed,
and the Wisdom to distinguish the one from the other.
- Reinhold Niebuhr, "The Serenity Prayer"

Every organization has to deal with certain circumstances. Some are mutable, others immutable. And even some of the mutable things may not be ready yet. Change strategy and communication is a very unique process, different for every single organization.

In this stage, I make proposals and verify them for feasibility. I still don't seem to be "doing" much -  the approach needs to be tempered by the current reality of my client. Bringing my client to a different reality doesn't depend on me - it depends on them: what they can see, what they are ready for and what they are willing to do.

The outcome of the Prepare stage is a transition strategy picture - I prefer to have a single page showing the Vision, main Objectives and a transition backlog with prioritized, sorted Key Results.
(it would be preposterous to say that the picture doesn't change - that's what being agile is all about!)

Depending on how available and open clients are for providing input and feedback on the strategy, this, too, can take anywhere from a few hours to several weeks - it becomes a drag in organizations where people are continuously "too busy to improve" and really fast if I can get people into a Workshop.

Stage 3 - Build Up

(something new with the people)
I'm focusing on the issues that bring people together and build broad majorities.
-Doug Ducey

In this stage, I work with the transition backlog to establish agile processes, practices, structures and mindset. The backlog allows me to focus and not overburden the client with too many parallel changes. What gets built up how in this stage depends on where the client stands and what they are ready for. It's not a linear process, it depends on continuous, deep feedback.

People can be built up in various ways: Formal training in frameworks such as Scrum or Kanban or methods such as BDD can open new horizons. Practical guidance, such as support in setting up the Backlog or offering insights into how to hold effective Reviews, boosts capability. When the a process gets reworked, I may propose unknown alternate approaches and then encourage independent experimentation with the process. 

This stage is the main stage where my own understanding of agile practices matters most, as the client usually simply doesn't know what they don't know or why the things they do won't get them where they want to go.

The outcome of the Build-Up stage are people - teams, managers and stakeholders - who have gained a new understanding and are equipped and ready to try out something new.

Since there is no universal definition of what it means to be "Built Up" and no objective standard for "feeling ready", this stage also depends strongly on the client's people and culture. The coaching process starts to become diffuse here, as some people might be in the "Strengthen" or "Support" stage already while others are still in need of building up.

Stage 4 - Strengthen

(new beliefs and practices)
Difficulties strengthen the mind, as labour does the body.

During the Strengthen phase, I help people to familiarize themselves with the new practices and ideas in their daily work. That could be anything like taking a look at the Kanban board and asking about queues or WIP limits, helping teams increase the effectiveness of their meetings, moderating Retrospectives to bring forth significant change and also individual coaching on the job - such as pair programming with developers, developing value propositions with Product Owners or walking Gemba with management.

The outcome of the Strengthen stage are people who feel confident in using new practices and who are willing to think in new directions.

It depends too much on the individual to answer how long it takes to continue through the Strengthening stage, as this is really a highly individual matter.

Stage 5 - Support

(others as they go their own way)
Believe that anything is possible when you have the right people there to support you.
-Misty Copeland

In the Support stage, my coachees anchor a new mindset. I work mostly to build up a self-sustained habit of feedback and growth while the show belongs entirely to the client (both teams and managers), who often habitually fall back into old behaviours and thoughts.
I coach by reminding people of their positive achievements, helping them discover and take the next step on their own, while also holding them accountable when they resort to behaviours they had decided to abandon.

The outcome of the Support stage are people who have made feedback and reflection a habit, who have no need of myself in their daily business.

The Support stage can be stable with a low amount of engagement over a prolonged period of time, but may be optional when the client has established internal mechanisms to create closed feedback loops.

Stage 6 - Journey onwards

(to new horizons)
Every day is a new day, and you'll never be able to find happiness if you don't move on.
-Carrie Underwood

Every journey comes to an end as the destination is achieved, and a new journey with a new destination starts. The end of my journey with a client is the beginning of their journey without me.

When bidding farewell, I like to part ways knowing that my client knows where they are heading and which are the next steps they will take, so we best close with a Retrospective to create a clear vision for the future of my client.

The "Journey Onwards" stage ends with the order - although I may still retain informal touchpoints  irrespective of budgets or commercial gain. After all, we're human beings whose relationships shouldn't depend solely on money.

Closing words

Sadly, most clients only plan budgets until Stage 3 - "Build Up", which oftentimes results in organizations reverting to old habits and practices, lacking understanding how they are damaging their own progress.
Although this is the normal case, I prefer to work with clients who take care to complete what they have begun.

Equally saddening is to see coaches/consultants who purposely create dependencies upon themselves, never enabling the client to take autonomous control because doing so would dry up their revenue stream.

I feel it fair to inform my clients that "A Transformation isn't done with 1-2 months coaching", and that my engagement will quickly diminish once I am confident that they can do it, which neither means that I am suddenly disinterested nor that it's already a good time to stop.

Tuesday, March 12, 2019

You have to be crazy to hire consultants

"You have to be crazy to hire consultants." - I repeat this sentence quite frequently after arriving at this conclusion almost a decade ago. Being a consultant myself, I think this statement is merely a reflection of the way how many clients see consulting work. Let me explain. 

Before we start, this article isn't about outsourcing services far outside your core value stream - for example, I myself resort to the services of a tax accountant, because studying tax law in detail would derail my value focus. This article is about consultants dealing with the core competencies of your organization.

Pervasive Taylorism

Most organizations are still set up according to the principles of Taylor - workers do the work with managers ensuring that they do the right work right. In knowledge management, "doing the work right" is known best to the workers and not to management, so that leads to the first level of craziness:

Organizations both expect and reward managers for being in control. Managers are expected to be responsible for coming up with solutions to known problems. Workers, on the other hand, are being overburdened with work and couldn't care less about resolving endemic problems, since that's not what they were hired for.

And like this, the most qualified people don't do that which would help the organization most and the least qualified people often decide on changes that don't help at all - and nobody sees a problem with the approach.

Inability to solve problems

When a problem arises, team members are neither enabled nor available to solve it. Management would then often demand, "Bring me solutions, not problems" - although teams working in a local context are often incapable of doing this when the root cause is outside their sphere of control. When the teams themselves have no solution, the obvious solution is to bring in consultants to provide a solution, since managers are busy with their other responsibilities.

And this is the second level of craziness:
  1. People with the skills solve the problem don't get time to think why the problem exists.
  2. People in a position to solve the problem don't have the skills to solve the problem.
  3. People hired to solve the problem won't have to deal with the consequences of the solution.

Absurd Incentives

Dysfunctional organizations thereby create absurd incentives, the third level of craziness:
  • Team members willing to solve problems get punished with overload because problem solving time isn't factored into their already full workload
  • Team members might be reprimanded for wasting time when their solutions are ineffective, making "doing nothing" the preferred option
  • The separation of management and doing work renders managers who solve problems ineffective in their management role, rewarding managers who do not spend time to solve problems.
  • Not investing time into active problem solving rewards managers who delegate problem solving to others.
  • Project organization rewards managers for band-aid solutions with a life expectancy not much longer than the project's duration.

The need for consultancy

Thereby, organizations reach the fourth level of craziness:

As team members and management are likewise incentivized not to assume personal responsibility for sustainable improvement - thereby incentivizing management to hire external consultants, who get paid to solve problems nobody else benefits from solving and who can conveniently be blamed when the solution doesn't work out.

In conclusion, I claim that the amount and frequency of resorting to external consultants are a decent measure for the level of organizational craziness.

Fixing the root cause

You'd think it should go without saying that the solution here isn't hiring more consultants to do an Enterprise Transformation, yet that's what organizations do - the ultimate level of craziness.

So, if more consultants aren't the solution - what is?
To make a long story short, rather than adding further layers to the problem, we need to dig down to the root cause: the distribution of responsibilities within the organization and the perception of what management in a knowledge era means.
Fundamental change must start there, and the people who have to make the change are the people of the organization themselves!

While Consultants and trainers can provide options for a different way of doing things and can assist in the transition - the change must ultimately be determined, owned and executed by the people of the organization themselves!

Coaching or Consulting?

Draw your own conclusions.

Wednesday, March 6, 2019

Finding fertile soil for coaching

There are hundreds of poorly written job offers for "Scrum Masters" or "Agile Coaches" out there - mostly because clients don't understand what they should be looking for. And who can blame them? Why would they need you, if they did?

It's not Cockaigne

I have talked with numerous "Scrum Masters" who require that a Scrum Master job ad be written properly to represent the role of a Scrum Master as based on the intention of the Agile Manifesto and healthy Scrum. They already screen the job interview for any hints that the organization may not be agile and disengage at the slightest hint that the company "doesn't get it".

In my personal opinion, these people are cherry picking. A very important part of being a Scrum Master is creating a healthy Scrum environment - to expect that it already exists means taking the easy route.

And since life isn't a bed of roses, even seemingly perfect environments have challenges.
I heard the personal stories of Scrum Masters who were sorely frustrated upon being confronted with un-Scrum-like elements in their organization and having to deal with people who interefered with team autonomy. Those stories make me wonder: "What did you expect?"

There will be challenges. There will be mindset discrepancies. There will be arguments. And that is part of the job.

Good descriptions can be bad jobs

There might be a huge discrepancy between written words and unspoken expectations.
Here are just some examples of hidden pitfalls:
  • "Guide the team in their self-organization" could mean "Track who does what, when and how long it takes"
  • "Establish agile ways of working" could mean "Enforce adherence to the 'Agile' Jira workflow"
  • "Help people adopt an agile mindset" could mean "Developers need to work faster and harder".
And that's just the tip of the iceberg. Below lurk further dangers:
  • Your influence is limited to the team
  • Rigorous adherence to rules
  • You're expected to optimize for efficiency or utilization
  • The need for supervision and control
  • Pressure to meet quota
All of these are serious concerns, yet nothing to be afraid of - there are problems everywhere, so why should any specific company be any different?

A good basis

As agile coach, change is your job - you just need to be aware when you're fighting an uphill battle and are up alone versus an armada. In some cases, steering clear of a confrontation is better than running headlong into your demise. So, how do you know the difference?

It's about people

"People and Interactions over Processes and tools" - for none is this truer than for an agile coach. Take a note of how people behave in their interaction with others.

These character traits from members of the organization are hints that existing problems and challenges can be overcome:
  • Trust: Invite and extend trust to and from others. Build networks of trust.
  • Humility: Able to admit that not only things, but also they themselves aren't perfect.
  • Kindness: Reach out in a generous, open-hearted way.
  • Openness: Share and receive ideas.
  • Accomodation: Give people a break for being in situations beyond their control.
  • Consideration: Take care to minimize inconvenience for others.
  • Curiousity: Ready to try out something completely different, even when the outcome is unclear.
  • Mindfulness: Willing to consider cause, effect and circumstance.
As a counter-indicator, when these character traits are either absent or even exploited within an organization, this will pose a challenge that won't be overcome by a single Scrum Master.


The importance of human virtues and relationships in picking the right place to make an impact as a Scrum Master should not be underestimated. Forget the job descriptions and have a conversation.

Shift the focus away from what people currently believe about how Scrum should look like and take a closer look at the character which people within the organization exhibit.

Coaching and change are much easier when there are positive character traits visible. At the same time, when these traits are compromized, there's a massive chance that coaching will not have an impact and no change will happen.

Don't try to help everyone. Pick the people who are willing to receive it.

Tuesday, March 5, 2019

Where the benefits of SAFe come from

Are the advertised benefits of SAFe real? 
The Scaled Agile Framework claims the following benefits of a Lean-Agile transformation:
Benefits of SAFe, taken from

These benefits are definitely realistic when the right levers are pulled in a traditional organization -  Let's take a look at how!

This article will focus on statements by William Edwards Deming and examine how SAFe implements these for visible benefits.

Productivity increase

Productivity isn't nearly as much a function of doing the right thing, as it is a function of stopping the wrong thing. Deming hypothesized that 95% of productivity is attributed to the system and only 5% to the individual:
"The fact is that the system that people work in and the interaction with people may account for 90 or 95 percent of performance." - attributed to Deming
Working in an ineffective system can reduce the performance to a twentieth of what would be possible - so when a theoretical 2000% boost is possible by creating "the perfect high productivity environment" (and hyperproductive teams prove that this is, indeed possible) - 20% is a single percent on the scale in an average corporate system(!)

Just having senior managers think about stopping some of the most egregious ways of wasting productivity and turning these into actions will result in the mentioned benefits.

Here are some ways in which SAFe addresses systemic productivity waste:

  • Reducing overly large delivery batch sizes
  • Increasing mutual understanding of requirements
  • Reducing the amount of handovers in the process
  • Reducing context switches for team members

SAFe's magic ingredient to productivity is the PI cadence with the ART.

Quality increase

Quality is the result of strategic decisions executed by the workforce. That is, by setting incentives and defining a route promoting low quality, the outcome will inevitably be low outcome. Impediments to quality are usually created above the team level:
"Quality is made in the board room. A worker can deliver lower quality, but she cannot deliver quality better than the system allows." - W.E. Deming
Some of the main drivers of low quality are lack of information and deadline pressure.

As Deming stated elsewhere, it's not enough that senior managers state that they want high quality (doesn't everyone?) - they need to get active in resolving impediments to quality. For this, they must examine and change those systemic constraints which lead to low quality.

Here are some ways in which SAFe addresses systemic impediments to quality:

  • Generating clarity of customer intent
  • Bringing the people together who should talk
  • Allowing teams to determine scope per time
  • Agreeing on a "Definition of Done"
  • Introducing meaningful feedback cycles into delivery
SAFe's magic ingredients to quality are the PI planning event and the System Demos.

Time-to-market decrease

It's not like people aren't trying, that they aren't busy, that they wouldn't be working fast enough. The problem is that they are often torn between many things and have no idea which of these is the most important or why these are important now:
"It's not enough to do your best: You must know what to do, then do your best." - W.E. Deming
That's why there is a lot of work in progress, many context switches and clogged delivery pipelines. According to Little's Law, Time-to-Market depends on how much work is in the system at any given point in time. Add more work to an overburdened system - and time-to-market goes up.

SAFe addresses time-to-market indirectly, albeit very effectively:
  • The PI Planning sets the focus for the upcoming 3 months.
  • Using an Economic framework scraps low-value work.
  • The PI cadence limits work in progress (WIP).
  • Iterations allow setting team-level course biweekly.
  • Continuous Delivery gets Done stuff shipped faster.
 If your organization had a history of delivery times 12 months and up, the 3-month cadence alone will easily reduce the Time-to-Market by 50% or more.

SAFe's magic ingredients to Time-to-Market are the PI cadence and the resolution of large batch delivery.

Morale increase

Organizations are great at demotivating employees by deriving their work of all meaning. People quit their job is when they hate it - when they can no longer identify with why they should be doing it. This happens most often when they can lo longer see the meaning of their contribution:
"When one understands who depends on me, then I may take joy in my work." - W.E. Deming
SAFe addresses detrimential impact on morale in the following ways:

  • Setting clear PI objectives 
  • A Program Board visualizing what the work contributes to
  • Working with "User Stories" makes the consumer visible
  • Allowing teams to focus on reaching a "Done" Increment
  • System Demos with real user interaction
In many large organizations, most of the work is - just work: long, arduous status meetings, constantly shifting priorities and binning unfinished work, creating documents which nobody will ever read etc. 

By abolishing these mechanisms, people get more satisfied - and when they are then replaced with real customer interactions (occasionally even with praise for a job well done), morale naturally gets a massive boost.

SAFe's magic ingredient, again, is the PI cadence and the System Demo.


The key benefits of SAFe are quickly realized by:
  • Clear Objectives
  • Dedicated teams and dedicated teams-of-teams
  • Cadences
  • Getting to Done
  • Closed feedback cycles
If one or more of these mechanisms is "adjusted for pragmatic customization", then SAFe becomes a relabelling exercise and the benefits become elusive.
There are other ways of setting up these mechanisms, SAFe is just one of the means to establish them.
Once these mechanisms are in place, that's not the end of the journey. it's just the beginning thereof.

As hinted in the article, it's even possible to achieve benefits exceeding those proposed by SAFe by a factor ten or higher - although few organizations have the dedication and courage to improve so relentlessly as to realize them.

Saturday, March 2, 2019

Making sense of Agility

"I know this doesn't make any sense, but ..." - aren't you all too familiar with this response towards questioning a specific process or practice? I have started the agilecartoons series to highlight the absurdity of practices and ideas some organizations hold dear. But is absurdity sufficient reason to say "That's not Agile"? I myself am not a big fan of either using the "Big-'A' -gile" nor about branding anything or anyone without understanding their context. So let's drill in.


We need to be able to understand what's going on around us. Awareness of what's happening is very important when making decisions. With more transparency, we can put our ideas, actions and options into a more appropriate context. As transparency goes down, we resort to doing more and more guesswork and the probability of poor decision making increases.

So, here's the first sense-making question:
Does it make sense to make a decision with the understanding we currently have?


Rather than just doing work, this work must be seen in context, the big picture. And then we need to take one step back and determine whether our actions, choices or ideas fit into the picture and whether that picture looks odd.

This brings us to the second sense-making question:
Does it make sense to do the things we're about to do next?


Upon discovering that something does indeed not make sense, does it make sense to do that thing? If you answered "Yes", I will rest my case. Otherwise, we need to look for the most sensible option at our disposal. I carefully avoid the term "right", because right and wrong may only be visible in retrospect.

This brings us to the third sense-making question:
Does it make sense to do something else instead?


When acting within an complex system - and organizations tend to be inherently complex - then our predictions about what would make sense are often not very accurate. We could be anywhere from outlandishly wrong to precisely correct with the choices we made. Fire-and-forget decision making often results in heaping one more dysfunctional approach over another. When we tried something, we need to look at our current situation by asking:
Did the things we just did turn out to make sense?

Does it make sense to "go Agile"?

If the answer to the sense-making questions is "No", hesitation, reluctance or even resistance, then - sorry to say - what you do doesn't make any sense, by design. As long as there is a mental barrier to getting to "Yes", no amount of "Agile" frameworks, methods, practices or concepts will make you agile. Your system is broken and you should examine that first.

If, on the other hand, everyone can wholeheartedly say "Yes" to the four sense-making questions, then you may find value by experimenting with those agile frameworks, methods or practices that make sense.

The avid reader may have noted that the first three elements are called "The Pillars of Scrum" (and/or "Empiricism") - and at the expense of stating the obvious, your willingness to uphold these elements is essential in determining whether it makes sense to introduce Scrum.

Tuesday, February 26, 2019

What does it mean to be agile?

A few years back, I coined the phrase, "Creating understanding is more essential than offering solutions". It used to be my working motto. Then I realized that even understanding is nothing. 

Agile Knowledge

As trainers, in a classroom, we teach "Agile" - be it Scrum, Kanban, XP, SAFe, LeSS or whatever. From twenty people who walk out of the class, maybe one has really understood the "Why" behind the things we teach.  The others jump right into doing and sooner or later struggle, because no classroom training can ever be comprehensive. The reason why agility is so important: reality is more complex than any process, method, strategy or approach we could devise.

Agile understanding

As consultants, we have a boatload of knowledge and even practical experience when it comes to implementing agile methods, frameworks and structures. But we usually still fall short of bringing our clients to the level we are. Not because we don't understand, and maybe not even because we can't get our clients to understand, but because we're talking about things we can't do with our client. We bombard them with knowledge and then try to approach the minds, but fail to bring them into action.

Agile Practice

Many agile practitioners merely go through a series of motions with their client (or their company, respectively). They may have both knowledge and understanding of what they do - yet still don't make any impact nor generate fundamental breakthrough. Why? Because, for them, it's just a job: A role they take. It ends with the engagement. And outside, there are other practices, other behaviours. They aren't agile. They only use agile approaches.

Those who just are

And then there's people who are like Toyota. Toyota didn't devise "Agile", their goal wasn't to implement "Lean". They just did, they figured it out all by themselves. And maybe they couldn't even explain half as well as some Agile Trainers can what they did and why the things they did were "Agile". Indeed, they didn't care for such labels at all.
Did they ever bother to build sufficient upfront knowledge about "Agile"? How could they, there was no such knowledge basis!
Did they bother to analyze and understand in detail what "Agile" means? The concept didn't exist, and it never crossed their minds!
Did they bother to implement the "Agile" practices correctly? There was no such thing! They made it up as they went.

They didn't stick to a book, they didn't stick to a concept, they didn't stick to a specific practice.
And that's what made them agile.

Wednesday, February 20, 2019

Top 3 success factors for agile transitions

So... SAFe. Big picture, many elements. What's important and what's not? What's make or break for becoming an agile organization? In this article, I will examine - based on my personal, subjective view, the three most important elements determining whether you're going anywhere.

What's not important

Many organizations start by defining their future structure and ensuring that all important people have gotten an "agile" role. Let me be blunt: in many cases, the transformation has already failed at this point, because it will be the same people doing the same thing in the same way as before, just with a new label.

So then, what is important?

#1 Relentless improvement

Many organizations tailor the Emperor's new Clothes. They set up systems where transparent, honest criticism isn't welcome - only good news and affirmation of status quo are acceptable. Even when they do indeed set up ceremonial Inspect+Adapt events, these events will never result in fundamental change and are usually just affirmation sessions leading to cosmetic changes when invasive surgery would be required.

To become agile, the organization must be able to accurately identify where things are going wrong, then precisely locate what aspect of the system is the root cause, then mercilessly make effective changes. And then, they must acutely observe the outcome of that change. If this isn't happening on a frequent basis, tranformation just establishes a new status quo.

An organization without a culture of Relentless Improvement will be cargoistic - they will go through all the motions in a ritualistic way and never understand why they're not seeing the desired benefits!

A) Systemic Inspect and Adapt

Team Retrospectives are just a small part of the picture. Everyone should be encouraged to identify and highlight systemic dysfunctions. The organization must have a transparent process for addressing, analyzing and resolving systemic dysfunctions. This takes courage on everyone's side - and openness from leadership.

Agile coaches, respectively Scrum Masters, first and foremost, need to work on creating both this kind of culture and awareness.

When effective systemic Inspect and Adapt is in place, most of the other things will eventually fall into place.

B) Closed feedback cycles

Feedback occurs everywhere, anytime: Among individuals, during the work, in processes ... If feedback is accepted and acted upon, further feedback is encouraged. When feedback is routinely rejected, the cycle breaks. And when no mechanism for providing feedback exists, the door to improvement is closed.

Agile coaches need to keenly observe how feedback works and actively shape closed feedback cycles.

C) Radical Candor

When the Emperor has no clothes, people must be able to say so. A dysfunctional process must be fixed, a worthless requirment trashed and an undesirable feature axed. As long as there's a mindset that decision makers know why they want things and the system doesn't incentivize stopping the wrong things, the most significant improvements to performance and outcomes just won't happen.

Agile coaches need to lead by example in being candid: Questioning worthless work and dysfunctional structures are bare minimum requirements to effective change.

#2 - A strong product organization

Let me be clear, I don't mean that a lot of people should be involved in "Product Owner/Manager" roles. A product organization is strong when it has effective mechanisms of addressing the right things and setting developers to do the right thing. The product organization isn't as much about structure as it is about turning opportunities into value in a very short time. It's about setting up the mechanisms and instilling the knowledge for maximizing value.

A) Focus on Value

Product people need an appropriate, effective way of discovering where value lies, identifying which backlog items have how much value and extracting the primary value from larger topics. When product people aren't keen on maximizing the value delivered, all is lost. Any mechanisms or incentives within the organization which tint, bias or distort the understanding of value will multiply a hundredfold into ineffective outcomes, so they need to be addressed and removed.

Agile coaches need to establish a focus on value by helping product people and managers see what is value and what isn't.

B) Deferred Decision Making

Until it's clear whether a value hypothesis is even valid, product people should reserve the right to change direction. When items are scoped for implementation before it's clear that their delivery will generate any value, there's a lot of money at stake. Should exploratory work open up alternative routes, the product organization must be able to inspect and adapt to this!

#3 - Technical Excellence

Doing the right thing in the wrong way may make the outcome appear like it was the wrong thing to begin with. Shoddy workmanship costs money, wastes opportunities and causes further harm to outcomes in the future. Developers need to be able to take pride in a job well done and have the confidence that their results are of high quality.

A) Genuine Shift-Left

Developers can learn how to better build products which do what they're supposed to in a way that customers like. Having a separate Testing or Operations unit is counter to this learning taking place. Terminology like "DevOps Team" masks dysfunctions and fails to address the root cause.

Agile coaches need to spot where functional separation breaks feedback cycles and bring the right people together.

B) Lifelong learning

Knowledge workers need to have time free from delivery work to learn new things, experiment with new technologies and try out different ways of doing the same thing. The higher the utilization for delivering features and fixing problems, the less likely developers will keep their edge. While many developers are geeky enough to use their spare time to learn things, it's essential to make sure the organization enables structures and processes which routinely include learning.

Thursday, February 14, 2019

The 5-minute Retrospective: Try Speedrospectives!

Agility depends on receiving timely feedback and turning it into effective change action. Relentless improvement requires closing feedback cycles wherever possible and whenever possible. 

Why Speedrospectives?

Many new Scrum Masters follow the boring, time-consuming and ineffective "What went well/what didn't go so well" template and can burn hours of precious team time without causing significant change - this model often degrades to a platform for self-adulation and/or ranting.

The Scrum Master -- or any agile coach, for that matter -- should create a self-perpetuating system of Kaizen, "Striving for the better", and do this in the most effective way.

Have you considered a Retrospective after every single meeting in your organization, to improve these meetings themselves and thereby increase the value of communication? How much time should that consume to be worthwhile?
A regular Retrospective is unfeasible in this context - but where, when and how do you address improvement potential then?

An important part of behavioural change is to address the situation as it occurs so that the memory is still fresh and set the stage for a future, more desirable condition.

The 5-minute Retrospective

When you know your audience and the situation is already stable, there's no need to go through the (definitely helpful) 5-stage Retrospective Process, you can just cut straight to the heart of the matter: What should be different next time in order to get more value?

And that's where my handy Speedrospective template comes into play:

The diagram itself is self-explanatory:
"If we do this again, the next time, we should ..."

  • Try: Introduce a new element or modify an existing element. For example, in a Retrospective, it could be: "Try whiteboards instead of sketching on letter-sized paper"
  • Stop: Elements which should not be repeated. For example: "Multiple people talking"
  • More: Elements which are helpful and could use strengthening. For example: "Collaboration on issues"
  • Less:  Elements which, although helpful, are overdosed. For example: "Process explanation".

Schedule of the Speedrospective

Create sketch

If you're fast (which is what this is about), you draw an X and write 4 words. That should just take half a minute - or a minute, while you're explaining what's coming. (1min)

Collect items

Take 2 minutes to collect feedback - more time isn't needed, because if participants don't have anything on their mind, it's probably not important, anyways - and next time around they might prepare a sticky right in the moment when something happens because they know they can bring it up. (2min)


After issues are collected, vote ONE the group would like to see implemented. (1min)


Agree how to make it happen and thank the group. (1min)


Speedrospectives are a highly effective tool to close feedback loops, initiate change and establish a culture of relentless improvement. The process is significantly more powerful than the "well/not well" template, because it's fully outcome focused.

Other uses

The suggested Speedrospective template can be used in many contexts, such as event closure - as well as in personal and organizational coaching.


There are many ways to commence a change-driving Retrospective within 5 minutes. The above approach is neither to be considered prescriptive nor the only way. Try experimenting with Speedrospectives and see what works for you.

A note of caution

Speedrospectives may miss fundamental change opportunities - for example, when we're having the daily frontend architecture status meeting, we will find ways of getting the most value out of this meeting without ever crossing the idea that the meeting itself isn't a good idea. They are not a panacea, just a simple power tool to support a continuous change mindset.

Saturday, February 9, 2019

Why organizations use Scream

The Scream framework has struck a nerve. This parody of the Scrum framework isn't just loaded with antipatterns - hundreds of people have already noted how similar Scream is to what they observe in their own organization.

Scream is a parody, and it would seem like nobody in their right mind would do those things - yet people do exactly that. But why?

Scream works!

Scream is effective. It works. The patterns found in the Scream Guide are all ways in which specific problems the organization has encountered have been addressed. And unlike Scrum, there is no rigour to Scream - it works very similar to the ice cream truck in summer. It addresses a need and makes people feel better.

Here's how:

The Scream flow

The Scream flow is easy and intuitive.

On the surface, it works like this:
A problem appears, and there's pressure to act before this becomes a personal issue, such as having an escalation, seeing your performance review drop, and therefore your bonus disappearing or whatever.

So why spend time to identify and isolate the root cause which may be hidden somewhere outside your own sphere of control? Pick a Scream pattern and apply it.

The pressure lifts - or at least, it goes down a few marks on the scale. Scream experts learn to throw Scream patterns at problems before anyone has even noticed there's an issue. Stress levels return to normal, and there's even a reason to celebrate having taken care of an issue.  Instant gratification.

And when the next problem appears? Rinse and repeat. Scream becomes routine quickly.

The rug

There's an insiginificant fly in the ointment. It's so miniscule that most managers and developers are more than happy to just let it go, as the evening is saved and no further meetings are required on the issue:
The problem wasn't solved. A band-aid patch is no cure. The core of the issue has been shoved under the rug, and the Scream "solution" has added another problem to the batch. No matter. Let's call it a day and move on to something completely different while the rizom continues to grow.

And one of these days, it will be harvest time. The problem has grown bigger than the rug and starts to resurface.

No problem - just apply the Scream flow and shove it under the rug again. It feels good to see the issue gone again.


Scream effectively makes problems disappear in an instant. This feels good. Even though the problems resurface and grow, there's always a solution: More Scream.

Sunday, January 27, 2019

The Agile Fallacy

"That's not Agile!" - does it matter? My claim - no!

"Being Agile" isn't true/false - it's a spectrum from rock to photon. Everyone is somewhere.

When looking behind the "Agile vs. Not Agile" bifurcation fallacy, we can start asking more meaningful questions:

  • Does the organization meet Market and Business Needs properly?
  • Does the Product stay relevant over time?
  • Are the Delivered Outcomes useful?
  • Is the Total Lead Time acceptable?
  • Is the overall Return On Invest of development positive?
  • Does everyone Focus on the most important thing?
  • Does development create up-to-date, Sustainable Solutions?
  • Is Technology Debt under control?
  • Is Improvement Potential leveraged effectively?
  • Do Failures get addressed and corrected openly?
  • Is there Continuous Learning going on?
  • Does the company exhibit Resilience to market changes?
  • Does the organization have a Sustainable Workload?
  • Does the organization attract, grow and Retain Talent?

If all these questions are answered with "Yes", then I could ask "Why do you want to be agile?"
If the answer to some or all is "No", then I would ask, "Then what are you doing about it?"

Taking a closer look, even these questions aren't binary, but gradients which would usually range somewhere from "We need to do something immediately" to "Yeah, we might want to think about it."

All the above questions are merely indicators of whether an organization is sufficiently agile for its own good, so I would leave you, as a reader, with the initial question: If an organization is excelling in all the areas mentioned above, does it matter whether they're agile?

Friday, January 25, 2019

Can you afford to have an IT department?

Many non-digital businesses augment their core business with digitization and automation. IT is "The Thing", and even though every organization want to have the benefits of an IT, few seem to consider the cost of IT. In this article, we will examine a few critical considerations.

Bad IT is just as good as burning cash.

When IT becomes a poor investment

In many organizations, IT is still considered a "feature factory" where business dumps in requirements, gets a cost estimate and upon approval, a piece of software to automate a phrased request, and that's it. Business and management neither wants to think about what is being done, nor how much effort is required to create and maintain the solution.

This approach was okay in the past, when the major cost of IT was in procurement of hardware and licenses and the human factor was neglegible.

Fixed cost procurement

Factoring the cost of a purchased IT product is easy: you have a purchase price for hardware and licenses, sign a support contract with a fixed price, order some training and you're done.
The cost of such an IT can easily be computed as a business case: when the cost is lower than the savings, you're good.

Cost Estimation

Unfortunately, that's not how today's or tomorrow's IT works.
Today, business wants automation for something that they are currently doing either manually or not at all. There is no solution which can be purchased.
Knowledge work is required. Since the optimal solution isn't known, the cost becomes difficult to compute, and therefore, all cost estimates are just that - estimates. There is no reliable way to tell the production costs of a feature until it is done.

Hidden Costs

And now we come to the fatal trap which many organizations fall victim to: the accruing cost of IT over time! Business terms like debt, deprecation and amortization are also applicable to IT.

Debt in IT

A financial debt is accrued when spending exceeds available funds. In IT, debt is accrued when technology is being utilized in ways which will result in future problems. Known debt still has the can be controlled, although few organizations measure and control thind kind of debt. Every accountant would cringe if someone told them, "Oh yeah, we're making debt every day, but we're neither keeping books nor make plans for repayment" -  yet this is how IT works in many companies.

Time-saving measures allow the business to get visible results faster, yet increase future cost.

In some organizations, this invisible IT debt is already so high that things which would take minutes on a green field take weeks within the existing infrastructure. Imagine that you're paying a loan shark an interest rate of a couple thousand percent per day - that's uncontrolled IT debt for you!

Deprecation in IT

The good thing about the constantly evolving field of IT is that new technology makes ever more complicated things ever simpler to achieve. On the reverse side of the medal, if you're not familiar with this technology, you're missing out!

While IT specialists are busy maintaining the existing legacy and struggle to integrate the latest feature requests, their technology outdates - and their knowledge, as well!

The company constantly invests into an ever-shrinking asset: status quo. At some point, the existing staff will no longer suffice to maintain status quo, so additional experts are brought in to keep IT running, although the marginal value of the infrastructure is already approaching zero.

Adding insult to injury, re-engineering the legacy based on the legacy processes with a legacy skillset using legacy tools exponentially increases the cost of change and produce a similiarly ineffective outcome.

Take, for example, the company still maintaning an IBM 704 mainframe: the costs of administration, maintenance and electricity are astronomical - yet the computing power of the system dwarfs a $100 smartphone! Yet, many companies still stick to their old systems because core business processes rely on them. Any effort to replace this legacy becomes unfeasible both because nobody has time and the effort is humongous.

Amortization in IT

The financial technique of amortization splits the cost of a finite-life product into a series of installments. and something similar happens in technology.
Danger: The analogy of amortization is highly flawed - your accountant would rip your head off if you tried to explain to them that:
  • You have no idea when the final installment will happen, and there will potentially be an infinite number of them!
  • If the present value of a system is lower than its cost, each installment will have a negative ROI.
  • You're very likely to pay installments long after the marginal value is zero.

Let's say, you your developers need a technical training; If you don't invest, their code is more expensive and less valuable than it could be - but if you do it, in a year, their code will still be outdated. You amortize not to generate profit, but to reduce loss.

IT is a money sink

Running an IT department is not just about having a handful of servers and building some business functionality.
This is how IT costs money:

IT assets are debt-riddled

Quick wins in IT tend to be even faster losses. Without a future-oriented sustainability strategy, you're no longer taking a controlled debt, you're baiting loan sharks!

If you don't (want to - or can) control your technology debt, your IT will eventually kill your business with skyrocketing costs at little to ROI!

Make technology debt visible and keep the interest at a maintainable level.

IT assets deprecate drastically

Any technology should be replaced within 5-7 years, so regardless of whether you're investing $1000 or $100m, be prepared to re-invest a similar amount in less than a decade. The more your IT is worth, the more it will cost you.

Without a deprecation control stratey, your IT will eventually be worthless, yet continue to drain money needed for investments.

Move towards continuous asset migration and decommissioning rather than investing heavily into maintenance and support.

IT assets won't amortize

Any technical or knowledge asset which isn't worth its cost by the time it becomes available, will never be. While cross-subsidization or taking a loss in order to avoid greater losses are both feasible options, throwing good money after the bad isn't a strategy!

The acquisition and maintenance of assets which "might have future value" is an unsound strategy that will most likely result in an economic shipwreck.

Avoid over-engineering, keep as little technology as possible and consider any investment "lost" the minute you signed the check.
Obtain technology only when it is needed, and only as much as needed.

An IT Investment strategy

Based on the above, let us now consider a few choices that you need to make with your IT:

  • Are you willing to consistently and scrutinously track and combat technology debt?
    • NO: You will lose cost control of your IT if you haven't already.
    • YES: Lapses cost twice. Be alert!
  • Do you have a sound mechanism for determining the net present and maginal value of your IT?
    • NO: Your ROI will most likely tank.
    • YES: When a processes' cost exceeds its marginal value, eliminate it.
  • Are you willing, able and ready to identify, replace or eliminate ineffective cost drivers?
    • NO: Your IT is a gambit with diminishingly low odds of success.
    • YES: Remember that yesterday's business driver can be tomorrow's cost driver!
  • Will you consistently invest a significant amount of time and money into the continuous learning of your IT workforce?
    • NO: Your IT is dead already, you may just not know it yet.
    • YES: Keep an edge. Avoid tailgating others.
  • Does your organization have the courage to admit and the grace to write off mistakes?
    • NO: Your IT will eventually be the Emperor's New Clothes.
      YES: Turn failure into learning, mishaps into opportunities for change.

If you have answered "NO" to any of the above questions, either re-consider your IT strategy or consider obtaining services from a provider who would answer all of them with "Yes".

Tuesday, January 22, 2019

A brief history of IT

Is your IT future-oriented? 
The nature of IT is changing - if you aren't adapting, chances are that your IT is a liability rather than an asset for your organization. So - what's different?

Yesterday's IT

The era whene IT was nothing more than automation of repetitive data processing is over.  Old IT systems were difficult to use, required scrutinous training, changed slowly were fully defined by static, prescriptive processes which permitted little variation. "IT" was mostly a data dump and retrieval center.

Users had a desktop client software which connected to a central database. The flexibility these systems possessed was in their ignorance of business processes (albeit sometimes with the pain, "We don't have a form field for this").

IT had full control of who had which version of the software and how the data was used - oftentimes, without even understanding what this data actually meant or how it was used.  Business processes were fully part of the business domain and outside of IT scope.

The legacy of this era remains a pool of low quality data and systems which are difficult to understand, maintain and upgrade.

Complexity was on the level of getting servers stable and software to run. Business complexity was neglegible.

Today's IT

IT does data processing more than ever - but the nature has changed.

More and more business logic has been inserted into IT systems, to the point where IT systems are doing actual clerical and administrative work. For example, a modern IT system not only accepts customer data, it might validate the customer's address, credit score, and order. IT systems reject bad contracts, informs the customer when products are out of stock, offers alternatives and even provides discounts, cross-sales, upsales and bargains. And that's just pre-fulfillment.

Such an IT is no longer a dumb data shelf for smart business processes - it becomes more the other way around: IT systems have an even deeper understanding of the business than any human being in the organization.

While many companies still face the complexity of managing their infrastructure, today most complexity resides in automating and managing the business capabilities.

Tomorrow's IT

In the age of "everything-as-a-service", IT infrastructure and processes are mostly automated. "Serverless", client-independent services can be used from anywhere for pretty much anything. Interconnected services route smart, self-correcting requests to achieve their purpose.
Autonomous agents discover and learn rather than blindly act upon pre-defined rulesets.

The IT of the future can do anything we can set our mind on - if we have the right skills and are willing to invest into the right tools. Constraints are either willful ("we don't want to ...") or external (e.g., "we can't afford ...") and no longer technological.

Although the technological complexity of such systems is extremely high, it is self-managed by other technology, allowing IT specialists to focus on creating enabling features and their interconnections.

Where is your IT?

With the above historic summary, you can quickly decide whether your IT is past-, present- or future-oriented.

Many organizations want to have tomorrow's IT, yet they are stuck maintaining and servicing yesterday's IT, so they can't even take the benefits of today's IT.

From an economic perspective such backward-oriented investments are hardly feasible, yet sunken-cost fallacies and fear of the Unknown make them commonplace.

If you're not prepared for the IT of the future, now might be a good time for making some strategic adjustments - improvement doesn't happen by itself, we must work towards it!

Wednesday, January 9, 2019

Setting meaningful goals

Tasks, Stories, Features, Sprints, Products, the company strategy - they all have goals, and each of these goals has an impact on overall success. Beyond SMART and INVEST which are focused solely on the definition of a goal, let's look at some important considerations for in the timespan between definition and achievement, i.e. the implementation phase.

The Goal Factors

Here are six factors which will help you define helpful goals:


In discussions, people shouldn't be talking at cross purposes. During implementation, we need to know whether an action will be progress or distraction to act accordingly.  Clarity also affects how we determine whether a goal has been achieved or there is residual effort.

Clear goals offer little space for interpretation when the goal is achieved - and partial solutions are likely a step in the right direction. Unclear goals cause people to constantly stab in the dark.


A goal should always be so important that success as well as failure have a significant impact somewhere. If there is no impact, other things are probably higher on the list. Significance depends on the bigger picture. For example, a task or a feature are only as important as their contribution to the strategy.

Highly significant goals create a sense of urgency and importance and thereby provide a boost to motivaton.


Goals exist for a reason. Regardless whether a goal describes a specific customer need or a strategic objective, there should be tracibility of where the goal comes from, what it contributes to and who is involved.

Traceability is a two-way street, so goal definitions need to be traceable downward into implementation as much as they need to be traceable upward into strategy.


Every person involved with a goal should be able to relate to this goal. They should be able to figure out their contribution towards success as well as the impact the achievement or failure has on them.

Goals that are highly relatable are much more likely to be achieved than goals which contributors can't relate to.


Goals should mean the same thing from the time they are decided until met. In rhetorics, the metaphor of "Moving Goalposts" describes a surefire way to derail any effort to make progress. A goal should not change. If it becomes different, then that is a different goal.

Constancy reduces waste, as detours are evitable. Any shift in goals turns all activity towards meeting the previous definition into waste.


Goals should be as flexible as possible in ways of achieving a favorable outcome. When a plan doesn't work out, alternatives need to be found without compromizing either the goal or its traceable line in the organization.

When circumstances change, flexible goals only require changes to the corresponding action plan, whereas inflexible goals might cause inefficient replanning and adjustment at multiple levels.

The importance for management

Goals which meet these six factors can be monitored effectively in multiple dimensions because of enhanced transparency in the following dimensions:
  • Success - was the goal met?
  • Progress - are we getting somewhere?
  • Blockages - are we moving?
  • Delays - what affects what else?
  • Waste - are we on the right track?
These items are equally important to individuals, self-managing teams and the overarching organization.

The importance for workers

Goals which meet these six factors will help workers in multiple ways. Working on such goals boosts:
  • Motivation - why is our work important?
  • Alignment - are we talking about the same thing?
  • Creativity - which options do we have to contribute?
  • Performance - how far have we gotten?
  • Accomplishment - what have we achieved?


Regardless of whether you're setting goals for the day, for the Sprint, for a Product or a Project - for a transformation program or for the entire organization, keep in mind that these goals should offer:
  • Clarity
  • Significance
  • Traceability
  • Relatability
  • Constancy
  • Flexibility
Without creating yet another futile metric, goals which are better on these six items will be more likely to contribute more to your overall organizational success  than others.

And most of all, if you miss setting goals - you're losing out both on the factors and on the benefits.

Monday, January 7, 2019

Goal Setting in an agile organization

Is your agile team is on track? Are you making progress? How do you know? Here are some tips to keep in mind.

You will notice in this article that nothing has anything to do with a specific agile framework or even with "agile" in general. Indeed, the remainder of the article will avoid the term "agile" completely. The suggestions are still fundamental to agile transition, because without these things, you're in for a trip to Wonderland!

Take your time and define, step by step, in the order presented in this article, the following items:


Where do you want to go, as an organization? Why does the organization exist, and what will be different because of the work that people do?
"To earn money" or "To pay the bills" won't cut the cake, although that's obviously something a company wants to be able to do. Your mission should discriminate you from the broad mass, giving guidance on things which the company would do and wouldn't do while being simple to remember.

Here are some guidelines when setting up a mission statement:

  1. Length: People need to remember it. Five words - maximum!
  2. Clarity: Provide meaningful guidance and direction.
  3. Breadth: Include everything you really want to - or are already - doing as a company.
  4. Focus: Must allow people to align activity.
  5. Avoid slogans: Must be useful as a yardstick in everyday work - and not just for marketing!


  • "Improving work" is a legitimate mission for a consultancy,
  • "Delivered." would be a feasible choice for a logistics company,
  • "Everything covered" might be appropriate for an insurance.

These statements are broad, yet focused - short and clear and can be used as a discussion point when discerning whether an activity is in line with the company's goals or not.

A mission statement isn't immediately actionable. It's guiding in nature and should rarely change.


From the mission, a small set of strategies should be derived - how do we plan to make this happen?
A strategy is a mid- to long-term plan for moving into a certain direction and should lead to some relevant outcome that is aligned with the mission.

As odd as it seems, this step is often skipped or neglected. Since a strategy is a clear statement of a direction into which we develop the organization, the presence of a strategy is necessary to determine whether you're still on track.
It isn't even necessary for management to define strategy - in many cases, employees have a good idea what strategies they would pursue, but they don't have any means or transparency to communicate this.

Taking one of our above examples, if we have "Delivered" as our logistics company mission, the following strategies might all be valid options:

  • Enter grocery delivery market.
  • Partner with company X and employ their delivery network.
  • Pivot Drone Delivery.
  • Build a Delivery Hotspot Discovery service to monitor and optimize efficiency.

Some strategies might require just a few months, others many years.
A strategy is good when we can tell clearly which set of activities is part of the strategy, when these activities are achieving the strategy - and how the strategy relates to our mission. Ideally, we can also fathom who could be involced and how long it might approximately take.

Strategies still aren't actionable, but they help people deciding for action determine what to do.
Keep the amount of strategies small, as too many dilutes your resource pool and impairs focus. Also, try having more than one strategy as putting all your eggs in one basket is a significant business risk. Two to five strategies are a decent bundle.

Revisit them about quarterly, abandoning those which are obsolete, reinforcing those which are worthwhile and adding one when needed.
Keep in mind: For every strategy you add, you should axe another, lest you lose focus and mess things up.


Strategies aren't equal, and the things we actually want to achieve might differ as well. This is where we get into the realm of setting SMART Goals: Specific, Measurable, Ambitious, Realistic, Time-bound.
We must be able to figure out how much of what we want to achieve by when - and that should  likewise be challenging and possible.

Many companies have trouble with this step because the wrong people do it. Ideally, goals are uttered by the people who will be working to achieve them and verified for priority, plausibility and strategic alignment by management, rather than enforced top-down. Only when management realizes that the workforce isn't able to set meaningful and important goals, should they feel the need to intervene by providing more clarity and context.

All goals are not equal.
Strategic goals might take years to achieve in a stepwise process, operative goals may be met fairly quickly and tactical goals could be succeeding each other in rapid succession.

The importance is that depending on their nature, they're frequently revisited and constantly verified against their alignment both with the strategy and mission - as well as with other goals the organization might be pursuing.

Transparency of goals is important to prevent the accidental pursuit of competing goals as well as enabling collaboration between people pursuing synergetic or overlapping goals.

When goals conflict with each other or strategy, everyone should feel free to have a voice and raise their concerns, as working on such goals would result in a loss of time, money and opportunity.

A problem with goal-setting is that when undergoing change, goal-setting isn't a straightforward action. Larger goals need to be achieved incrementally with intermediate checkpoints and feedback loops - another thing many organizations get wrong. Either they forget to feed subgoals back towards overarching goals, or to act upon information that a goal no longer makes sense.

Goal-setting on different levels should be a frequent exercise, but when a goal hasn't been pursued or seen progress in months, then that goal can be considered obsolete for all practical purposes. Don't bother with these - axe them. The shorter the time between goal-setting and seeing their achievement, the faster the organization can act.


Goals need to be met somehow, so some action must be initiated. Regardless of whether this action is an initiative, a program, a project or even just a small task - it needs to be clear who is responsible for the action and how we can know whether it was successful.

As one action could contribute to more than one goal, or one goal could require more than one action, creating clarity between the relationship of goal and action is essential, although the only people who can do this in a meaningful way are those who set the goal and who will be executing the action. If these people don't know - nobody will!

Since actions are only required to achieve goals, depending on the complexity of the work, it may or may not be important to make these actions transparent. When people's actions could block each other, these people need to communicate. Other than that, actions and their tracking are irrelevant.


Every action should have an outcome - and that outcome can be as intended, or otherwise. It's a good idea to define the intended outcome right alongside the result, in order to assist the execution of the action.

It's essential for those who complete an action to know the intended results and correlating goals, as this is the yardstick for progress. Performance should move away from amounts of action conducted towards results achieved.

Results are the compass for action:

  • When results are moving away from the intended goal,s the action needs to be revisited immediately. 
  • When results are moving towards the intended goals, the action is on track.
  • If an action proves to be ineffective, it needs to be changed.
  • And when the intended goal is met, it may be time to either complete the action - or set another, maybe more ambitious goal.

Results should be revisited frequently and feed into their goals on at least a weekly basis. While "no result because no action" is an acceptable explanation, this is a clear indicator that something should be done in this context:
  • If the result is important, it needs to be prioritized for action
  • If the result has become obsolete, no further action needs to be taken.


Let's return to Alice and the Cheshire Cat for a minute.
If you don't know where you want to go or why you would want to go there, or how you would know whether you have arrived - it doesn't matter which way you take.

You need to have your mission defined ("where you want to go"), so you can state which strategy you want to pursue ("which way you go") and by defining goals with verifiable results, you can even discover whether you've gotten somewhere.

If you lack these three components, you will still get somewhere, eventually - but whether that "somewhere" is where you'd like to be, is a completely different story.

Just like Alice didn't know Wonderland and she had to explore, we often define goals without knowing the way and discover midway that both the goal and our action was maybe not the best choice. Still, we are where we are and have to move from there, so our process of locating ourselves, and determining the next step are essential.

The more frequent and painlessly we can go through the feedback process of Goal-Intention-Action-Result, the better we become at getting where we want to be.

And to close with the Cheshire Cat:
"You sure do that, if only you walk long enough".