Posted on

The difficulties of cascading OKRs

Allan Kelly from Allan Kelly

I almost despair when I hear people advocate cascading OKRs: the idea that someone, some team, some central planning department, can set OKRs which then flow down the organization with each “lower” group implementing some small part of some “higher” ask. What could be more waterfall like?

I admit, when I started working with OKRs I kind-of-expected to be shown the OKRs of the “above” before my team wrote theirs. But when I thought about it, and the more I thought about it, the more I realised if you did do it that way then it is decided unAgile. How can a team be really autonomous, self-organising and self-managing if they have goals handed down to them?

There was a point when I was wracked with self-doubt: am I interpretting OKRs differently to the rest of the world? How do I reconcile agile and cascading OKRs? What am I missing? – but, when you look around, I am not the only one. In fact, if you read, watch and listen to OKR commentators the majority agree with me: the teams delivering OKRs need the latitude to set their own OKRs.

Reconciling OKRs with agile is far from the biggest problem. In fact there are, at least, two bigger problems, one concerns team motivation. Can a team ever be motivated to do something they have no say in? Perhaps some can, I can’t and I know others who don’t. At the very least team members need to be asked.

Motivation becomes especially problematic if you want OKRs to be stretching. If you set someone a stretching goal and ask them to hit it without involving them then don’t be surprised if they shrug their shoulders.

Still, we haven’t got to the biggest problem.

The biggest problem with OKRs is not the metaphysical issues of motivation and whether one is truly agile or not. The biggest difficulty is simply: cascading OKRs are not practical.

First think about the timetable.

If every team is waiting for the team above them to issue OKRs before they set their own then you have a delay built into the system. And the more levels of hierarchy you have the greater the delay is going to be.

For example, suppose you have an executive team, and middle management team and several delivery teams. Then each cycle the exec team need to set some OKRs, once they have set their the middle management can set theirs, and then the delivery teams can set theirs. At each cascade point there needs to be communication, and each point creates the possibility of misunderstanding and mistakes.

Setting OKRs isn’t instantaneous, I think you need about a week to have a think, reflect overnight, iterate once or twice but, if you are well practices, and don’t hit any delays, you might do it in two days. Either way it is going to take at least a week, and possibly three, to get all three layers set. And if anyone runs late then it has a knock on effect.

I’ve heard it said that the Key Results of higher levels become the objectives of the next layer down. The key results of this layer the become the objectives of the one below them. But that assume that the OKRs themselves are a series of “items to do” and that each objective is made up of several pieces which are themselves things to do.

Sure, it sometimes happens that way. I may even have been guilty of interpreting them that way sometimes. But these days I see Key Results not as small pieces of work which, lego style, build into a bigger objective but as Acceptance Criteria: the parameters which the outcome needs to satisfy.

Now to some degree acceptance criteria can be translated into work items to do, and vice versa, but not always. Consider this:

Objective: Improve overnight batch processing to save 10% of work processing costs
Key result #1: Shorten batch processing time by 1 hour so staff do not need to wait for run to complete in the morning
Key result #2: Reduce false positive alerts by 100 per day so that staff waste less time

Now these key results could be packaged as individual work to do but perhaps they are the same piece or work. Perhaps a database upgrade could address both issues in one go. Which path you take is a design decision.

Seeing key results as acceptance criteria changes them from work to do into bounding conditions.

In Succeeding with OKRs in Agile I advise against having domino key results: don’t set key results so that failing to hit one makes others impossible to hit. So, for example, if the DB upgrade had been added to that previous example as key result #1 then the team would have been committed to doing it. And if the upgrade had failed then the other key results would have been lost. Leaving it out gives the team the decision on how to proceed: the people doing the work decide the best way of meeting the objective.

That advice is given within teams but it also applies between teams. If, the Middle Management team require three lesser teams to deliver work to build their own objective then, if any one team fail the middle management team will not only miss one key result but will therefore miss their objective.

Done like this the OKRs become fragile and a dependency nightmare. That will have two effects, first more time will be needed when setting OKRs to identify and mitigate the dependencies, then more time will be needed to manage the dependencies. Progress will only occur at the speed of the slowest.

Second, these problems will encourage people to play it safe and not set stretching and ambitious OKRs. Predictability and safety will be prioritised.

