Next month – in just over 3 weeks in fact – I’m running a mini-workshop Masterclass (2 hours) on Writing OKRs. Specifically on making key results measurable and quantifiable. Yes I know targets can mislead, that might be something we will talk about. Its timed for 2pm which should be good for Europe and the East Coast. Sorry far east, Australasia and West Coast.
Tickets are available now but are limited so if you want to don’t delay, book now. Plus, for the next week cheap very early bird are available, and if you use the code “Blog20” you can get an extra 20% off.
Looking across the state of teams today I can clearly see three different styles of agile: Backlog Driven Development, Reactive and Objective Driven Agile. All have their place, all have their uses but the first two of these are a dead end. I’ve been speaking about the third, which I’m calling Objective Driven Agile, for years but in the last few months, since writing Succeeding with OKRs in Agile and speaking to many people about how OKRs and agile fit together, it has become clear to me that ODA allow us the industry, and teams, to address a number of problems that have arisen with agile in recent years.
1) Backlog Driven Development – BLDD. Teams are typically working in a Scrum fashion with a backlog and short sprints. Such teams are sometimes called “feature factories” because they are aiming to “do the backlog” – and the backlog is inevitably a lis of features.
While the Scrum these teams practice is a lot more agile than what came before they haven’t really moved very far from the big requirements documents of old. Backlogs are frequently bottomless pits, the team can never reach done. The loss of change review board might well be making things worse because Product Owners often lack the authority to say “No” or remove items from the backlog.
Still, not only are these teams agile but in many places this is success. The team are churning out stories, customers can see progress and are persuaded to part with cash. If the backlog can be tamed they might even declare done one day. But then, if the team is being operated by a consultancy or other outsourcer for a client the last thing they want to happen is for work to be done.
2) Reactive. Reactive teams gravitate towards Kanban but some are compelled to work in a Scrum fashion which doesn’t match their real work. Such teams may see backlogs are an anathema because they do “what is needed, right here, right now.” Team members here will say “true agility is listening to what customers want and getting it done as quickly as possible.” And in a way they are right.
Again, these teams are a success story, particularly if they are supporting a live system, running DevOps or if customers previously had to wait months for results.
The problem here is that these teams don’t have much capacity for doing the backlog or anything else and yet they are frequently still expect to “do the backlog”. If such a team have been tasked with immediate customer support then that isn’t a problem but frequently these teams face competing demands.
3) Objective Driven Agile, ODA: this is the approach I’m focused on at the moment. With Objective Driven Agile teams have a mission and a higher purpose, something more than “do the backlog” or “keep the system working.” Such teams might be considered “Empowered” and might practice “Dual track agile.” The key thing is, they are not beholden to a prepared list of things to do. The team are responsible for deciding what customers need, what will add value and what will meet team and organisational objectives, and then, delivering that thing.
These teams have “Product Owners” who are more than mere Backlog Administrators – I’ve started calling them “Product Specialists.” These people are tasked with understanding what will add value for customers, users and other stakeholders. Importantly they have the power to decide what gets done and to say “No”. With that power comes responsibility: responsibility to the team, to stakeholders and to other leaders in the organization. That means Product Specialists can explain – in a business case or in a star-chamber – how work on the product adds benefit and how the desired outcome – the objective – is moves things forward.
All three of these styles have their advantages and disadvantages but the real problems occur when the styles are not clearly stated.
Consider the team trying to deliver the backlog BLDD style but who have to “keep the lights on” and support a live system. It is mathematically impossible to make accurate forecasts about delivery when events can derail you. It is also nye on impossible to deny customer requests when they are waiving a large sum of money or escalating their ask through your organization. But again, this can blow up any plan or roadmap.
Nor is is possible to pursue objectives when teams are committed to supporting live or delivering a backlog. At best the objectives duplicate the role of the backlog and at worst increase work-in-progress and add stress to individuals on the team.
So my advice: decide which type of team you are and focus.
In the last few months I’ve been speaking a lot both about objectives and “just in time backlogs”. I’m fired up and want to pursue this idea, if you are interested please let me know and I’ll write more.
Lets get back to lightweight methods, let me propose a 7 step process with the working name Objective Driven Agile – although I also want to call it Really Simple Agile or maybe Xanpan 2022 – and I’d rather forget the A-word altogether and get back to lightweight.
1) Start where you are, with the people on the team, with the code you have, with any existing documents, there is no pre-work, you start here with what you have. Any pre-work you think you should do, any blocks or impediments you are facing, any reason not to start now becomes a work item to be done.
2) Default to a 3 month “super-cycle” and 2 week iteration cycle (OK, we’ll call them sprints), you may change this later but put the dates in your calendar now and set them to reoccur.
3) Set a maximum of 4 objective(s) for this period.
I will assume you are using OKRs for this and limit them to a maximum of 4 key results for each objective. Key results are not small pieces of objective but bounding criteria which describe the objective, acceptance criteria.
If you team must “keep the lights on”, operate as a DevOps team, support a live system or other “business as usual” then this is objective zero and must be acknowledged as work to be done.
Objectives are outcomes, they make the world a better place. Objectives should support business purpose and strategy. The team should be able to explain how the objectives meet these criteria, better still it should be obvious.
One of the objectives should be nominated by the team themselves with the aim of making future work better, easier and more productive even if the outside world can’t see a difference.
4) Run sprints (iterations) inside your super-cycle: the first sprint starts as soon as the objectives are confirmed.
If any preparation work (e.g. interviewing customers) is needed this is part of the work to do. In the sprint planning meeting review your objectives, then decide which will be the focus of the sprint and ask “What do we need to do to advance our mission?” and write stories for this work.
For each story ask: “can this be completed within one week?” If it cannot then find a way to rewrite it as several stories each of which can be completed within one week.
When you have written the stories ask: “is this enough work for the sprint?” If the team thing they have capacity to do more work, or might do all of this work, then write some more stories – about the same objective or another. If the team feel this is too much work for this sprint prioritise the work then hold some back for the next sprint.
5) During the sprint aim to release each story as it is done, continuous delivery style. Review progress against OKRs regularly (but not every day). If the team can’t do release individual stories at the start then it is something to work towards, something for that team nominated objective.
Work items which arise under OKR #0 should be recorded as “yellow stories”, the team may refuse such work but once accepted it has priority over all other objectives unless otherwise decided.
6) At the end of the sprint release any finished work, demo to stakeholders, review, retrospect and replan. Count the stories – including yellow work – completed each sprint and maintain a graph during the super-cycle. The graph should show planned and yellow work.
7) At the end of the super cycle close out the sprint, review progress against OKRs, hold a retrospective for the whole period. Destroy any stories which still remain undone.
Return to step 3.
Two assumptions: you are setting objectives using OKRs, you are running Scrum like sprints. Both assumptions can be relaxed (i.e. you don’t need to use OKRs and could run Kanban style) but I would need more space to explain how that might work and I’ve deliberately kept this short.
I was recently asked to do a short introduction to OKRs for the Digital Leaders conference. The recording is now online and focuses on the benefits of OKRs. Naturally, I put the emphasis in different places to others!
“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.
I blogged last week that I had begun work on a new book – How I Write Books which is now a work in progress at LeanPub – signup and be the first to know when the draft is published.
Well a funny thing happened while I was setting up my tool chain to write that book: I found another book! Well, perhaps half a book is a better description.
Succeeding with OKRs in Agile Extra is a companion to last year’s best seller, Succeeding with OKRs in Agile. But it isn’t a complete book in its own right, it isn’t really a sequel, it is a companion. It contains a mix of material. Material which didn’t really fit in the first book, material with was’t needed, ideas which didn’t develop far enough and some unfinished chapters.
As such it is like my Xanpan Appendix, unused material which is still interesting and might appear elsewhere in time.
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.
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.
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.