Agile

While this blog may not have the big reader numbers of some blogs many of my readers are very loyal – my mail open figures are off the chart! Thank you.

I ignore many of the blogging rules I’ve heard advocated: short posts, tight topic focus, limit topics, keep focus both in the posts and across post. I’ve tried following such rules but it doesn’t last. Its not me.

In my mind you, my dear readers, follow me and my (sometimes) whacky ideas. I like to think we have a “special relationship”. Having said that, I’ll also admit: I write about what interests me, you reads seem to like that!

So I want to share something personal with you. I share it because I’m sure some of you will have had similar experiences. It is important to recognise we are not to blame. Sad to say that no amount of success seems to insulate one from this sort of thing.

About two years ago I got involved with a toxic client. I won’t go into details but in retrospect the client’s manager was a bully. I’d not been working with the client very long when I saw there were problems. I decided to tackle the problems face on and sat down with the manager concerned in an effort to resolve them.

Rather than resolve them I brought them to a head. The manager turned on me. In classic bully fashion it was all about them, how hard they worked, how many problems I created for them, the problems they faced. So I suppose I did resolve them but just not the way I wanted to! There then followed a few weeks where they wanted me to sign an NDA and I refused. That itself is a story but ultimately I called their bluff.

If anyone offers you an NDA to keep quiet remember: they want you to keep quiet for a reason, you have power over them. If they are clever they will realise that offering you a sum of money and then taking it away is probably more likely to make you share your story and it makes them look worse.

Anyway, this was all really bad for my mental health.

I had some counselling at the time and thought I had managed it but actually I hadn’t. It had completely undercut my confidence. I was failing to function properly. It dragged on, weeks and months.

I was slow to realise this but then two things happened. One of you, yes you readers, came to me with an idea. Something which I’d never thought of, it got me back in harness. Thank you.

Once I started working again I quickly realised how I wasn’t over the bullying incident. I was still carrying a lot of baggage. It wasn’t just the recent bullying, I was bullied at school. So I went back into counselling for several months.

In counselling I also came to realise that much of my internal logic stemmed childhood: both the bullying, the way schools treated me and the (now obvious) fact that my neurodiverse dyslexic brain doesn’t see things the way it is “supposed to” – I don’t share the canonical view of, what, some many other.

Take Project Myopia and #NoProjects for example. I’d seen Projects as crazy for years, it was only when Mary Poppendieck said the same thing over dinner in 2011 that I realised I was not alone. Slowly I started to say publicly what I’d only thought privately and ultimately write the book.

At the time my views on projects were career limiting. Not only could I never be a Project Manager but nobody who was doing a “project” (which was everyone back then) who checked out my social media would hire me.

But, I am not the only one who thinks like this – many of you readers do too! It is because I think differently, because I will say these things that I am immensely valuable and I suspect, why you read this blog.

So my dyslexic brain if both a curse and a blessing,

Back to where I am now.

I’m actually in a pretty good place now. My professional life is very different to where it was two years ago and I don’t think its every going to go back. I’m not sure what happens next, I have a couple of ideas but I’m in no rush to change.

Anyway, I wanted to share this with you for two reasons.

In the last year I’ve told several people about my mental health problems and I’m often told in return that they too have had problems. It seems a very common problem for people who have worked as agile coaches to suffer mental health issues as a result of the work. (I might talk about way that could be another time.)

Second, anyone can have mental health problems, and they are nothing to be ashamed off. In truth I’ve had mental health problems on and off my entire life. It is not because I am weak, it is because of things that happened during my childhood I had no control over – like being dyslexic.

Second my professional pivot leaves me wondering what happens next with this blog. I’m not giving up, I’ll keep blogging. I wanted to say thank you to my loyal readers, knowing some people value what I write has meant a lot to me during this time. I’ll keep up non-canonical ideas coming.

I might be known for speaking my mind, being honest and wearing my heart on my sleeve but there are some things I try to avoid talking about. There are time when I consciously bite my tongue.

Perhaps because I brought down the wrath of project managers with #NoProjects all those years ago I try my best to keep my mouth shut when people ask me about Change Managers and Change Management*.