Now if we take the alternative approach and each team sets its OKRs independently then the time lag is removed, teams set OKRs in parallel and if someone is late it doesn’t matter. Dependencies may still exist but they have not been baked into the OKRs so teams can put effort into removing dependencies (reducing coupling and increasing cohesion) rather than putting that energy into managing the dependencies.

So, while we might argue about whether OKRs should, or should not, cascade down; and while we might argue about the psychological effects of being given an OKR by another, simply remember: cascading OKRs mean setting OKRs is going to be more complicated and take longer.

Photo by Alexander Hipp on Unsplash

Subscribe to my blog newsletter and download Continuous Digital for free

The post The difficulties of cascading OKRs appeared first on Allan Kelly.

Posted on

Class war in the modern workplace

Allan Kelly from Allan Kelly

Writing about “The knowledge worker” in The Age of Discontinuity (1968) Peter Drucker offers this insight: the knowledge worker sees themselves as a skilled professional, or “white collar” to use an old term. To this end programmers, marketeers and conference producers see themselves as akin to doctors and lawyers.

But, Drucker says, these professionals are still employees and are seen by their employers as “workers” more akin to the “blue collar” factory employees of years gone by. I’ve long found it ironic that many contractors like to see themselves as entrepreneurs and small businesses while their clients may well see them more as casual day-labourers who can be hired and disposed of with little thought.

Quote from Peter Drucker book
Age of Discontinuity “The

Look at it like this: once upon a time the majority of employees would be working on the factory floor, their hands would get dirty. The work of the manger was to optimise both the work they were doing and the way the work was done, employees were probably not encouraged to think too much.

Today is the age of mass knowledge work – at least in developed western countries. The majority of employees type at keyboards and spend all day talking to others about ideas. Their hands stay clean.

Look at the qualifications people hold: in the past blue-collar workers might have a skill, many were “unskilled” or “semi skilled. Workers “trade” might be learned via an apprenticeship which involved observing and doing the work. Today we live in the age of mass knowledge work, the bulk of the workforce are not factory workers or dock labourers but educated analysts, programmers, accountants and such.

Modern blue-collar workers are overwhelmingly degree educated and do expect to have a say in their work – both what is done and how it is done.

When I visit clients I sometimes see – or rather hear – this explicitly when managerial types talk about “the factory floor” or “engine room” when they mean the offices where IT staff work. You see it too when teams are treated as “feature factories” and measured on how many “user stories” or “story points” they complete and how fast the burn-down chart burns down.

There is a mismatch in the way workers view themselves and the way the managers view the workers. This mismatch in views becomes a misunderstanding and can escalate into conflict.

Workers advocate replacing management with “self managing teams” and managers look to replace programmers with with automatic programming, “programming through pictures” or lately “lo code” solutions. Rather than resolving the conflict it becomes an existential fight. Sometimes it can even look like a modern class struggle between workers and employers.

There are no silver bullets to this conflict. Both sides needs to respect one another and we need to find a new understanding of roles.

One of my favourite takes on this dilemma comes from Tim O’Reilly. In an essay entitled “Managing the Bots That Are Managing the Business” (2016) he suggests that the true workers of today are the machines: it is the factory robots that assemble cars, take our online orders and increasingly do all the “heavy lifting”. The managers of these machines are the people who instruct the machine what to do and how to do it. Most obviously programmers but also the many who work use digital technology to instruct a machine, e.g. a marketeer who schedules tweets, or customer service agent who scripts the chat-bot.

Either way you look at it the fact is that modern blue collar workers need more of the skills and knowledge traditionally reserved for managers: they need to understand the profit and loss, plus they need to understand business goals and strategy and appreciate the consequences of their actions. And it means the white-collar managers of the managers need to respect the knowledge workers as peers rather than hired help, they need to be explain business goals, strategy and be open about the business.

It sometimes feels as if the “class war” of the early twentieth century is still with us. Only now it is not blue collar workers fighting white collar but white collar workers fighting between themselves.

Subscribe to my blog newsletter and download Continuous Digital for free

The post Class war in the modern workplace appeared first on Allan Kelly.

Posted on

Focus is not divisable so limit you OKRs

