The OKR cycle goes wide-narrow-wide

Since writing Succeeding with OKRs in Agile I’ve had the chance to work with a few companies on OKRs and deliver a some training. Structure my thoughts to explain to ideas and concepts to other people is a great way of increasing your own understanding. So much so that I’m contemplating a second edition of Succeeding with OKRs – I’ll decide once I get Books to be Written out of the way.

The OKR cycle

Hence, I increasingly find myself talking about the OKR cycle – I mention the term in Succeeding but have come to realise how important it is. The “OKR cycle” is depicted in the diagram about, it is setting the team OKRs, executing against the OKRs, then as the end of the period is in sight thinking about what comes next. As the cycle ends there you need to close out the OKRs, review what you did, retrospect (what can we do better next time?) and go firm on the OKRs for the next quarter.

Typically the OKR cycle is 13 weeks long which immediate begs the question of how it fits with 2-week sprints? I was already moving towards saying “aim for 12 or 14 weeks” but after listening to a number of podcasts and talking to others I increasingly think 13 weeks is not the best period.

I can see a good case for running 4 month, 16 week, OKR cycles. This would decouple the OKR process from all those other quarterly processes businesses have: financial reporting, sales quarters, performance reviews and so on.

I can also see a case in going in the other direction: a 10 week cycle would also decouple OKRs from the same things. But there is a catch here: OKRs fill the mid-range planning horizon and help glue strategy to implementation. If we shrink the cycle too far it will become a long-sprint. Hence I tend towards lengthening the cycle but until I get a chance to try it I’m not coming down firmly one way or the other.

The other reason to shrink the cycle is to learn faster: particularly when starting OKRs. Just like running one week sprints when a team is new to agile. When a team is new to OKRs I now recommend running two back-to-back 6 or 8 week cycles. This would give the team twice the experience of setting OKRs, using OKRs to drive iteration planning, closing out OKRs at the end and repeating. After the second cycle I would drop back to 12 (or 16) weeks.

Which brings me to the second point on OKRs – something else I hint at in Succeeding but now go further. When working with OKRs you want to follow and Wide-Narrow-Wide model.

Wide-Narrow-WIde for setting, executing and evaluating

Stage 1 goes wide when setting OKRs: during this phase you want to go wide and think broadly. Consider what you might do, what is valuable, how what you are proposing will deliver (or protect) value. Ask difficult questions, throw stones at ideas and see if they hold up. Everyone should have a say because everyone needs to feel enrolled in the objectives.

Stage 2 goes narrow: your sole focus is on delivering the OKRs, you should aim to push everything else aside. OK, caveat #1 if your house catches fire unexpectedly PUT OUT THE FIRE even if you loose you OKRs – don’t be stupid but neither should you rush to extinguish every flame prematurely. And caveat #2: if fighting fires, aka dealing with live issues (think SecDevOps) is part of your responsibilities then make sure your OKRs reflect that is part of your work – maybe use OKR #0 as I discuss in the book.

Stage 2 is the longest stage, most of the typical 13 weeks, so my egg-timer model image isn’t completely accurate but you get the idea.

Finally, in stage 3 you go wide to evaluate what happened. This is where you ask not just “Did we meet or miss the OKRs?” but more importantly: “did we do good? did our work benefit people? add value? did we further our mission and the purpose of the organization?”

Ultimately I don’t care if you miss every OKR if you can answer “yes, we added value, we furthered our mission.” OKRs are, after all, a hypothesis of what will create benefit in the next few weeks.

And no sooner are you finished thinking broad in stage 3 then you are back to the wide thinking of stage 1 and you repeat.

Subscribe to my blog newsletter and download Continuous Digital for free

Books to be Written new cover

Books to be written has a new, professional, cover. What do you think?

I published an updated version earlier this week with more about working with publishers.

There are some loose ends to tie up in the content now then I’m into a big end-to-end edit, the hard bit. After that I move from writing to production with copy editting. The new cover is the first step along that path.

If you buy the unfinished version on LeanPub now you will receive free updates as they are released and the final, finished, book later this year.

By the way, in keeping with the book being increasingly “done” the price has gone up $1 and it will increase again before I’m done so you can save a little money by buying early.