A few years ago a contact asked “What is your chagne philosophy?”

Inside I thought “I don’t have one! Change is not a thing” but rather than say this I waffled. Since then, from time to time, I have glimpsed my change philosophy out of the corner of my eye. Let me try and break it down…

Fundamental my change philosophy rests on the belief that

People don’t resist change, they resist being changed.

Take those two parts separately.

People actually like a lot of changes: when you get a new mobile phone or other gadget, when you get a pay rise, when you change your location for a holiday and so on.

That is not to say people like every change but the changes people don’t like – and thus resist – are largely the changes they have no control over. Thus, if you start from a position that change must be done to people then resistance becomes a self-fulfilling proposition.

Therefore….

Enrol people in change, don’t impose change on people, respect them and make changes which they welcome.

(I almost wrote “put them in driving seat” there, while that conveys what I mean its not entirely true as in most cases there are multiple people on he receiving end and they can’t all be drivers. The moment one person becomes a driver everyone else becomes a passenger and that is exactly what I don’t want.)

Remember …

Change is a leaning process, some people learn faster than others and it is difficult to know what you will see until you have learned. So don’t plan too far ahead. Indeed, one person’s far sightedness can be another’s learning inhibitor.

Because …

Change is not the objective, focus on the outcome.

Talking about change in the abstract – a change programme, a change manager – is a diversion from the goal you are trying to achieve. Change is a means to an end but when we talk about change itself as a thing in is own right it becomes a distraction.

When people are part of a change which benefits them, i.e. makes their life better or supports something they believe in, then success breads success: focus on the outcome, take small wins and use them to motivate further action.

It flows from this that Change Managers, Change Programmes and even Change Initiatives create the most of the very problems they set out to address.

Instead, focus on the outcome you want to achieve and ask people to help.

Another loose end to pick up…

When OKR setting I’m very keen that everyone involved thinks “What is needed?” – more specifically, “What do our stakeholders/customers/users need?” or just “What will add value?”

The aim is to park the “can we do this?” and “how long will it take?” because to answer those questions you need to know what you are doing. And when you answer those questions you start to ask about details, and this all becomes a long conversation, especially when people doubt the information available (i.e. they don’t trust it or don’t want it to be right).

Getting such information also introduces a forward tail where with upfront pre-work. That creates scheduling problems and complicated everything.

Instead you want put customers and outcome first, assume that in the twenty-first century with technology coming out of our ears it is possible to do something which will move towards the objective. What that something is, is itself open to questions but something can be done. Even if it doesn’t solve the problem entirely.

Rather than set an objective by reference to what you can do, set the objective by reference to what is needed.

Remember: to any problem there is always more than one solution. The solution you choose will depend on other parameters like resources and funding. There are always options.

The OKR 2-step

Step 1: set the objective, decide the outcome you need to advance on

Step 2: think/plan/design how you will go about meeting the objective (or at least moving towards it)

Step 1 might be in the morning and step 2 in the afternoon. Or maybe step 1 happens this week, there is a week of feedback and refinement, then step 2. Just separate the discussions, allow your brain to think differently in each.

Of course it is entirely possible that when you come to do step 2 you decide that step 1 and the resulting OKR needs revisiting but that is a worst case scenario.

In truth it is always going to be difficult to completely separate the “what shall we build?” from the “can we build it?” and “what does the solution look like?” questions. If you don’t try you certainly won’t.

I apply this 2-step approach whether setting OKRs which are ambitious (moonshot, 10x thinking) or predictable (guaranteed delivery). When aiming for predictability its gong to be even more difficult to separate the what from the how but again try.

I mean, what could possibly be wrong with putting the customer first?

In recent posts about OKRs I promised to say something about eggs-within-eggs, I also promised to talk about the OKR 2-step. So, at the risk of creating a OKR mini-series here…

Objective egg

The objective – or outcome with my OACs renaming – is a goal, a target, something to aim for, and outcome you wish to bring about. But, as much as I’d like that outcome to be the end state in itself, more likely, it is part of a broader, longer, larger goal.

The thing about goals is they are almost always wrapped in other goals. Look at sports, like football: you score goals, scoring goals is the aim. But actually, those goals are are themselves part of a bigger goal: winning the match.

