OKRs

Two unspeakable Silver Bullets?

There are no silver bullets” wrote the late, great, Fred Brooks. Consequently most writers and evangelists avoid claiming they have a silver bullet even when it sounds like they are claiming just that. I’ve cautioned against silver bullets several times in this blog. I often find myself telling clients “The devil is in the detail.” Meaning: there are lots of things to address and no single big fixes.

Anyone claiming to have found a silver bullet deserves to be faced by scepticism. Still…

I find myself coming back to two solutions again and again. They are the closest thing to silver bullets I know. Even if these are not silver bullets in their own right applying either makes it easier to work the detail and tackle problems.

Yet these silver bullets dare not speak their name. To do so risks endless debate and damaging your own leverage.

Keep reading for the Silver Bullets

Writing this I’m avoiding naming the potential silver bullets because I even feel many readers will stop reading the moment I name them. Please, keep reading.

Both are widely discussed by the agile cognoscenti but both are controversial. Suggesting either may lead people to think you fail to comprehend the situation or are just stupid. Thus in both cases you are likely to end up in long discussions.

Both are disliked by opposite ends of the organizational hierarchy. Both ends are optimistic, and prefer to believe people should be able to rectify problems themselves (the people problem problem again.)

Both bullets are rarely applied with vigour. Perhaps because of the previous points. When I raise the points people plea helplessness, “My boss doesn’t understand.”

Both bullets scale: in the small and large, although they manifest themselves in different ways at different scale points.

Neither is an instant fix but both start to deliver returns relatively quickly. The problem with both is you need to keep the faith and keep applying them for weeks to see a difference. In both cases, people often give up before they see the benefit.

Bullet #1: work Test First

Specifically in technical teams applying Test First coding; whether Automated Unit Testing (e.g. TDD, test driven (first) development), Behaviour Driven Development (BDD) or some other form of Acceptance Test Driven Development (ATDD). Away from code, at team and organizational levels OKRs are implement the test first principle.

Test first will not fix all problems but it will remove a substantial number of problems. That makes managing the remaining ones easier. And as to where the “extra time” comes from, that is easy: the time you don’t spend fixing defects and misunderstandings. Test first is faster than debug later.

I’ve written a lot about test first so I won’t say more just now.

Bullet #2: reduce Work in Progress (WIP)

Most commonly WIP limits are applied through limited columns on a Kanban board or limiting the work taken into a sprint. Done right OKRs limit WIP too. However, reducing WIP requires discipline.

At the higher levels companies and Government entities seem quick to reduce staffing numbers but slow to reduce work. Accepting new “projects” is easy but resourcing them difficult. Rather than prioritise, say “No” and push back on work, everything is taken on. Individuals who push back as seen as pessimists, “not team players” and “obstacles.” Pushing back does not help your chance of getting promoted so leadership ranks tend to be populated by those who accept.

The result is salami sliced people and slow progress across a broad front rather than rapid progress across a narrow range. But, reducing WIP also seems to be the hardest medicine to administer. In fact, I sometimes find myself hiding WIP reduction measures.

As an aside, I feel WIP has gotten worse since the pandemic struck, the move to remote working means every conversation is now a meeting in the diary. Our diaries are now overrun with “Meeting WIP”. An ad hoc 10 minute conversation at the coffee machine is now a 30 minute Zoom call planned days in advance.

WIP reduction is applicable at all levels: reduce the number of pieces of work the individual is switching between, reduce the number of pieces of work teams are tackling, reduce the number of projects a department has in flight, and most of all: reduce strategic WIP.

Next time

There are lots of benefits of reducing WIP so let me ask: why is WIP so difficult to reduce? – that is the question I’ll address next time. So too is Why don’t people Test First?

Finally I’ll just note: I sometimes wonder why I stop being an OKR-cynical to learned to like them. The thing is, I see OKRs as a tool to address both these problems: OKRs are test first, and limiting OKRs is WIP limiting.