Product Owner car crash story

A few weeks ago I was in Sweden with clients and heard a horrific Product Owner story today – one I can hardly believe… maybe I shouldn’t, this was told to me second hand but I think it serves as an useful warning.

Reportedly a local car company has told its Product Owners to split their time three ways: 25% of their time is to be spent doing product owner work, the next 25% is to be spent in line management and the rest of the time, half their time is to be spent keeping deep technical knowledge by coding and other hands on activities.

To be clear: this is a bad idea, a bad idea, a bad idea.

Let’s start with 25% product owner work: not only is the Product Owner role the most difficult role to fill it is also the most time constrained role. 100% a product owners time is not enough to fill the role properly.

Next, line management and product ownership should never mix: product owners take their authority from being experts on what is needed rather than a position on an organizational diagram.

Product Owner – even when called Product Managers – are peers of software engineers. They are both professional with specialist skills, they need to respect each other and have constructive discussions even when they don’t agree with one another. The Product Owner is the expert in what customers want, the engineers are experts in solution building, they represent the analysis-synthesis split.

Product Owners need to be able to represent what the customers want to the engineers and engage in meaningful debate between peers. This is not going to be possible is the Product Owner is also the line manager for the engineers with the power to refuse holiday, promotion and mark staff down in reviews if they don’t get their way.

Besides, when do they have the time to do line management?

Then the massive 50% of the time spent coding or other technical work. Again this conflicts with being a true product owner (representing the customer) and holding meaningful discussions with engineers. As they only spent 50% of their time on engineering issues the PO will be the least prepared engineer on the team but the one with most authority. (I’ve written before about the mistake of making a platform engineer the product owner.)

And where is the product owner to get time for all the other miscellany that lands on a Product Owner’s plate? Reporting, statistics, testing, negotiation, etc. etc.

This company has fundamentally misunderstood the Product Owner role. They are seeing the role as an old fashioned Development Manager who was expected to be the technical authority, the team manager/leader and the one to nominate what should be worked on. (Even if they never meet a customer.)

The three things the company is asking the product owner to do are not just three different things, they are three things that should be separated. Line management is an issue agile folk struggle with because in purest terms it shouldn’t exist but in the vast majority of organization that nirvana is so far off it needs. So far at moment we are still in search of a generic model and until we get it we need to keep line management outside the team if possible.

50% hands-on is the give away here, the car company really want a technical authority, call then a senior engineer, a dev lead, or even an architect. This is a legitimate ask and should be recognised as full role. In fact, I would encourage the role holder to put a lot of time into mentoring less experienced engineers. In some engineering fields such senior engineers work as a type of tester to reviewing the work of other staff.

Finally the Product Owner role is a full, legitimate role in its own right. I suspect what is happening at the car company is they have lots of teams working on small technical aspects of the car. They feel only a few people need actual customer knowledge and contact.

It might be that the company could use the strategic product owner/tactical product owner model. Sometimes the TPO role crosses over with the Tester role and it can make sense to have an experienced engineer in the role. Still, you need someone to represent the customer point of view and another person to represent the technical side so the two can have constructive disagreement.

Very occasionally, once in a while I come across a situation where is makes sense to a very technical person drive product ownership from a purely technical point of view. Such occasions are few and far between, but the majority of engineer and managers think their case is one of those exceptions. Maybe this is one such case, but why add-in in line management? and why reduce Product Ownership to a part-time role?

In short: don’t do this.

Subscribe to my blog newsletter and download Continuous Digital for free

Books to be written

I’m entering the final stretch of writing for my new book so it is time to think hard about the name.

“How I write books” was only ever a working title, now I think I’ve hit on the permanent name “Books to be written“. What do you think?

Let me know – you can check out the (nearly finished) book on LeanPub right now. Almost all the chapters are now drafted.

How fresh is your backlog?

Do you struggle with an overwhelming backlog?

Do you count the number of product backlog items in your backlog in tens? hundred? or thousands?

Does your backlog contain many stories which have been there for months, if not years, and yet never raise to the top of the backlog?

Is your success judged on your ability to do the backlog?

