I’m delighted to announce Books to be Written, my book about writing books, my guide to writing, producing, publishing and marketing you own masterpieces – if finished! Is published! Is for sale on Amazon – both print and e-book version.
This is available at a special introductory price of 2.99, thats $2.99, €2.99 or £2.99 – the offer will end next Friday, 24 March so get it now.
Books to be Written – yippee! Read More »
I’m delighted to say Books to be Written is done. Print and eBook versions are now available on Amazon. A special introductory price of $2.99 / €2.99 / £2.99 applies for the first few day so buy it today.
And here is a short video explaining why I wrote Books to be Written and what to expect from the book.
Books to be Written – done and published Read More »
“How many OKRs should a team have?”
“Can a bigger team have more OKRs?”
These are among the most frequent questions asked about OKRs and I will answer both here.
First question, how many? 3. My answer, my rule of thumb: three.
Better still: one, 1. Fewer is better than more
But people seem to want more, so if you twist my arm, inflict pain and I will give in, I will admit I lied and say four, yes 4.
You should be able to count the number of OKRs on the fingers one hand. 18 is too many, 10 is too many, even six is pushing it.
One OKR is probably “OKR Zero”: the business as usual OKR which highlights the revenue protection and support work a team does. “DevOps” in modern software parlance. (See Succeeding with OKRs in Agile for the full description of that.)
Another OKR might be nominated by the team themselves to improve work effectiveness and efficiency. For a software team this might be something like retooling the delivery pipeline or addressing “technical debt.” For a customer service team it might mean adopting a new improved ticketing system or undertaking more training to increase team capabilities. (Again Succeeding with OKRs in Agile discusses this.)
Which leave two OKRs, or perhaps just one, for the main business need usually nominated by the product owner type person. Not a lot. One might be the primary, high profile, most effort, objective. While the second is, well, secondary.
Put like that it doesn’t sound a lot. OKRs, unlike user stories, are big and meaningful. They create outcomes which deliver benefit.
The logic here is that it is better to achieve one thing completely than several things partially. The aim should be for “short and fat” working over “long and thin.” The sooner something is completed the sooner it can generate benefit. The sooner it can generate benefit the sooner it can pay back the time invested and the greater the return on investment.
One of the key benefits of prioritizing OKRs is that “things can fall off the end.” Suppose a team has the four OKRs just suggested:
0. Business as usual
1. Primary thing
2. Secondary thing
3. Team improvement
Now suppose that they are forced to take on four more:
4. Something else
5. Another thing
6. Sally’s thing
7. One more thing
When prioritisation is disputed and all are considered equal, then there may well be some progress across all eight but none are completed. If they are prioritised as above then: business as usual is covered so the team don’t slide backwards. The primary objective stands a better chance of success than anything else. In fact, the further ones goes down the list the less likely it is to be achieved. (Sorry teams.)
Remember: the aim of OKRs is to create beneficial outcomes. Simply starting more work, creating more work in progress does not contribute to this goal. In fact, those familiar with Little’s Law know that more work-in-progress has the opposite effect. So adopt the Kanban mantra: Stop starting, start finishing.
When OKRs are prioritised in ascending order, with no duplicates, then above some point it is pointless to add more. Adding more only increases the amount of time needed to set OKRs and the disappointment when they are not achieved.
Even so, adding a tenth or eleventh OKRs to a team which can only really achieve four might be the path of least resistance. However, there is something slightly dishonest about it, more importantly, it misses the opportunity to have a strategic conversation.
No.
Remember the goal of OKRs is to create focus. When a team is bigger, say 16 instead of six people, it is more difficult to achieve focus. Therefore, bigger teams benefit more from fewer OKRs.
Focus is not divisible: an individual can focus on one thing. Maybe two, maybe drop everything for an emergency. But they cannot focus on 10, or even five. More work to do simply increases cognitive load and makes it more difficult to do anything.
If a team is regularly called upon to do 10 different things the solution is not to set more OKRs. The solution is something else.
This rule also applies if you lengthen the OKR cycle. If you set 3 OKRs for a 10 week cycle you will also set 3 for a 15 week cycle. Often, having more time make it more difficult to focus. How often have you missed an appointment because you had plenty of time? Yet when you have just enough you don’t let anything get in the way.
Enjoyed this post? Subscribe for updates and download Continuous Digital for free
How many OKRs should a team have? Read More »
“Any advice on how to bridge [the IT/Business] gap? Are there any rules/guidance on how a technology dept should be defining/presenting products to business functions in this context? Also, guidance on the relationship between projects/products in this context?”
I’ve received these questions from a reader who finds themselves inside a company undergoing a digital transformation. Actually, they describe the situation in more detail and there are questions about the differences between products and projects, the role of BAs and how to organise the whole place.
Let’s start with Projects v. Product
Projects have end dates – or, at least, are expected to end. Projects are usually a batch of defined work which is expected to bring about a defined outcome. Projects may run past their expected ends, may expand in scope and may fail to deliver the intended benefit but while managed as a “thing that will end” they remain a project.
Products are ongoing, in a commercial environment products continue to deliver revenue and continue to require work.
In the pre-digital age a project might developer a new product, the project ends and the thing is passed to manufacturing, or service agents, for delivery. In the digital world this doesn’t happen. Products require continued attention. This may be to keep them competitive – add capabilities competitors have; or to keep them operational, e.g. update libraries which have security flaws.
With digital products it is hard to define when new development gives way to “manufacturing”. Techniques like Lean Start-up, Minimally Viable Product and Product Discovery exploit this ambiguity to leverage learning and in-market learning. Before digital this “expeditionary marketing” technique was expensive.
There is a difference in funding too. Projects are typically funded in their own right (how much work is involved? what will that cost?). Conversely the teams which support product teams should be funded in their own right and trusted to do what delivers benefits. Product teams should be able to demonstrate at the end of the funding period that they have delivered more benefit than they cost.
Inside corporations IT Departments used to delivery projects which aimed to improve business effectiveness or support a non-digital product. In the digital corporation the business is the technology and the technology is the business, it no longer makes sense to separate technology departments from the business. The need for rapid feedback loops between “the business” and “the technologists” means that they are one team. Anything that gets in-between slows down the processes and hinders communication, and thereby damages competitiveness.
This means that digital product teams are responsible for sourcing and deciding their own work. Whereas before the business would decided it wanted to do an IT project and the IT department would be expected to deliver it now, the digital product team would spot the need or opportunity to change the product and decide to take action. They reason what using their resources to enhance the product will deliver more benefit than it costs.
The digital product teams will contain both the “supply” skills to do the digital work (e.g. programmers, testers, UXDs, etc.) and the “demand” skills to understand customers, monitor market changes and determine responses (e.g. product management and business analysis). The exact mix of inward facing BA skills and outward facing product management skills will vary depending on the product and market. Deciding what to do is product ownership, and the person task with making the “what shall we do next” decision is a “ProductOwner”. They may be supported in that role by additional BAs and/or Product Managers.
But all this doesn’t mean that projects cease to exist. Not everything is a digital product – the company may want to move offices and the move itself could be a project.
There may even be projects which impact digital products. For example, the company the new office needs a new phone system and decides to avoid the cost of laying cable by using a virtual VOIP system. This requires software on desktops plus audio equipment. It may also mean the products running on those desktops need to be interfaced to the new telephone system and the interfaces to the old PABX retired.
A office move project like the may well use Business Analysts to investigate what is needed to make the move and resulting changes. Meanwhile, the digital product teams, who may not even know an office move is planned, are unlikely to see the telephony changes early. So at some point the office move BA will need to work with, and inject work into, the product teams.
Because projects come and go, it may be that some BAs rotate between projects while other BAs are embedded in product teams. However, because digital companies will have more products and fewer projects it is likely fewer floating BAs will be needed while more remain with their teams. And because products have an outward facing, customer, dimension, many of those BAs will want to acquire some product management skills.
The product teams will probably have a stream of product development work they want to pursue to make their product even better. They will also have “business as usual” work to keep the product operational. Add to that the work arising from the projects that demand attention and you have a lot of work to do. Rather than privilege any one stream of work its it better to think of it all as “work to do”, work may come from different sources but it all gets done by the same team.
Where one team has to support multiple products things get more complicated. One product owner might be able to cope with them all it also means there might be several each with a different product focus. In these cases they either need to agree between themselves how capacity is allocated or, more likely, someone needs the authority to make those calls.
Ultimately the “IT department” and floating BAs may well go away because there are business lines, which are digital and are serviced by business focused teams containing all the necessary skills.
It doesn’t make sense for digital products to be run out of the IT department because digital products are more than just information technology, they are the business. You could say that the whole business needs to move into the IT department but really we want the IT department dissolved. Rather than structure a company as manufacturing, IT department, a marketing department, services etc. what we want to see is “Amoeba” teams which contain enough technical skills, enough marketing skills, enough delivery skills and so on.
That change isn’t going to happen overnight so while we are waiting to dissolve those different functional units companies can establish product teams where people from different functions work together. The programmers might still report to “IT” and the marketeers report to Marketing but success is judged at a team and product level.
In many ways what I’ve written here is a summary of the model I put forward in Continuous Digital: in a digital world the work is continuous, the product is the technology and companies need to restructure themselves accordingly.
Digital transformation stuggles Read More »
Money is information. I like to joke: “money is the best form of feedback.” Unlike comments in a retrospective, kudos cards, and SurveyMonkey results I can trade your information for something else and in so doing, give someone else feedback.
When someone buys your product they are saying “Your product is worth giving up …” – money in the bank, a nice meal out, a new car. You give them the product and they give you information. Money is a feedback, perhaps the ultimate feedback loop.
Within companies money also provides information. Money signals what the company values and who has power.
I worked as an agile coach with a Belgian company applying “the Spotify model” a little while ago. The leader of the tribe repeatedly told squads “you are masters of your own destiny.” He was keen, at least when speaking, on self-organisation, on squads taking control and aiming high.
One of the squads I coached decided the best way of improving performance was to improve quality: reduce bugs, reduce outages, make customers happier, improve code quality, etc. Then they asked for money for technical training and coaching. End of story.
The squad had no budget of its own. The tribe had budget but it was earmarked for something else. Asking for more budget was off the table. The squad only had power while they didn’t spend any money.
Teams, development teams specifically, rarely get to see or talk about their own budget. In fact they rarely get to talk about money at all. It is funny, most of us live and work in capitalist in free markets societies. Success is judged by profit (or at least revenue), and the aim of the company is to make money for investors.
But day-to-day how much does anyone on your team know about the finances of your team? How much does your team cost per month?
What about your product: What does it sell for? What is the profit margin on the product? How much will that new feature you are adding earn?
While managers will often talk about cost-benefit “bang for your buck” and ask “how long will feature X take?” or “is it a quick win?” it is seldom quantified. If it is then it is probably only in days or weeks not pounds, shillings and pence.
Inside the company it is almost as if we live in a cashless communist enclave where money can’t be spoken of. People even say “Its all about money” as an insult – still they expect to be paid in money and (usually) want the company to keep doing so.
But what is devolved authority, self-determination, self-organization if it isn’t backed-up with the power to spend money?
How are we to make informed decisions if we don’t know how those decisions will effect cashflow? – while we might know costs how can we begin to talk about revenue without information. And how can we evaluate the impact of our decisions if we don’t see the bottom line?
I give my children a few pounds a week pocket money. They can choose to save it or spend it, I do my best to respect their choices even when I disagree. When it comes to bigger things, holidays and even clothes, Mum and Dad make the decisions.
If companies don’t open up finances to teams then they don’t trust those teams. They are placing severe limits on what the teams are allowed to self-organize. But in almost every company I’ve ever worked for, or with, development teams are treated like children and kept away form money. Even asking about money is frowned on.
Is it any wonder engineering decisions happen without reference to financial impacts? Why should we expect engineers to suddenly become aware of the cost of their decisions when actual costs are hidden? And there is no feedback loop?
I can’t recall ever seeing a team with their own budget. Even a small budget would be an improvement (of course ultimately we want Beyond Budgeting but I’ll settle for imperfect budgets right now.)
I’ve long advocated Kazuo Inamori’s Amoeba management model. Inamori points out that in most companies teams get no feedback on their financial performance. In amoeba management, hourly efficiency reports are used to control costs and allow teams to make their own trade-offs on expenditure – not unlike beyond budgeting in fact. (In Kyocera hourly efficiency is calculated as: (revenue – (costs – wages))/hours.)
Unless teams have financial information they can’t make decisions. Back in Belgium I couldn’t quantify the cost of bugs because there was no data on salaries, contract rates, product contracts, support desk costs. I couldn’t put a value on removing bugs. But I was forced to put a cost eliminate those bugs. Consequently I couldn’t do the cost benefit equation and it was down to one man making a decision which seemed to favour some teams over others.
Talking of value without financial feedback loops is pointless.
Enjoyed this post? Subscribe for updates and download Continuous Digital for free
Lets talk about money: the ultimate feedback loop Read More »
There is an interesting piece in this week’s Economist about the poor quality of management in the UK, “For Britain to grow faster it needs better managers” (paywall). It suggests bad management is a large part of the productivity gap between the UK and other developed nations. Living in the UK, and having seen inside many British companies this rings true with me. I’ve long thought it was less a case of “In search of excellence” and more a case of “In search of mediocracy.”
Now that said, I don’t have an objective point of view: I’ve been involved with many “project rescues” or “turn arounds” (actually I quite enjoy them, call me!) in the UK but my clients abroad are normally more stable. I suspect this is selection bias: because I’m UK based it is easy to ask for help. Flying someone in from abroad is a barrier so only the better managed companies in Europe and the USA would do it. So while I might think UK management is bad it is entirely possible that it is bad everywhere. Indeed, I am sure there is bad management everywhere, and there is good management too; but in the UK the ratio of bad to good is higher.
The international agile movement doesn’t do much to encourage management to improve. All the anti-manager talk (“self managing teams”, “no project managers”, etc.) creates a barrier. It has long been my view that such anti-manager talk is largely a reaction to bad management and it is entirely possible that “no management” is better than “bad management.”
Simultaneously, “good management” can be value adding, people don’t push back on “good management” (even if it gets branded as bad just because it is management). Sometimes, making things better for the many means being unpopular with a few. The few will voice their complaints more loudly than the many will voice their praise, and often it is hard to attribute success to managers anyway.
The common agile view of management as “a bad thing” misses two points:
First off: removing the managers will remove some management work but will leave a lot. Removing managers does not remove management work. The work which remains either doesn’t get done (worse still) or is spread around those who remain so everyone’s work gets disrupted. On the whole these people don’t want to be managers, so they are unhappy and don’t have management skills. They do have other skills – business analysis, Java, support desk, whatever – so now they are not using their most productive skills and are unhappy with it.
Second, and more importantly: removing managers does’t do anything to improve the skills of those who do management work. Whether this is managers in place or people who have to step up when managers are fired. In other words, all this talk of “no managers” stops us from improving management skills one way or another.
Yes, I think workers and teams should have a voice in the work they do.
Yes, I think we should make group decisions and take into account diverse opinions.
Yes, managers sometimes need to use authority but good managers spend more time nudging, enthusing, guiding, structuring. Occasional use of authority can help, over use undermines.
Yes, I think people can take more responsibility. Some of what passes for management work is admin that could be dropped, information sharing which could be automated, or managers making work for other managers.
But I happen to think good management recognises all those things and respects the expert workers.
Bad management ignores all those things and subscribes to the “Action Hero model of management”: you do this, you do that, I’ll siege the bridge, if I’m not back in 10 blow it all to kingdom come, move it!
The irony is, those who subscribe strongest to the “no management” meme will say “Let the engineers (or doctors, or designers, or whatever) run things” but when you do that you find a management style cadre arises who are experts in their own field. Being a senior engineer (or whatever profession) often means being a type of manager, they need their original skills but they also need some management skills. If they don’t learn new skills those people become bad managers.
Is all management bad? Or is it just bad management? Read More »
Turning to my second potential silver bullet: reducing WIP, work in progress. This is easy to comprehend but hard for people to action. Again optimism plays a role: because we are optimistic, and because we don’t like giving bad news people naturally tend to take on more work than they can reasonably do. Making this worse are members of the agile community who go about talking about “commitment” and “doing twice the work” which makes people feel they should be doing more.
Culture also plays a role. When people like to present a “can do” image, when hierarchy is important and when people are accustomed to doing a little of everything and saying “No, I’m fully loaded” then reducing WIP is harder.
People are reluctant to say they are “full” until they are very close, or even beyond, 100% capacity. But the problems with queuing work occur long before 100% is hit. Even leaving aside human cognitive capacity to juggle many things basic queuing theory tells us that as work increases, the variability in work (i.e. some things take 5 minutes while some take 5 hours) means delays will occur. As capacity nears 100% the system looses capacity to absorb the unexpected (someone is ill, a delivery is late, etc.) so predictability is lost and delays spiral – the “bull whip” effect.
Notice I say system: we all work within systems, not computer systems, workflow systems. One person’s heroic efforts count for little when they work in a saturated system. We end up like Boxer in George Orwell’s Animal Farm, saying “I will work harder”, we work harder, wear ourselves out and burn-out. Too often we forget the old agile principle of sustainable pace. (Watch Stockless Production to see this in action.)
Once it becomes clear that little is being delivered, and even less to budget and deadline, trust is loss. People are less willing to see work requests queue. They want to see action, any action.
In a rational system some work will wait until there is capacity, but when there is no trust people want to see their requests being worked on. So instead of a team working on a project for a month and then moving onto the next thing in sequence the lack of trust means everything has to happen in parallel, slowly. So, a lot of work happens at the same time, there are much higher switching costs, variability creates delays and management overheads rocket. The team becomes alike a sponge: work goes in but very little comes out.
This can all be particularly tough in start-up environments. In the beginning start-up often depend on a few founders doing ridiculous amounts of work. This culture of long hours and heroic efforts. It is thus hard for people to accept that fewer hours and lower WIP might create a better outcome.
This is particularly true when the founders are still in the start-up: inevitably they worked very hard at the start and they want to see that ethos in their employees. Their start-up survived because they chased clients and worked very very hard. Therefore the founders see hard-work and lots of WIP as the recipe for success. The last thing they want is someone saying “no, do less.”
The same ethos carries over to investors who want to see lots of action, lots of people running around being busy. And because in a start-up it is hard to know what will work it makes sense (portfolio theory) to work on lots of different things to find one that wins. Again this creates a culture of high WIP.
For those seeking promotion it makes sense to be involved with lots of different work and cultivating a “can do” image. Being see as “Dr No” or shying away from work is unlikely to lead to promotion. So there are incentives to take on more work. And when such a person gets promoted than their theory of success is proven so they expect the same from others. Meanwhile, those who surreptitiously balance their work load, keep within their own capacity, beaver away and quietly delivery are less likely to be promoted.
The feedback loop promotes the wrong behaviours: each piece of work is viewed in isolation. Each one suffers its own delays and it is hard to see how one obstructs the another. The project model makes this worse because it disconnects funding (based on benefit analysis) from capability to do work.
If you are lucky you can say “Reduce WIP” and people will do it.
If you are unlucky then you need to build a feedback loop to show these problems, you need to start pushing back where you can, you need to start building trust.
See also: Two Unspeakable Silver Bullets and Why don’t people Test First?
Enjoyed this post? Subscribe for updates and download Continuous Digital for free – please share!
Why is it hard to reduce WIP? Read More »
In my last blog I describe two potential silver bullets: working test first and reducing work in progress. I finished by promising to discuss why they aren’t used more. This post briefly discusses why people don’t work test first, the second one, looks at why it is hard to reduce WIP, work in progress.
It is easy to understand why people don’t work test first: we (humans) are optimistic. Test first is hard and historically test comes at the end of a process. Because testing is traditionally (almost) the last thing that happens moving testing requires change which is counter intuitive and often perceived as risky. (That risk is very really for when work is sub-contracted: there is an incentive for the supplier to delay testing to make it harder for clients to change suppliers.)
The thing we call “Testing” has several parts. The first, should, involve working out what tests to do: test writing. Later those tests are executed (manually or automatically) against the candidate solution. If the candidate does not pass there is more work to do. While the test execution cannot occur until the is a thing has been created the tests themselves can be decided in advance. This is what I call test first: decide what tests you intent to perform. Thinking about the tests up front is an act of learning and informs the work of creating the solution.
Working test first requires thinking and it requires thinking about something we would rather not happen. Since we are optimistic we see this as waste, or something that should be done by people paid less than us. So it requires discipline to do it. You need to be able to project yourself into the future and ask “What will the result look like?” Thinking test first is often better done with others, e.g. pair programming or “power of three” analysis sessions, so keep each other disciplined.
While it is relatively easy to work test first when programming the skills required to write automated test first require some time to master. This skill still isn’t taught at most schools or colleges so people need to learn it later in their career. Since people are optimistic, they often lack the motivation to learn to write tests first so they never master the skills. Since they are always on the learning curve test first coding takes longer and they often give up before they master it. If they stay the course, if they master the skills then they will find that while coding may still take longer the elapsed time is less because they no longer need to fix things afterwards (“debug later”.)
(As an aside, I’ve long been of the opinion that when we get AI technology to write programs (which is now starting to happen) writing tests will become more important than code. While machines will write more code which executes and doesn’t crash there is still a need to test the code does what is wanted. If we have a good test set then machines can be left to iterate and mutate code until it passes the tests.)
Outside of code the testing skillset is less well defined and people are less accustomed to thinking about tests anyway. Consequently working test first is more difficult. Add to that the fact that there are many more parameters to consider, and people are more forgiving than machines and it become more difficult still.
So, while test first working might be a silver bullet it is not easy to adopt. But then, because it is hard to do it is also hard for your competitors to do which means test first can be the source of competitive advantage.
Next Why is it hard to reduce WIP?
Enjoyed this post? Subscribe for updates and download Continuous Digital for free
Why don’t people Test First? Read More »
“There are no silver bullets” wrote the late, great, Fred Brooks. Consequently most writers and evangelists avoid claiming they have a silver bullet even when it sounds like they are claiming just that. I’ve cautioned against silver bullets several times in this blog. I often find myself telling clients “The devil is in the detail.” Meaning: there are lots of things to address and no single big fixes.
Anyone claiming to have found a silver bullet deserves to be faced by scepticism. Still…
I find myself coming back to two solutions again and again. They are the closest thing to silver bullets I know. Even if these are not silver bullets in their own right applying either makes it easier to work the detail and tackle problems.
Yet these silver bullets dare not speak their name. To do so risks endless debate and damaging your own leverage.
Writing this I’m avoiding naming the potential silver bullets because I even feel many readers will stop reading the moment I name them. Please, keep reading.
Both are widely discussed by the agile cognoscenti but both are controversial. Suggesting either may lead people to think you fail to comprehend the situation or are just stupid. Thus in both cases you are likely to end up in long discussions.
Both are disliked by opposite ends of the organizational hierarchy. Both ends are optimistic, and prefer to believe people should be able to rectify problems themselves (the people problem problem again.)
Both bullets are rarely applied with vigour. Perhaps because of the previous points. When I raise the points people plea helplessness, “My boss doesn’t understand.”
Both bullets scale: in the small and large, although they manifest themselves in different ways at different scale points.
Neither is an instant fix but both start to deliver returns relatively quickly. The problem with both is you need to keep the faith and keep applying them for weeks to see a difference. In both cases, people often give up before they see the benefit.
Specifically in technical teams applying Test First coding; whether Automated Unit Testing (e.g. TDD, test driven (first) development), Behaviour Driven Development (BDD) or some other form of Acceptance Test Driven Development (ATDD). Away from code, at team and organizational levels OKRs are implement the test first principle.
Test first will not fix all problems but it will remove a substantial number of problems. That makes managing the remaining ones easier. And as to where the “extra time” comes from, that is easy: the time you don’t spend fixing defects and misunderstandings. Test first is faster than debug later.
I’ve written a lot about test first so I won’t say more just now.
Most commonly WIP limits are applied through limited columns on a Kanban board or limiting the work taken into a sprint. Done right OKRs limit WIP too. However, reducing WIP requires discipline.
At the higher levels companies and Government entities seem quick to reduce staffing numbers but slow to reduce work. Accepting new “projects” is easy but resourcing them difficult. Rather than prioritise, say “No” and push back on work, everything is taken on. Individuals who push back as seen as pessimists, “not team players” and “obstacles.” Pushing back does not help your chance of getting promoted so leadership ranks tend to be populated by those who accept.
The result is salami sliced people and slow progress across a broad front rather than rapid progress across a narrow range. But, reducing WIP also seems to be the hardest medicine to administer. In fact, I sometimes find myself hiding WIP reduction measures.
As an aside, I feel WIP has gotten worse since the pandemic struck, the move to remote working means every conversation is now a meeting in the diary. Our diaries are now overrun with “Meeting WIP”. An ad hoc 10 minute conversation at the coffee machine is now a 30 minute Zoom call planned days in advance.
WIP reduction is applicable at all levels: reduce the number of pieces of work the individual is switching between, reduce the number of pieces of work teams are tackling, reduce the number of projects a department has in flight, and most of all: reduce strategic WIP.
There are lots of benefits of reducing WIP so let me ask: why is WIP so difficult to reduce? – that is the question I’ll address next time. So too is Why don’t people Test First?
Finally I’ll just note: I sometimes wonder why I stop being an OKR-cynical to learned to like them. The thing is, I see OKRs as a tool to address both these problems: OKRs are test first, and limiting OKRs is WIP limiting.
Two unspeakable Silver Bullets? Read More »
OKRs offer a way to connect strategy – high level abstract goal type things – with delivery – low level concrete detailed task level things. OKRs offer a middle level planning. They are replanned often enough to be flexible while lasting long enough to give enough stability to take on bigger, more ambitious work.
As with so much else about OKRs there is a more agile way of going about this and a less agile way of going about it. Connect strategy to OKRs in the less agile way and you end up back at command and control. The give away sign is that OKRs cascade down the company so teams don’t control their own destiny, ambition is neutered and motivation is lost.
Which approach you take will largely depend on the seemingly academic question: “what is strategy?”
Many people see strategy as a one way street. Strategy making and execution is hierarchal with decisions made at the top are passed down. Alternatively strategy can be seen as emergent property of a cooperating network. Strategy is a two way street, each node both informs strategy making and execution is guided by the resulting strategy.
Depending on how you view strategy you are going to implement OKRs very differently.
Sad to say, the predominant view of strategy is that it is some sort of grand plan. The plan sets out the “place” the company aims to get to (price, position, etc), plus the route for getting there. Anyone who has studied a little strategy will recognise this as the “Porter view of strategy.”
Strategy as planning inherently sees strategists as master planners, all the relevant information is fed into the strategy/planning department. Experts analyse the data and rationally decide what needs doing. The plans are sent out.
This is inherently hierarchical so it natural to use cascading OKRs as the implementation mechanism. But because teams have little say in setting their OKRs motivation is lost and ambition is neutered.
The is a machine like view of organizations, inherently top-down, deviation from the plan, the strategy, is an error. When OKRs do not directly support strategy OKRs need to be changed.
Study a bit more strategy and you will find that while Porter’s view has appeal it is not the only view. There are in fact many different schools of thought on what strategy is.
To my agile mind the “emergent view of strategy” fits better. Strategy emerges over time from the activities of the organization, part planned, part reactive and part backward looking to explain the past. Professor Henry Mintzberg describes strategy as “a pattern of behaviour over time” which chimes with my pattern thinking.
Strategy is a two way street, teams are edge sensors: detecting technology changes, production techniques, putting products in the hands of customers and gathering feedback. This allows learning and adaption. The organization as a whole is a learning entity: discovering customer need and mastering new capabilities. Teams have the authority to act in the best interests of the company and customers. Over time strategy emerges.
When OKRs do not reflect stated strategy it is a learning opportunity. Ask: why do team OKRs deviate from strategy?
Is the team seeing something which the strategists do not? – in which case the OKRs are signalling back from the edges to the centre.
Is the team able to follow strategy? – maybe it lacks skills or capacity, or maybe it is overloaded with “business as usual.”
Has the intended strategy has been clearly communicated? Or maybe there is no explicit strategy?
OKRs, like other agile tools, are problem detectors exposing opportunities for improvement.
Perhaps obviously, the “Strategy as a plan” view is going to limit agile to a back-room delivery thing because it passes over the opportunities for feedback and centralises decision making. Conversely, the “Emergent strategy” view entirely compatible with devolved authority, independent teams, experimentation and “the agile mindset”.
When teams act on their own initiative the organization will be more agile. When teams wait for instructions everyone is less agile. There may be a price for agility: teams may repeat work, teams may pursue the “wrong” goals but the price of that efficiency is lost agility which costs in missed opportunities and improvements.
If you want high levels of efficiency and believe in planned strategy you will look to decide strategy and align OKRs with the strategy before you do anything else. However, that results in less agility.
If you want to using OKRs and maximise agility then you need to take an emergent view of strategy. In many ways, we back to the Theory X or Theory Y question.
Download Continuous Digital for free when you subscribe for Allan’s updates
Why OKRs require a strategy rethinking Read More »