Allan Kelly from Allan Kelly

From time to time I hear about teams who have 8, 9, 10 or more OKRs in a quarter. That is just plain wrong. In Succeeding with OKRs in Agile I suggest 3 Objectives per quarters each with 3 key results. When I hear the cries of pain and people twist my arm I compromise on 4 objectives and about 4 key results.

Now those numbers are MAXIMUMs, I’d really like fewer, and I’ve heard of teams which have just 1 – yes ONE – objective per quarter. I’m itching to try that with a team.

Sometimes people respond and say: “Arhh, but we have a big team, I agree with 3 being the right number for a team of six but we have a team of 16 so surely we could have more objectives?”

But actually, when you have a bigger team you have a bigger problem and hence even more reason to limit the number of OKRs.

Part of the power of OKRs is that they create and maintain Focus. Having agreed and stated outcomes to work towards gives individuals something to focus, it gives team members – and particularly product owners – a reason to say No when more work appears. It keeps the team honest when looking at what needs doing and deciding how to spent their time.

New options to learn about OKRs and Agile

Focus is not divisible – devide your focus and you no longer have focus. When you have a bigger team you have more need for focus rather than less. One could even argue that that as the team grows the number of OKRs should reduce not increase.

Bigger teams, because there are more people, struggle more with focus than small teams. On a small team the lack of capacity forces trade-offs and brings people face-to-face with limited capacity. On a big team its easy to think one or two people can go and do something different, or even for individuals to hide.

By the way, this applies equally if you extend the OKR cycle: setting OKRs every six months rather than every three should be a reason to reduce the number of OKRs rather than increase them.

Once upon a time I worked with a team that had real focus problems: teams members found little overlap in their work. Consequently there were seven or eight OKRs each month. That was itself information, when you looked at the OKRs they were disjoint, the team was not focusing because it had three – or four – very different work streams and the people on the team had different skills.

The solution was to split the team into three mini-teams each with their own OKRs. One could argue that the full team got more OKRs but what happened was that each mini-team could now focus and work towards their goal with focus, with less distraction and greater purpose.

This keeps things simple – the Rule of Three! – and keep things focused.

Subscribe to my blog newsletter and download Continuous Digital for free

Photo by David Travis on Unsplash

The post Focus is not divisable so limit you OKRs appeared first on Allan Kelly.

Posted on

OKRs workshop, tutorials and free stuff

Allan Kelly from Allan Kelly

Two opportunities to learn more about OKRs. Both based on Succeeding with OKRs in Agile.

Implementing OKRs in Agile

24 February: 1-day online workshop, hosted by iLean in Belgium and open to all.

Combining OKR and Agile

Online tutorial series – this is a mix free and paid for material.

You can buy the tutorials individually or as a bundle. Subscribing to the bundle is much cheaper and gives access to new tutorials as I add them. My plan is to add one new tutorial each month.

Use the code blogreader to get 20% the paid elements.

The post OKRs workshop, tutorials and free stuff appeared first on Allan Kelly.

Posted on

Practical tips or mindset change?

Allan Kelly from Allan Kelly

How many books on your bookshelves have a number in the title? Specifically a list of X things. Such books sell, blog posts of a similar ilk get read.

“50 specific ways to improve your programs”

“97 things every dog walker should know”

“10 practical things every Scrum Master should know”

“51 tips to improve your requirements”

Small, specific nuggets of information, best presented as a list and advertised as such. No grand unifying thesis, just “75 things”. The closest I have ever come to this was “Little Book of Requirements and User Stories” which was my best seller and would have sold more if I had called it “16 tips to improve your User Stories.”

However, most of my books aren’t like that. Most of my books contain a big idea – at least one big idea. The whole book sets out to explain that. Business Patterns does say “38 Business strategy patterns” but really the books big idea was “Apply pattern thinking to business strategy”. In retrospect it would have sold better if I had called the book “38 Business strategy patterns” and put the pattern thinking stuff as an appendix.

Regular readers might notice that my blogs follow a similar pattern: mostly long thoughtful pieces which try to build an argument, few practical posts thrown in once in a while. Despite knowing I should write more short practical pieces (to boost readership) I keep failing.

Why?

Two reasons.