Backlogs were a good idea when they were introduced a bit over 20 years ago but today many teams slaves to the backlog – see my posts on the Tyranny of the backlog and Purpose over backlog. One of the benefits I’ve called out for OKRs is the ability to move away from backlog driven development (BLDD).

In Succeeding with OKRs in Agile I ask suggest you either need to prioritise your backlog over OKRs (in which case OKRs are derived from the backlog you intend to do) or OKRs over backlog (in which case OKRs are derived from strategy and the backlog plays a supporting role.) In my podcast with Jenny Herald earlier this year I even say “Let OKRs drive… nuke the backlog.”

Filipe Albero Pomar recently shared his backlog freshness blog which I think is great. Freshness is a great way to think about the state of the backlog that separates the size of the backlog from the relevance of the backlog.

Filipe’s idea is simply to talk about the backlog in terms of freshness – you have a fresh backlog if your backlog items are fresh: written recently, relate to current opportunities, problems and things people currently want.

And of course, the opposite of fresh: stale, stories that have been sitting in the backlog for months, even years, stories that relate to yesterday’s problems and project, stories which people wanted last year. The existence a big backlog of stale stories means the team is seen to be not delivering, the end-date is far off because people still expect all the work to be done.

Filipe suggests backlog freshness can be measured:

1. Set a cut-off date

2. Categorise stories as fresh or stale: fresh stories have been written since the cut-off date, those which are older are stale

3. Calculate freshness as a percentage of fresh from the total: if 25 stories out of 60 have been written in the last month then the backlog is 41% fresh, and 59% stale

Thats a useful metric, I think we can do better, look at the graphic above. I group backlog items into age groups and graphed them. For completeness I added a line to indicate average story age. Clearly this backlog is not fresh – nearly half the stories are over a year old.

I like the idea of graphing backlog freshness because it is easy to understand and makes an impact. In the graph above I’ve categorised backlog items into age groups and added an average line. Clearly this is not a fresh backlog. Whether this is the way to demonstrate backlog freshness I’m not sure – I’m playing with a histogram and quartile ranges.

With some clients I’ve thought of the backlog like a mortgage. There is the principle (the existing backlog), the interest rate (the growth rate of the backlog) and the monthly repayments (stories reaching done). Unfortunately when you do this you sometimes find the mortgage will not be paid for many years, and perhaps never. (Don’t worry about estimating the size of stories, for this sort of analysis the number of stories will get you started, and if your backlog is measured in hundreds of items the small will offset the large.)

I’d love to talk more about this and experiment with some ideas, I think it could be a very useful way of thinking about the backlog.

Subscribe to my blog newsletter and get Continuous Digital for free

Scrum or OKRs, which comes first?

“Hello Allan , I followed a few of your seminars on OKRs and I am reading your book. I do have one question. I will start a transformation soon. The company has the ambition to move to Scrum and also OKRs; Do you have any advise on where to start? OKRs first or SCRUM first. Thank you a lot !”

This question appeared in my mailbox – or rather my LinkedIn box – a few weeks ago and I thought other readers might be interested in my answer.

My answer is: do both together.

That will sound ambitious if you see Scrum and OKRs as distinct things but I don’t, to me they are synergistic and can be viewed as one change. In the process I see the opportunity to create a simpler form of agile, or simpler version of Scrum if you prefer. Let me describe.

The Scrum Master role remains pretty much the same as regular Scrum. The main change is that in addition to facilitating planning meetings and sprint retrospectives the Scrum Master will additionally facilitate OKR setting sessions and OKR retrospectives at the end of the cycle. They will want to ensure the OKRs are known by everyone and people reference to them during sprints.

Similarly the Product Owner role remains pretty much the same with the additional need for the PO to lead thinking on what OKRs to set. This means the Product Owner needs to do more horizon scanning, talk to more stakeholders and prepare to set objectives that will last several sprints rather than just one at a time.

Simplification comes in that there is no need to build up and administer a product backlog. Set the OKRs, then go straight into a planning meeting and ask “How do we make progress against this OKR?”. Write the stories you need to do that. Use the OKRs as a just-in-time story generator. If you generate stories you cannot do this sprint then put them in a product backlog for the next planning meeting.