But winning the match is not the final goal either. Winning the match may help the team win the league this season. So the real aim is to win the season – or some other contest.

But even winning the season isn’t the ultimate goal. The team wants to continue winning, and to continue winning they need to make money. Even winning the season is a goal nested inside bigger eggs.

Now goals aren’t always so well aligned. The owners of the team may aim to make money, so although they want the team to win their make money goal can some times conflict with the winning games.

On the whole the individual players will have aligned incentives: win the match, be crowned the best player, bag a bonus. Possibly a player has other incentives, one recovering from an injury may have other concerns. Just possibly, a player has been offered a lot of money to throw a game, so they may be pursuing a personal goal which conflicts with the team.

Goals work best when there is alignment, small mis-alignments may not be an issue but big misalignments can be.

Misalignment probably isn’t nefarious

The same is true in our work. Taking a Machiavellian view you see lots of conspiracies for team and individuals to pursue alternative goals. However, I tend to the see goals diverging for more mundane reasons.

Goals aren’t communicated clearly: leaders say one thing but workers hear another.

Works see divergence between what stated goals and their actions.

Conflicts between different goals aren’t spotted, or nobody listens conflicts are spoken, e.g. cost effectiveness is a goal but so too is innovation.

Or simply, goals aren’t prioritised sufficiently: everything is priority #1, team A spend their time on goal Y while team B on goal Z and team C try and do a little of everything an get sidetracked somewhere else.

Try this at home

Try drawing your goals as one of my egg diagrams – like above. Start with your immediate goals, then the goal they exist within, carry on going for as many layers as you can identify.

Then check your company website: what are you stated goals? or missions? What about your values? Do they all align?

Now show this to others and see if they agree with your analysis or see things differently.

This is why I advocate a challenge-respond-discuss protocol, it is feedback. Leaders set out the bigger goals and and challenge, ask, teams to contribute. Teams respond (with OKRs) and then the two sides discuss and give feedback, they iterate towards goals which everyone agrees.

And this is where the outer eggs become more relevant: by understanding the different eggs and how they need to align all can work to build smaller goals they support bigger goals.

By not giving orders leaders test their own communication. If teams come back with goals that don’t align, or don’t seem to build towards the leaders goals the question is why?

Is there something the leader didn’t know?
Did the leader’s communication lack clarity?
Or maybe a team member had a insight the leader should know about?

If the team members misunderstood who’s problem is that? And more importantly, what can we do about it?

By letting team members decide for themselves not only do you enhance motivation and bring their knowledge into play but you get to debug your own thinking.

The thing is, you don’t get alignment by telling people. Simply adding OKRs to your way of working does not deliver alignment either.

Rather, you get alignment because this approach shows you where alignment is missing or where conflict exists. Because each goal is articulated and can be compared with others. Because these are seen by different people.

In short, you get alignment by working at it.

Anyone mind if I rename OKRs? s/OKR/OAC/g

Rrather than call them Objectives and Key Results I wish, o how I wish, that I could rename them OACs – Outcomes and Acceptance Criteria

Why?

Well, two, or maybe three reasons.

First off the terms. There is an increasing emphasis on Outcomes in a lot of discussions and management teams. Indeed, if you look beyond the “agile is dead” click-bait many former agile advocates now talk about “outcome based working” or some variation. Nor is this confined to those formerly known as “agile coaches.” Indeed “product model” thinking revolves around the same idea. While many in the product community seem allergic to agile they pursue to the same idea.

This raises the question “what is the difference between an objective and an outcome?”

Personally I see little difference. Thus I define an objective as “an outcome you wish to bring about.” You might think of “objective” as forward looking while “outcome” is backward. The objective is a target, an aim, a goal, a outcome is the realisation.

Tell me again: Key results?

When it comes to “Key Results” there is some ambiguity. I don’t think “key results” intrinsically speaks to people. People don’t automatically know what is key and what is a result. At best it requires explanation, at worst it is interpreted erratically.

