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.
Last week I delivered the opening keynote at Oredev in Sweden: It’s always time for tea – lessons for Alice the software developer. I also picked up a whole bunch of questions – about agile, OKRs and tea – which I intend to answer here in the coming weeks.
This was a unique presentation, a challenge to put together but still a lot of fun to create and deliver. You see, the conference had an Alice in Wonderland theme so the challenge was to deliver an Alice themed keynote. Having read Alice twice in the last few years I knew immediately where to start: the Mad Hatter’s Tea Party.
The lessons I drew from Alice form a mini-manifesto which nicely describes much of my own philosophy when it comes to managing digital work.
Deadlines over estimates
‘Yes, that’s it,’ said the Hatter with a sigh: ‘it’s always tea-time, and we’ve no time to wash the things between whiles.’
Which nicely describes the life of technology creators. I argue that “it is always time for tea” is actually the natural state of things. When it is not “time for tea” we lack motivation; humans are bad at estimating time but good at working to deadlines. (See my old Notes on Estimation and More Notes on Estimation.)
Therefore we should organise our work processes around deadlines not estimates and structure our work in the expectation that we will not get time to make things good later.
Purpose over plans
“It doesn’t matter which way you go,” the Cheshire Cat tells Alice, “‘you’re sure to [get somewhere] … if you only walk long enough.”
In Through the Looking Glass the Mock Turtle concurs: “‘no wise fish would go anywhere without a porpoise. … , if a fish came to ME, and told me he was going a journey, I should say ‘With what porpoise?'”
Similarly, plans are not benign, plans have a dark side, they can be demotivating, demoralising, controlling and mislead us. Planning is essential but plans are downright dangerous.
We often overlook purpose, mission and outcomes in favour of following the plan and just “doing the backlog”. Yet out backlogs have become bottomless pits and burn-down charts are often burn-up charts.
At some level we are too busy doing stuff and earning money to think about the bigger questions but there is evidence that companies which focus on purpose and regard profits as a side-effect do better, and not just in the long-run.
Small over big
Everyone knows about Alice growing bigger, and smaller. Which echo’s “Kelly’s law of projects: “Inside every large project is a small project struggling to get out.”
The idea of doing small things comes up again and again: minimally viable products, prototypes, proof of concepts and so on. But we too often think big and fall for the old economies of scale myth.
Simplicity over complexity
With big comes complexity, which Alice discovers when the King invokes rule number 42:
“Rule Forty-two. ALL PERSONS MORE THAN A MILE HIGH TO LEAVE THE COURT.”
Again and again we find complexity hides simple truths, we need to constantly work for simplicity.
Along the way I talk a bit about the nature of agile methods and explain that while SAFe may be agile it will never be lightweight.
I think it will be a while, if ever, before this presentation gets repeated but hopefully a video recording will be out before long. In the meantime you can get the slides.
After my presentations at Oredev, and over coffees, I picked up a few questions which I thought I’d answer in the next few blog posts. I hope you find this useful, and as ever, please leave a comment or get in touch to talk about these ideas more.
In case you missed it, Tom Cagley has released the “SPaMCast” podcast we recorded a couple of weeks ago: Nuke your backlog!
Since recording that I saw Rob England describe similar thinking as “declaring backlog bankruptcy”. Certainly bankruptcy is a more business friendly than “nuke”. And in the weeks since I releases “Honey, I Shrink the backlog” I’ve had several people tell me about their experiences ditching their backlogs.
So, while the disposing of the backlog may be a somewhat radical idea it is not completely new.
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.
My popular User Stories by Example online courses have been absent for a couple of months while I moved platform. I’m pleased to say these are back online on a new platform. The code Blog2022 will give you a 25% discount on the courses.
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.
In November I’m delivering the keynote at Oredev in Malmo: “Its always time for tea” – the conference has an Alice in Wonderland theme.
Before then, I’m doing a practice run at Agile Bath and Bristol entitled “Lessons from Alice” on 11 October. This is online so if you can’t make it to Malmo you can get to see an early version – and if you are going to Malmo you can get a sneak preview.
As the name(s) suggest I’m aiming to draw lessons for technologist from Alice – after all, I was told long ago that Alice is Wonderland is packed with mathematical observations.
Anyone who has been following my posts and reading my books will notice I regularly return to the topic of goals, and specifically “bigger goals”, or as I say in Continuous Digitalhigher purpose. I’m not alone in this. The idea occurs again and again in management literature. Post-covid the idea is even more prominent. There are two reasons why I keep returning to higher purpose.
First, there is good reason to believe that people are motivated and more productive when the work they do has meaning and purpose. When I say “good reason” what I actually mean is: a) it feels intuitively right and b) there is research that backs this up (See Alex Edmans excellent book Grow the pie. Perhaps more importantly people feel better – happier, more satisfied – when they have meaningful work.
I don’t deny that making money is what drives some people, but for most of us, while it is necessary it is not our driving force. When you get up in the morning do you think “Gee another day to make some money” ? Does paying the mortgage or rent drive you onward? The thought of anyone needing to do a job they dislike simply because they need to pay the rent makes me depressed.
Second, I have long advocated team autonomy and driving authority down to the lowest level – what most of the agile community summarise as self-organizing teams. In tandem I advocate a move away form “shopping list” projects where teams are expected to “do everything on the list” towards outcome/ goal, based working where success is not “doing everything which was asked for” but rather “achieving an outcome and delivering benefit.” In this model they teams need goals.
And, as I point out in Succeeding with OKRs, goals are embedded within goals, goals are Matryoshki.
See how all this fits together?
But there is a problem. Or perhaps two problems.
Language complicates things. I’m writing here about meaning and purpose, which, for the moment I’ll regard as synonymous. Broadly speaking this fits in with “Start with why” hypothesis the likes of Simon Sinek advocate – and surfaces again and again. So there you have three terms which may be the same, may be different: meaning, purpose, and why.
Some organizations call these missions and have mission statements. Jim Collins and Jerry Porras wrote about BHAGs – Big Hairy Audacious Goals – in Built to Last. Salim Ismail of Singularity University suggest companies should have a Massively Transformative Purpose, MTP (Exponential Organizations). The same idea reappears as True North (or is it North Star?) elsewhere and I’m sure there other names I’m not aware of.
Then we have Objectives (with and without key results) and Aims, possibly even Targets. Where do Jobs to be Done and Epics fit in? I’d mention visions and product visions except I’m reminded of the words of German Chancellor Helmut Schmidt: “People who have visions should go see their doctor.”
Let me suggest whatever term a speaker uses they are driving at the same thing: “Something meaningful, large and overarching, something beyond the details”. Which brings us to the second problem: magnitude, some of these Matryoshka dolls are in the outer layer that you open first, some of them are inside and significantly smaller. Within these BHAGs, MTPs and missions there are smaller goals, and those lesser goals – which might be quite large themselves – align to the same True North.
Lately I’ve been using the model here to explain OKRs: OKRs are nested within Missions, a team may have several missions although ideally it would have just one. Missions are long lasting and may apply to several teams or an entire division. Missions in turn are nested inside organizational Purpose, purpose is pretty fixed and is lifelong, it is shared across the entire entity.
I find this model useful and it serves to illustrate how context is important. Teams can only make decisions on the work if they know the objectives (and, maybe, key results) they are pursing, and these can only be set if the team have the context that comes from a mission and purpose. But this model fails the language test, and by referencing OKRs means anyone not using OKRs will discount the model.
To unify the ideas we need to accept them all as equal.
Let me suggest a unifying solution: Level 1 Goals – I want to number those Matryoshki, with the outer most one, biggest one, being Level 1. As you open the dolls increment the number. (I’m using the word goal in a very generic sense, you can substitute objective or another word if you prefer.)
Level 1 Goals: “Purpose”, a “True North”, possibly an “MTP”, the organizational purpose, probably singular, largely invariant, doesn’t change often, in fact, changes it can be problematic.
Level 2 Goals: “Mission”, maybe a product goal or “product vision”, slow to change, expect it to last years. Organizations may have multiple missions each has the potential to advance on the purpose. Teams too can have missions, actually, I think all teams should have a mission – something I’ll write more about, its best if a team has one mission at a time but it might have multiple.
I’m not sure whether BHAGs qualify as Level 1 or Level 2 goals. If a company has only one BHAG and everything is aimed towards that goal than it is a level 1 goal, if the company has more than one BHAG then they are level 2. Which highlights a key point about Level 1 Goals: there can be only one level 1 goal, no organization can have more than one level 1 goal.
Now there is a big gap here between Level 1 and 2 goals which seldom change and last a long time to…
Level 3 Goals: these could be OKRs or quarter plans, I’ve also heard them called or “season plans”. These reset on a regular schedule – typically every three or four months.
There may well be more nested levels. Sprint Goals as used by some Scrum teams might be level 4. An individual Epic story might be 5. The important thing is, at each level the goals should be shared and understood by all, everyone should know the goal(s) and, hopefully, be working towards them. As Steve Jobs is reported to have said: “It’s okay to spend a lot of time arguing about which route to take to San Francisco when everyone wants to end up there, but a lot of time gets wasted in such arguments if one person wants to go to San Francisco and another secretly wants to go to San Diego.”
The beauty of numbering the levels is that we can keep on going. Although I would suggest that at some point things will become so fine grained as to be trivial and unworthy of the goal moniker (Level 99 Goal anyone?)
Notice I haven’t said anything about Roadmaps or Plans, neither of which has a place in this taxonomy, something else I might right more about in future.
Nor have I used the word strategy: strategy is sometimes used to denote a goal however when used like that I suggest strategic intent (a term coined by Gary Hamel and C.K. Prahalad) is a better term to use. Strategic intent is the thing you aim for, it is a level 1 goal. Strategy (alone) describes how you will go about achieving your goals.
Finally, to step back to meaning and purpose. These are different, purpose is about “why”, purpose is the reason for doing something. Meaning is an understanding of explanation and, perhaps, significance. Purpose tells why something is being done, meaning explains why that why is important – although at some point the distinctions breaks down and the why might become the goal. But I think there is another difference.
A recent article (“Why we don’t talk about meaning at work“) points out: purpose is shared but meaning is personal. While some people obtain their own meaning from the stated purpose others may find personal meaning in what pursuing that meaning provides for them. While leadership can articulate a shared purpose – a shared goal – they cannot articulate a shared meaning because each individual creates their own meaning.
Last week I delivered a new presentation “Honey I shrunk the backlog” to Berlin Product People. The presentation is now online and can be downloaded from my presentations page.
My previous post on backlogs (Backlogs, #NoBacklog(s) and comfort blankets) generated a lot of attention, including a comment from Derek Jones – his is one of the blogs I read most often. I thought I’d post my reply as a fill post so here goes:
DJ: “Why is a backlog bad? Isn’t it better to have some idea of what work needs to be done, and at least it shows that work is waiting to be done.”
As I understand it Mary’s comment that backlogs are a problem is based on inventory thinking in Lean. I think she was speaking in generic terms and saying “Lean thinkers see backlogs as a problem so maybe having a backlog is not a good thing.”
In a software process backlog work requests are akin to supplies delivered and held in stock waiting for production. Although they don’t take up physical space (and therefore cost) software requests do increase the cognitive load because they take mental space – if only to worry about them.
Part of the logic of Lean’s Just-in-Time approach is to “lower the water level” and make problems more visible. The same is true with a software request backlog: all those backlog items hide problems, sometimes the items may contradict and sometimes, like I suggest in my post, they distract from the overall goal.
As for knowing the work that is coming I’m not sure that is a good thing: again this will increase cognitive load, and when the backlog is run away the content of the backlog is not a reliable indicator of what might happen in future. I’d also add that I’m not convinced software engineers do a better job by deliberately designing for the future, in may experience an awful lot of code which is built “for future change” end up being bloated by unused options for a future that never happened and which hinder the future that does happen.
Future plans can also distract from what is valuable and needed now. The more developed a plan for the future it is the harder it is to walk away from the plan when needs change. That is not an argument for no planning or no plans, it is simply to say that one has to balance both sides.
DJ: “Now, if the backlog just grows and grows, and random items are selected for implementation. That’s not good, but the problem is with how the backlog is being managed.”
Let me turn this around: I am not saying backlogs that are under control are a problem. If a team has a “tame backlog” which is not too large and only growing at a pace noticeably lower than “velocity” then everything is good. But, such backlogs seem to be few-and-far-between.
My conjecture is: many organizations have “run away” backlogs and in such environments a better solution would be to move to a just-in-time backlog generator and sideline the backlog. One could step further and say: even when the backlog is tame it can be better to use a just-in-time backlog generator rather than a (semi-static) backlog.
DJ: “How do we know whether items in the backlog are being consistently prioritised or selected at random?”
We don’t. In my experience large backlogs are seldom prioritised with anything more granular than Moscow rules (Must have, Should have, Could have, Would like to have – rather than the rules of spy tradecraft) – in which case 60% is rated high or Must. Within those priority #1s there may be second priority set at a more granular level. When this happens the majority of the “musts” will be rated low, in effect they are “nice to haves”. Of the few genuine high-priorities the actual priority is not stable. “decibel” management means that they are regularly leap-frogging one another to be Number 1.
Agreed, I would suggest the behaviours with create that distribution also undermine the reactivity (i.e. agility) of the organization. If a team really was reactive then we would expect uniform, short, lead time. Conversely, if a team really was adhering to a rational plan, roadmap, requirements document, then the lead time would be longer but would also be uniform because at some point X the stories had been captured, the work had been prioritised and was being delivered in regular fashion.
Which begs the question: is a power law distribution of work-to-do a natural phenomenon which will always reassert itself or an indicator of dysfunction?
A team following my Story Generator (aka Just-in-time Backlog) model would see average delivery times of less than half the super sprint duration because any undelivered items would be deleted at the end of the super sprint.