In the next planning meeting review progress and ask yourself again: “what do we need to do to make progress on these OKRs?”. It might be that you have some stories from last time to work with, if not write some more. OKRs in effect become the Sprint Goal and you generate the stories from there. (If you are using a Product Goal as well then reference that when setting the OKRs at the start of the cycle.)

Estimation is reduced because you have fewer stories in play and in the backlog. If you want you can use story points and velocity to determine if the sprint is full or you can just ask the team “Is that enough work to keep us busy?” and “Do we have space for more?”

If you want a more sophisticated system then get the stories out on the table, put them in the order they are likely to be done, then go from top to bottom asking “On a scale of 1 to 10, What are the chances we will get this story done in this sprint? – where 1 is unlikely and 10 is almost certainly.” If the probability is below 8 you probably take action, break the story down, reorder the work order or just accept that you probably won’t do everything you would like to.

In the longer term you can count the stories done to build up a record of capacity.

I would aim to do end of sprint demonstrations and better still release to live. The OKR may not be complete but the stories in the sprint can start delivering value early. As usual keep quality high, aim for zero bugs and automate everything that needs testing.

If you are new to both Scrum and OKRs then I would probably run one week sprints and a six or eight-week OKR cycle the first time. Do a retrospective at the end of the OKR cycle, after that you might move to two-week sprints and 12 week OKR cycles but keep an open mind and decide what works for you.

All the way through keep delivering benefit to customers, hitting OKRs is icing on the cake, and there are no prizes for doing perfect Scrum.

I’d like to think I outlined this recipe in Succeeding with OKRs in Agile but I suspect I wasn’t as clear as I could have been. Increasingly I’m seeing OKRs as a means of stripping agile back and simplifying it.

Subscribe to my blog newsletter and download Continuous Digital for free

The Excess Strategic WIP problem

Try pouring a bottle of milk into a glass with milk already in it. You have a choice: stop or tidy up the mess afterwards. That is my work-in-progress (WIP) analogy, if you try and do too much – no mater how much you want to do it – you will end up with a mess.

Agile folk are well versed in the problems created by too much WIP and how to deal with it – check out the Stockless Production video if you want to see. In the last six months I’ve been seeing a particular variant on this problem with I’ve come to label the Excess Strategic WIP problem.

In the latest report the manager told me how the team completed a great quarter with 3 priorities – set via OKRs. The senior management team were so impressed they asked for 19 priorities in the next period.

Right now I don’t have a “paint by numbers” solution, fixing this problem is more involved. I’m starting to understand it and I’ll make some suggestions later. Ultimately this a failure of leadership to say “No”. That failure is itself rooted in a failure of leadership to appreciate what is happening on the ground and what doing the worker are up against: the number of strategic initiatives or the amount of business as usual.

In a team it is easy to spot excess WIP using a visual system like a whiteboard or card system. When you track work like this you see an awful lot of work sitting in the “in progress” column. Typically there is more work than people on the team and the work isn’t moving. Some of the work may be actively marked as blocked but more likely most of it is nominally being worked on.

It can’t all be worked on at the same time because despite having two eyes, two hands, and two sides of a brain human’s can only really do one thing at a time – even new parents. I label this work “WHIP” – work hopefully in progress. While it is, in theory, being worked on, most of it is just sitting there waiting for a multi-tasking (i.e. time slicing) person to come back to it.

The good news is when you can see the WHIP you are half way to solving the problem: there are well known solutions. Accept less work, impose work in progress limits, sequence work by adding queues to the board, educate people to work on one thing until it is done, etc. Once you can see the work you have a feedback mechanism, you can take action and, thanks to the feedback mechanism, watch it reduce.

But Strategic WIP is more difficult. Strategic WIP is the stuff the organization decides in really important, the stuff the most senior leadership decides should be happening. The Excess Strategic WIP Problem occurs when those strategic priorities are greater than the organisation’s ability to deliver on them.

While some of this work may be transactional (“Build a Mega Widget”) much of it is transformational (“Adopt Agile working”, “Increase diversity”, “Tighten security”). Such things involve changing the way other work is done: changing the processes, changing the criteria, increasing awareness. The feedback cycle is long but to get started people need to devote time: attend training, arrange kick-off meetings, discuss approaches with consultants/coaches, etc.