Perhaps because of this key results themselves are often a little fuzzy. Time and again key results are little more than a to-do list: a work breakdown or plan of action. Now I’m not saying you shouldn’t have a plan of action to achieve your outcome (objective) but key results is not the place. (Another blog I need to write, “The OKR 2-step.” I talk about it in presentations and training but haven’t blogged about it.)

Key results are the key – the important, the main, the principle, chief, first and foremost – results, the consequences, the effects, the measurable differences, you realize when the outcome is met.

At the same time key results are measurable and therefore testable. Thus in test first management the key results are the acceptance criteria.

Outcomes and Acceptance Criteria, OACs

This rename has two more benefits. Because this interpretation highlights test first management it continues the test first story which began with automated test first unit tests (TDD, Test Driven Development). Then Acceptance Test Driven Development (ATDD) into Behaviour Driven Development (BDD).

That might seem like a small benefit but in positioning OACs closer to the agile way of thinking creates distance from the past.

One great thing about OKRs is that they did not appear out of nowhere. By the time they hit the mainstream there was already a body of work discussing them. Plus at least two well-known case studies. This helped their adoption by teams and leadership, and, for better or worse management consultancies who are keen to push them.

But, at the same time it brought baggage. I really dislike some of the writing on OKRs which is too “rah rah, win one for the Gipper”. Or (to use a word I dislike) its outright “boosterism.” While that can be good for rally-the-troops it is also short on detail (how to) and sounds like another silver-bullet.

Some of the older writing on OKRs, that dating from the 1970s, actually propagates the mistakes I see in key results: like the to-do list tendency. It also comes with a command-and-control assumption that manager knows best. Under my interpretation of OKRs they are used more as a challenge-respond-discuss protocol.

So, why not?

As much as I’d love to replace OKRs with OACs I don’t think I’m ready to do it. Thats because, for all their “faults” OKRs are pretty good. That legacy has oiled their passage into management circles. Similarly, despite the flaws in the older writing there is good advice in there.

Still, I’ll continue to push my interpretation, dream about renaming them and continue talking about Objectives and Key Results.

“Should I rollover OKRs which the team didn’t meet?”

No

“If I do rollover our OKRs, should I update them or keep them the same?”

Always update them

I recently spoke to an American health care provider about OKRs and backlog free working when these questions came up. This is not the first time I’ve been asked about OKR rollover so I thought I’d post my answer her.

Basically, when you start writing OKRs start with a blank sheet of paper.

A blank sheet has no carry over work. You are going to ask “What are the most important things we should be working on in the coming period?”

Do not start with carry over work, do not come with assumptions, do not make promises in advance. You have never set objectives with these people and this point in time before.

You probably set the previous OKRs 3 months ago. So let me point out the obvious: that world no longer exists.

Sure the last 3 months – January to April 2025 – have seen a lot of changes (understatement!) but every 3 months see change. Three months ago you probably agonised long and hard about what were your most important three (or maybe four) things that were worthy of OKRs.

Hopefully you have achieved these OKRs and have the outcomes to show for. But if not… do you really like in the same world you did 3 months ago?

Why would your priorities 3 months ago still hold today?

Is your business so stable that priorities from 13 weeks ago are unchanged?

Do your customers want the same things?

Are your investors and executive team relaxed about the market, cashflow, ROI and everything else?

Have your competitors, and government, really done nothing?

Count your blessings if you live in such a world. Lets pretend you do.

It is entirely possible that you are working towards some even bigger goal, something that does take more than 3 months to produce – landing someone on the moon, creating a new technology, gaining a certification/qualification, or some other big thing.

That is good, that is a bigger goal – the next level up, it might last a year, two years, 10 years or longer. That goal deserves articulating in its own right and while it remains your bigger goal all your quarterly goals should contribute towards it.

(Although I talk about the nested-egg and OKRs I haven’t posted about it here, I’ll correct that soon. In the meantime check out my Employees: growth driver or cost to trim post were I mention them.)

Now, suppose that the big thing you wanted 3 months ago is still really important to you. But, suppose you didn’t complete the OKR. There is work outstanding, or you didn’t meet all the acceptance criteria. Entirely possible.

Do you carry it over as is?

No.

Even if you didn’t complete it you probably did some work. If it is no longer important write it off, don’t fall for the sunk-cost-fallacy.