Use Blog20 for 20% discount

For both: book Writing and add discounted ticket to Introducing

Why OKRs require a strategy rethinking

OKRs offer a way to connect strategy – high level abstract goal type things – with delivery – low level concrete detailed task level things. OKRs offer a middle level planning. They are replanned often enough to be flexible while lasting long enough to give enough stability to take on bigger, more ambitious work.

As with so much else about OKRs there is a more agile way of going about this and a less agile way of going about it. Connect strategy to OKRs in the less agile way and you end up back at command and control. The give away sign is that OKRs cascade down the company so teams don’t control their own destiny, ambition is neutered and motivation is lost.

Which approach you take will largely depend on the seemingly academic question: “what is strategy?”

Many people see strategy as a one way street. Strategy making and execution is hierarchal with decisions made at the top are passed down. Alternatively strategy can be seen as emergent property of a cooperating network. Strategy is a two way street, each node both informs strategy making and execution is guided by the resulting strategy.

Depending on how you view strategy you are going to implement OKRs very differently.

Is strategy a kind of planning?

Sad to say, the predominant view of strategy is that it is some sort of grand plan. The plan sets out the “place” the company aims to get to (price, position, etc), plus the route for getting there. Anyone who has studied a little strategy will recognise this as the “Porter view of strategy.”

Strategy as planning inherently sees strategists as master planners, all the relevant information is fed into the strategy/planning department. Experts analyse the data and rationally decide what needs doing. The plans are sent out.

This is inherently hierarchical so it natural to use cascading OKRs as the implementation mechanism. But because teams have little say in setting their OKRs motivation is lost and ambition is neutered.

The is a machine like view of organizations, inherently top-down, deviation from the plan, the strategy, is an error. When OKRs do not directly support strategy OKRs need to be changed.

Study a bit more strategy and you will find that while Porter’s view has appeal it is not the only view. There are in fact many different schools of thought on what strategy is.

Emergent strategy is more agile

To my agile mind the “emergent view of strategy” fits better. Strategy emerges over time from the activities of the organization, part planned, part reactive and part backward looking to explain the past. Professor Henry Mintzberg describes strategy as “a pattern of behaviour over time” which chimes with my pattern thinking.

Strategy is a two way street, teams are edge sensors: detecting technology changes, production techniques, putting products in the hands of customers and gathering feedback. This allows learning and adaption. The organization as a whole is a learning entity: discovering customer need and mastering new capabilities. Teams have the authority to act in the best interests of the company and customers. Over time strategy emerges.

When OKRs do not reflect stated strategy it is a learning opportunity. Ask: why do team OKRs deviate from strategy?

Is the team seeing something which the strategists do not? – in which case the OKRs are signalling back from the edges to the centre.

Is the team able to follow strategy? – maybe it lacks skills or capacity, or maybe it is overloaded with “business as usual.”

Has the intended strategy has been clearly communicated? Or maybe there is no explicit strategy?

Strategy, OKRs and agility

OKRs, like other agile tools, are problem detectors exposing opportunities for improvement.

Perhaps obviously, the “Strategy as a plan” view is going to limit agile to a back-room delivery thing because it passes over the opportunities for feedback and centralises decision making. Conversely, the “Emergent strategy” view entirely compatible with devolved authority, independent teams, experimentation and “the agile mindset”.

When teams act on their own initiative the organization will be more agile. When teams wait for instructions everyone is less agile. There may be a price for agility: teams may repeat work, teams may pursue the “wrong” goals but the price of that efficiency is lost agility which costs in missed opportunities and improvements.

If you want high levels of efficiency and believe in planned strategy you will look to decide strategy and align OKRs with the strategy before you do anything else. However, that results in less agility.

If you want to using OKRs and maximise agility then you need to take an emergent view of strategy. In many ways, we back to the Theory X or Theory Y question.


Download Continuous Digital for free when you subscribe for Allan’s updates

Verified by MonsterInsights