Sometimes those “short practical tips” seem so trivial, or so obvious, that I just assume everyone does it that way and everyone sees what I see. They are so small and so “obvious” I don’t see them.

But more because I see value in those long pieces. I see them as “philosophy” pieces, they are about how to see the world, how to comprehend what is going on, sense-making. Quite often I will wrestle with balancing forces, how one force pushed you one way while another pushes you another. The right course of action is about balancing those forces and what is “right” may be different at different times. (Thats a pattern thing.)

It might be better if I called those “Mindset” pieces. They are about preparing the mind to see the world in a particular way. Conditioning you for agile, perhaps.

To me those Mindset pieces are more important because they shape the way you respond. In the complex world in which we live few decisions and few courses of action can actually be boiled down to a simple “If this Then do That”. Instead, the thousands of small decisions you make each day are informed by your mindset (philosophy) of how the world works and what will happen if you make decision X instead of decision Y.

Especially for those working in management, it is your mental view of the world that shapes your decisions and relationships. I’m sure somewhere out there is a “50 practical tips for better management decisions” book but in truth there are so many variables, unknowns and ambiguities that you can’t boil the world down like that.

Thats why, while everyone is short of time and wants “10 practical tips” to fix a problem right now it is more important to spend time really challenging your own thinking. Change can only really become permanent when people change their actions and decisions without thinking each time, when people can make decision #563 today congruently to everything else not because they read it in book but because that is the way their mind works.

Our constant search for “quick answers” can mislead us, we might get a quick answer but we aren’t necessarily building our long term capability.

In Succeeding with OKRs in Agile, I tried hard to write a hands-on-practical tips book. I failed but in failing I did better than I would have done without trying. I very deliberately kept the opening chapters short and quickly moved into “practical tips” (mainly about writing OKRs). Almost all the mindset philosophy was pushed later in the book. So far sales suggest I got it right.

So, even as I strive this year to write more “10 practical tips” blog posts I expect I’ll have more philosophy as I put the world to rights!

Subscribe and download Continuous Digital for free

The post Practical tips or mindset change? appeared first on Allan Kelly.

Posted on

Team Retrospective cards are back, and better than before

Allan Kelly from Allan Kelly

Team Retrospective cards

Team Retrospective cards are back on sale

Agile Stationary have given retrospective cards a new home and are handling all the sales and logistics. That means everything should be slicker and export to anywhere in the world should be hassle free.

Agile Stationary gave the cards another print run and in the process enlarged the cards slightly. So while they can still fit in your pocket they are a bit easier to handle.

To mark the occasion Agile Stationary are offering a 20% discount to blog readers, use the code TEAMRETRO20.

Subscribe to my blog newsletter and download

Continuous Digital for free

The post Team Retrospective cards are back, and better than before appeared first on Allan Kelly.

Posted on

Can you keep Agile and OKRs seperate?

Allan Kelly from Allan Kelly

“I’ve been told to keep agile and OKRs separate”

The first time I head this I was surprised, “missed opportunity” I thought but then, as I thought about it more, the more I realised that it was impossible.

Start with the OKRs: OKRs are about deciding what to put your time and energy into. OKRs are about the big priorities for your organization and team. The more I’ve spent time with OKRs, the more I’ve come to see them as the management method rather than a management method among many. Let me caveat that lest it sound arrogate: management within an organization.

The management approach

There are many management approaches out there: strict time-and-motion were workers time is schedule to the minute by experts; complete devolution giving employees free rein and managers (if they exist at all) only exist to coach. And there is everything in between, including project management which attempts to define the start and stop dates in advance. At this level OKRs are one management approach among many and organizations are free to choose which they follow.

Even combining traditional HR performance review processes with OKRs can lead to ruin. Once compensation is conected to OKRs people become incentivised to stay safe by setting OKRs which bring rewards, i.e. not ambitions ones that might be missed.

Running any other management method in tandem with OKRs risks jeopardising both. So if you choose OKR then follow it all the way, call it “Extreme OKRs” if you like.

Just try imaging agile as something separate to your OKRs: you set OKRs and then you run iterations. What are you delivering in the iteration? Surely iterations are delivering progress against OKRs?