In one case I saw this year the organization has, for years, been asked to do more than it is resourced to do. While a few months of such a mismatch might have been manageable the cumulative effect has been to create organizational debt and demoralised staff.

The second case I saw isn’t a result of under resourcing, if anything that organization has too much – money, people and perhaps equipment then they know what to do with. But because their management model resembles a sponge it is impossible to know when the organization has taken on too much. While some pockets were overworked I’m sure other pockets were idle.

In both these cases “lean” was a dirty word. Both organizations had been subject to lean programmes that had stripped out “waste” but, from what I could see, removing that waste had created both organizational debt and demoralised staff. Having removed “spare” staff those left were juggling. Staff didn’t have time for “agile” and their diaries had no space for daily essentials let alone another change programme.

The third case came to light when discussing OKRs. The company had a successful quarter were they focused on a few objectives that success seems to have bred the next failure when the organization requested many objectives.

Actually, this case brought it home: taking on too many, or being given too many, OKRs. I’ve heard of teams tackling too many OKRs so many times in the last year. (In fact, I should name this “Excess OKRs Problem”. This occurs whenever you have more OKRs than you can count on one hand. Don’t tell me your team is big enough to do so, check out Focus is not divisible so limit you OKRs.)

In a way, the Excess OKRs Problem is better than the Excess Strategic WIP Problem because you can see it. One can say “OK company, you have asked us to deliver 15 OKRs here, we need to sit down and talk about this.” Like visualising your work in progress excess OKRs is a thing you can identify and address, it is the reason to talk.

(Note: unlike User Stories which should always be small, OKRs should never be small. OKRs should be big, meaningful and preferably strategic. No team can take on 16 meaningful OKRs, even 5 is too many.)

One of the problems with excess Strategic WIP is that it can be difficult to see, there are different teams involved and in different places. Conflicting priorities are hidden. People on the ground may see problems but the senior people – the people creating the WIP – are too far removed. Those people may not want to hear people saying “You are asking too much”. They may have too much riding on getting multiple work streams done. They may be deaf to the cry of pain when people say “too much.” They may have too big an ego to accept that what they are asking for is a problem. And it may be politically unacceptable.

“Political” is an important word here: several of the cases I’ve heard of, and some of those example above, are Government agencies.

Because excess strategic WIP is difficult to see it is difficult to build a feedback loop and difficult to take action. How do you know when the problem is too much WHIP and when people are “crying wolf” ? – which in itself implies a problem of trust and maybe a belief that “everyone is lazy, we need to push harder.”

By its nature “strategy” is big, which means that the feedback cycles are long and the problems of excess strategic WIP take time to play out. What is a WIP problem looks like another failed strategy.

While I would like to think OKRs can help with this situation – because they force teams and organizations to take stock of what they are working on – they may be making things worse because OKRs include an ambition agenda. Teams are encouraged to “shoot for the moon” and build “10x solutions”. There is good logic here: if one aims for a “10x solution” (i.e. a solution 10 times better than the status quo) and falls short the “failure” may still be “better” (e.g. “5x”) than if one had aimed for a “2x solution” and succeeded.

Ambition with OKRs should not be about doing more OKRs, rather ambition is within the OKRs, a challenge that makes you approach it differently. One can draw a line here between having one OKR which aims for “10x” and having 10 OKRs but I suspect the subtlety will be lost on someone asking for “more than you think you can do.”

So whats is the solution?

I’m not sure there is a silver bullet but I would want to … make the problem visible, perhaps a portfolio level kanban board. I would want to build a feedback loop so I could measure change. I would want to show the strategic people the visualisation.

Management education has a part to play too. I can believe many senior managers would benefit from understand what WIP is, the problems excess WIP can cause, the way excess WIP plays out on a day-to-day basis and how it effects people’s working lives. And perhaps most of all, address trust and the belief that “we just need to push harder.”

That might also mean some of the Lean waste lessons and OKR ambition lessons need to be revisited.

Subscribe to my blog newsletter and download Continuous Digital for free