Assuming it is still important evaluate where you are and reflect it to reflect both the work done and what you have learned in the last 3 months.

You might be half way to your target already, in which case you might want to increase it. Or maybe you realise how hard the target is, in which case you might want to relax it.

Either way you will have learned something, revisit the OKR and ask: is it still worded the right way? are the targets right? should we add more key results or delete some?

So in short: do not, never, ever, look at an OKR and say “We missed it so cut-n-paste it for next time.”

In the early days of Agile this approach was called “Time boxing.” Work which wasn’t finished at the end of the time box was either released or abandoned. Over the years the industry has relaxed that understanding and today “time boxing” has been diluted to mean “a period of time.”

OK, I get that 2 week cycles are tough, I get that sometimes work flows beyond the sprint, I get that abandoning work is tough.

It is in working in time boxes, be they 2 weeks or 3 months, that we get good at working in time boxes. They make our lives difficult to force us to think, revaluate and learn. We get better at it the more we do it.

So please, lets not unbox OKRs: 3 months is a long time. Just ask any politician.

As I was drafting my Priority #2 Problem post I could hear readers in my ear saying “You need the Eisenhower matrix – divide work into urgent/not-urgent and important/not-important.” So, a footnote, the problem with the matrix…

While undoubtedly useful for Priority #1 problems – those which are clearly important and/or urgent – the Eisenhower matrix has, at least, three issues in this context.

Firstly, the matrix is binary: things are either urgent or not urgent, and important or not important. Life is seldom that simple. There are usually grey areas: is this urgent? or can it wait?

Then when all the urgent and important things are done and taken away how do you decide between the not-quite-so-important and not-quite-so-urgent? Or maybe between the, “might be urgent” and “might be important” and the “soon to be urgent” and “someone else thinks this is important?”

The search to determine which of several possible work items is the most important and/or urgent itself becomes a costly diversion. Priorities #2s are not so important or urgent that they must be done NOW but benefits are lost when left undone (remember time-value profiles). When working alone you can’t delegate them, and even if you can the effort and/or coordination to delegate them is more than actually doing them.

Second, the Eisenhower matrix has no concept of time. It is a matrix for making decisions were decisions are made and you move on. When there is work to do then making the decision is the first step. Once the decision is made to do something there is real work be done.

That means that doing one thing precludes the others: having made a decision to do A other items, B, C and D, must wait, so each decision carries an opportunity cost. Doing A means not doing B, C and D – or at least not doing them right away.

Plus, the time spent doing A means there is time for doubt (“maybe B was really more important?”) and change (“Emergency – we need C”).

Again, this problem is particularly acute when solo-working although you see it in organisations too. The longer it takes to do work the more time there is to doubt to enter the picture, and the more time for some risk to materialise.

Finally, one problem which doesn’t happen do much when you work solo: what is urgent and what is important are subjective.

In an organisational setting one person may think project A is important while another thinks B is more important than A and third thinks C should be the priority. Finding time for these three people to meet and agree retracts from doing.

Costs of the Priority #2 problem

First is the cost of omission: valuable things don’t get done because more valuable things crowd them out.

Second is the cost of carry: the multitude of should be done wears us down. Individually this manifests itself as cognitive load, your brain knows something needs to be done but you can’t do it. Organisationally it complicates decision making. In both cases it leads to more work and delays trying to decide between priority 2s

Third is the cost of delay: when these things do get done they are less valuable than they would have been if done earlier because the benefits are delayed.

An arbitrary, random, choice between options can be the best decision because it saves time and costs of rational decision making.

Searching for the best option is a fools errand: far better to set a bar and accept everything that passes it. Then optimise the doing rather than argnonise about the best thing to do.

Motivation to do work can be more important than rational decision making. (If you do the one you really want to do first then you will break the deadlock, deliver some value and be ready for the next sooner.)

Be prepared to go into debt to do these things: if you only do what you can afford (money or time) then these things will never get done, their benefits will never get realised and the world will not advance. So if they can meet a hurdle rate, if they makes sense to do, then don’t be worried about borrowing money (or someone else’s time) to get them done.