I suppose you could have a backlog of work to do (Track A) and some OKRs to work on as well (Track B). Track A and B might lead to different places or represent different work to do. Leave aside potential conflict for a minute, think about how you divide your time.

More WIP, fewer results

Agile teaches that work in progress should be minimised, but now in this example there are two sanctioned work streams. Maybe we could ring-fence work: Agile in the morning, OKRs in the afternoon. I find it hard to see that working well.

Maybe A could be the main stream and B other a “best efforts” / “spare time” stream. But, if both A and B are important then why leave prioritisation be left to the worker? It smells a bit of leadership abdicating responsibility for prioritisation.

It is a fantasy to think that workers can focus on delivering the backlog and in their “spare time” deliver the OKRs. If your workers have copious amounts of spare time then something else is seriously wrong. It is easy to overload workers, and thereby create problems further down the line. People will burn out, goals will be missed or goals are met but with such poor quality that problems emerge later.

I can see how you can run OKRs without agile.

And I’ve long seen Agile working without OKRs.

But if you have both Agile and OKRs in the same company I just don’t see how Agile and OKRs can be separated. Conversely I can see how they can work well together – yes, I wrote a book on that.

If you are going to have OKRs and Agile in the same company then you need to consider them as one thing, not as two separate endeavours.

Photo by Jackson Simmer on Unsplash

Subscribe to my blog newsletter and download Continuous Digital for free

The post Can you keep Agile and OKRs seperate? appeared first on Allan Kelly.

Posted on

Signing off 2021 and Not rolling over

Allan Kelly from Allan Kelly

“The decision about what to abandon is by far the most important and most neglected. … No organization which purposefully and systematically abandons the unproductive and obsolete ever wants for opportunities.”

Peter Drucker, Age of Discontinuity

I’m writing this on the last day of 2021 and for once I am confident in predicting that next year will be better than the one that is ending. Like most people I have a few routines I follow around this year and one of these relates specifically to this blog.

I often get asked: how do you get ideas for your blog?

The truth is I have too many ideas for this blog, right now I have 18 ideas for blog posts that are part written. That might be as little as a title, or a completely written post I haven’t editted yet – plus there is one entry I wrote and decided it was for me alone. When I have an idea for a post I just add an entry into my blog list, normally that would be a title and few bullet points. Sometimes it is just a title, occasionally I just type the whole thing as a stream.

These entries will not be rolled over for 2022. In fact, I just deleted 7 after writing that last paragaph. The remaining 11 will be folded up and put to one side in the MacJournal software I use for blogging. I have already created a 2022 folder for next year.

It is a bit like buying a daily newspaper, once the day is gone there is rarely any point to going back to read the bits you missed. Tomorrow is a new day with a new newspaper, new priorities and new things to read.

In order the have new ideas one must make space for new ideas, and that means throwing away ideas which have not be able to win the competition for attention to date. This idea is embedded in my thinking when I recommend teams using OKRs throw away their backlog. It is why I like Jeff Bezos’ “Everyday is Day-1” thinking.

Don’t get weighed down by yesterday’s good ideas, if they are really good ideas they will appear again. If not then removing them will make space for better ideas. Plus, by practicing new ideas you will get better at new ideas.

More importantly: throwing away those ideas and work-in-progress forces one to think about what is really important, what really will make difference and move you forward. Dispensing with the day-to-day trivial allows one to think big.

In truth, while I just irrevocably deleted seven potential blog entries the other 11 will not be lost for ever. They will just be hidden. If I am stuck in a few months time I know where they are – but for that matter, I could equally fish in the unused entries from 2020, 2019, 2018… And in complete honesty, there are two early drafts already in the 2022 folder that I’m keen to write.

So while I say, and I advise you to: “Throw away the backlog” I have no objection to someone keeping (some of) those good ideas in a bottom draw as long as a) nobody pretends they might be done one day, b) they do not distract from your focus on the important things.

Finally, if I am to think big for the next year what would I like this blog to carry? – in other words, what might you expect?

Top of the list is to focus on OKRs: I’ve been blown away by the interest since I published “Succeeding with OKRs in Agile” and I know a lot of people are wrestling with OKRs with agile.

I’d also like to focus myself on “small practical bits”. I know I have a tendency to be “philosophical” – in part that is because I believe that our “philosophy” informs our daily actions and decisions, and the pattern of those decisions, far more, and for far longer, than any given list of “10 things you should …” But I also know, readers – and book buyers! – like “small practical bits” so commercially I should do more of those.

Subscribe to my blog newsletter and download Continuous Digital for free

The post Signing off 2021 and Not rolling over appeared first on Allan Kelly.

Posted on

Top agile books which aren’t about agile or software

Allan Kelly from Allan Kelly

Christmas is almost here and the end of the year is nye. That means it is time for newspapers and journals to start publishing “Top books of the year” lists and “Christmas recommendations.” So, prompted by a recent thread on LinkedIn I thought I’d offer up my own book list: top books for agile folk from outside of agile (and software).

That is: books which are not explicitly about agile (or software development) but which contain a valuable message, and possibly techniques for those wanting to expand their knowledge of, well, agile.

Most of the books I’m about to list address philosophical, or mindset, underpinnings of agile: how to think in an agile way, rather than “how to do agile.” That might disappoint but think about it, how could a book from outside agile tell you how to do agile?

Well, actually, there are three which do.

First The Goal: written in the style of a novel this book explores the theory of constraints and elementary queuing theory, without mentioning either by name. Since it is written as a novel – with characters and back story! – this is an easy read. But please, don’t judge it as a novel, judge it for the message inside.

Next up is The 7 Habits of Highly Effective People: I blogged a few months ago how these habits could also underpin a team working style. Whether you read this for yourself or with an eye on your team this book does contain actionable advice – and some ideas on how to think. It can be a bit of a cringe in places and I’m not sure I agree with all the ideas but it is still a worthwhile read.

Finally in this section is a book at the opposite end of readability: Factory Physics.

Make no mistake this is a text book so it sets out to teach and can be hard going in places – there are plenty of equations. But, if it is a solid grounding in queuing theory, variability, lead times and the like you want then this is the book to go to. In fact, it might be the only book.

That is it for hands on books which will tell you how to do things on Monday morning. The books which are ones I consider “philosophy” – how to think. Thats my way of putting it, a more popular way of putting it is: Mindset. These are books which have shaped my thinking, my mindset, and as such underpin my approach to all things agile – and more!

First here is The Fifth Discipline. This may be the founding text in the field of organizaional learning, ultimately all agile learning and applying that learning. The “learning view” underpinned my own first book and that still fundamentally shapes my approach to working with individuals, teams and companies.

My next choice continues the organizational learning theme and is the source of perhaps the most famous quote from the that field:

“We understand that the only competitive advantage the company of the future will have is its managers’ ability to learn faster than then their competitors.”

The Living Company presents an alternative view of companies and organizations: rather than being rational profit maximising entities this book encourages you to see companies as living organisms. As such the organizations true goal is to live and continue living. Trade, and even profit, is simply a means to an end. And like all successful living things companies must learn and adapt, those that don’t will die.

Living Company is not alone in presenting an alternative narrative of how companies work. My penultimate book presents an alternative view of that most sacred of management practices: strategy.

The Rise and Fall of Strategic Planning is a major work that not only charts the historical rise of strategic planning and the subsequent fall it also present an alternative view of what strategy is and how companies come by strategies: strategy is a consistent pattern of behaviour, strategy is part plan but is also emergent and changes in respect to what happens. Strategy claims to be forward looking but is equally retrospective, strategy offers a story to link past events together.

Along the way Rise and Fall accidentally explains where the waterfall comes from (Robert McNamara), how planning is controlling and why even with almost unlimited resources (GE and Gosplan) the best attempts at planning have failed. If you harbour any ambition to implement Scrum at the corporate level make sure you read this book.

All the books above are over 10 years old and had I written this list 10 years ago it would probably be the same. But two years ago I read Grow the Pie, this advances the discussion of why companies exist and how to be a successful company – the secret is to have purpose and benefit society. Written before the pandemic it is now more relevant than ever. Again it isn’t an easy read but it pays back in thoroughness of argument and reasoning. And if for no other reason, read Grow the Pie to really understand what constitutes value.

Subscribe to my blog newsletter and download Continuous Digital for free

The post Top agile books which aren’t about agile or software appeared first on Allan Kelly.