I am indebted to Yoan Thirion for created this infographic to illustrate Succeeding with OKRs in Agile. He’s done a brilliant job on both the graphics and the summary – undoubtedly better graphics than I could have done and probably a better summary than I would too, sometimes one can be too close to a thing.
Q: What do you guys think about Business Agility?
My reply: Business Agility, bit like apple pie, how can one not be in favour?
Of course, what flavour of business agility is another question. Lots of people seem to use the words “business agility” but I’m not sure there is a consensus on exactly what it is. I am a member, and supporter, of the Business Agility Institute which was founded by Evan Leybourn who also published a NoProjects book.
Evan and I were in regular communication while we were writing our books, we both saw the flaws in the project model and both arrived at the conclusion that as the business world digitalises business is never done therefore technology is never done. In essence that is the genesis of Continous Digital. While I wrote a book on the subject Evan founded the Business Agility Institute.
Q: So whats your take or how you think business agility is different from no-projects? is people just rebranding stuff to BA now?
My reply: Business Agility is good, it makes sense to go “up” from software to the business. Now look at the things you might want from Business Agility:
▪ Quick to market
▪ Fast to deliver
▪ Responsive to customers
▪ Reactive to trends and changes
▪ … add your own here…
Isn’t that what any business wants? Whether you call it Business Agility or not? – these are apple pie things, hard to argue against and if you read (almost) any management textbook in the last 30 years they say the same things.
These aren’t #NoProjects, that is a very specific critique of the project model. Some people may have believed that projects facilitated those things, however what #NoProjects says is: the model is flawed, if you want those things you need to find another way. For me that other way is Continous Digital, which is why my presentations talk of #NoProjects evolution: it is not enough to say “projects don’t work”, one needs to suggest an alternative.
So how is Business Agility different?
First off: even if the things Business Agility offers aren’t new the rise of Business Agility is a new opportunity to push an agenda which is good, sometimes things need to be “rebranded” as new to get attention. Should’t be but there you are.
Second, the methods have changed: two forces at work here, Digital and “Millennials”
Digital tools – driven by Moore’s Law and the falling price of CPU power – have changed the way business works, it means that the things executives often want to avoid, software development, is now the power house of your business.
Hence, “the business is the technology and the technology is the business.” Think Uber: how do you separate Uber’s technology from Uber the taxi company?
This is why I have take to saying “IT is dead, IT’s Digital”. Information technology in business is no longer a cost centre, it is no longer “just” and enabler for business services, Digital means it is the business, it is were innovation happens and it is a driver of revenue and profitability.
That also means “Agile Methods” (a la software engineering) come into focus because a) you need to create software and b) as digital tools permeate every aspect of business life agile becomes more applicable.
Agile methods are the processes that maximised the benefits of digital tools. Agile started with software engineers (and friends) because they had early access to digital tools (email, IM, VOIP, web, wiki, etc.) and are able to create “missing” tools
Millennials: those born about 2000 are said to want more meaning, purpose and autonomy in their work. Personally I’ve always wanted these things and I think everyone does. Whether I am right or not this is a trend which has been running for a while, millennials exhibit this most clearly. (Plus the pandemic adds to this)
This too fits with agile because agile methods recognise the people aspect, people in agile are not plug compatible (although we do encourage a more team based approach.). Agile considers motivation and recognise those doing the work as experts in their own right – are better at addressing that need.
Hence, and a point I’m making in my “Reawakening Agile with OKRs” presentation which I’m delivering this year, we need to think more about purpose driven development – PDD. Our software needs purpose so our people have purpose.
Ultimately, while business agility might not be anything new there is a greater need for it.
In my OKR book I advice teams to forget about the backlog and instead use the OKRs as a story generating machine. As I expected, this grabs people’s attention. For many this might be the most surprising piece of advice in the boo, and perhaps the most controversial.
So it is hardly surprising that there were several questions around this:
Q1: If the backlog isnt a reflection of what we need to do in order to move towards our vision what is it for?
Exactly. If the backlog does not reflect your vision then what is the point of a backlog?
First off, if the backlog is aligned with your vision, and things are working well then why change? Certainly don’t add OKRs unless they are addressing a problem, and when you add OKRs see if there is anything else you can remove. If OKRs are simply repackaging the backlog then why both? Why add to the tools and processes in use?
For a few fortunate teams that is indeed the case. However, for many teams the backlog also contains a multitude of work which is not part of the vision and requested fixes. The backlog long ago became a dumping ground for requests.
Yet removing work from the backlog becomes hard. Product Owners feels they lack the authority or confidence to actually say “No, we will not do that.” At the same time the teams performance is judged by “how much backlog” gets done. Success or failure come down to “is the backlog done?” Thus the backlog comes into conflict with the OKRs.
In the book I introduce Jeff Bezo’s “Day 1” approach where company works as if today is the first day and questions what they are doing. OKR setting needs to be a day-1 experience.
Q2: Backlog needs reviewing to align with OKRs, surely?
That is one approach, set the OKRs and then before or during every planning meeting comb through the backlog and find work which will move you towards the OKR. That will work if you have a few dozen items in the backlog but what if you have a thousand or more? What if the backlog has been passed down from a previous product owner or a requirements document? In both cases that work will be harder.
The bigger problem is: what if you think of something that is not in the backlog and will move you towards the OKRs?
Do you say No?
I expect not, I expect you will quickly write it, slip it into the backlog and say “look what I just found”
Now the backlog is a collection of ideas which might, or might not, help achieve the OKRs but which you might not do.
At which point, what is the point? Why not just brainstorm what you can do?
Q3: Isn’t OKR then a guidance to create Backlog? or prioritize it?
Create a backlog, yes, the OKR is guidance to create a backlog – its a story generating machine. So what is the point of having 500 stories which describe work not related to the current OKRs? Will not get done anytime soon? And likely will never be done? But which confuse the governance process and drawn everyones morale because “we still have 500 PBIs to do.”
Once you have your OKRs then there is little point in creating any more backlog then you will do in the next three months. You may generate 12 months of work but since OKRs are reset every three months the chances are three quarters of those stories will be thrown away.
So every quarter reset the backlog and start over. That is pretty much what I’m advocating.
Prioritizing the backlog, see Q2 above.
Q4: How have you approached the removal of backlogs? small experiment?
Q5: Have you done this in real life? How did you persuade people?
OK, you found me out, we didn’t actually throw the backlog away. There was some history in there which was useful and more importantly it would have drawn too much attention to the team. Instead we just ignored it.
This started as a small experiment between me – as Agile Coach – and the Product Owner: we just opted to ignore it.
We set the OKRs based on current priorities and strategy. Then in the planning meetings if we knew of a story in the backlog we pulled it up. But actually, this turned out to be more work than it was worth. Plus, by challenging the team we got better answers and more involvement.
It didn’t take long before the team noticed what was happening but I don’t think they minded much. Again they might say “O I know there is a story in there to do…” but more generally we just wrote new stories there and then: the OKRs were a story generating machine.
In the book I describe a further experiment I ran with another coach, as a result she came to the same conclusion: OKRs before backlog. While we shared this with other coaches – and indeed anyone who wanted to talk about it – we didn’t make a big fuss or publicise it. I’m doing that now.
I see this approach as the logical conclusion of working with OKRs so I don’t think you need to make a fuss. You can just do it and I expect more teams to reach this conclusion. Except of course, those backlog-slaves who are labouring under corporate agile to burn-down the backlog!
Succeeding with OKRs in Agile is available in print or ebook format from Amazon now, an audio version will be out in the next few weeks. I will be repeating Reawakening Agile for Agile Newbury next month and discussing OKRs with Adrian Reed in May.
It shouldn’t surprise you to learn that I’m doing a lot of talks about Succeeding with OKRs in Agile at the moment. Last Tuesday spoke to Digital Transformation in London and Lean Agile Coaching London groups (a joint Meetup). At the end there were a lot of questions and I didn’t get to answer them all – in fact more have come in on mail and twitter since. I’ll try and answer them here, but there are so many questions I need to split this post in two.
Q: You said “the companies which make the most profits don’t aim to maximise profits.” Do you have any references for that?
A: I’ve heard this argued several times, although its not a clear cut case because you can’t do an experiment and profit isn’t always the best measure of commercial success. You might look at share price, or earning per share or several other measures.
The most recent – and probably the best – evidence I’ve seen is from Alex Edmunds in his book Grow the Pie. Edmunds argues that profits are but one part of the value created by companies, those who focuses exclusively on profits neglect the other parts, society looses out, and profits are less than they could have been.
The good news is Edmunds presents lots of evidence, and counter evidence. The bad news is: that can make for a lot of reading – sometimes dry.
John Kay in Obliquity makes a similar point in a more readable book but one that lacks so much hard research. Another book worth reading on the subject of profits and value is Mariana Mazzucato, The Value of Everything.
Q: Where I’ve seen companies use OKRs they are set by the people at the top and passed down the organisation. Surely letting teams set their own OKRs would loose alignment?
Yes, I get the impression that this is what many companies do. But to my mind that is little more than a re-invention of MBOs (management by objective) and ignores agile. Agile demands that teams be given real responsibility and authority.
As for alignment I would rather the organisation put its efforts into removing the need to align, removing dependencies and building independent, autonomous teams. (I’ve written about Amoeba teams and the MVT model before.)
This is not to say alignment isn’t important but it is secondary. First you want teams which are delivering benefit, when you have that you can seek to optimise them.
Q: How do OKRs work in organisations with large numbers of teams who need to resolve competing visions and priorities but who depend on each other?
Q: To what extent should OKR’s be negotiated – either between teams (where Team A is dependent on the output of Team B); or between senior management and Teams?
OKRs aren’t a silver bullet. Yes OKRs can help, because OKRs define an API to the team you can tell others what to expect. Better still, you – or your product owner – can consult and negotiate with those other teams and find out what they need.
The ultimate answer is not better co-ordination or even communication, it is removing those dependencies, making teams more independent. Conflicting OKRs will highlight those problems but aligning those OKRs will never be a complete solution.
What you absolutely must avoid is having one person, or a small cadre of people, decide what each group needs and issuing OKRs to others to fulfil it. That destroys team independence, the aim here – in agile, in the twenty first century, in digital business – is independence.
Some people talk about these ideas under the title “Descaling the corporation.” This about increasing team coherence and reducing coupling. Corporation need to reduce the connections and dependencies.
Q: How granular should OKRs be (in terms of departments), e.g. should you have separate OKRs for Product and Customer Success? Even though they are both partially responsible for renewals?
I’d have to look at the context here but in general I would rather remove that distinction between those departments. Your aim is “customer renewals”, the question is “what can we do to increase renewals?” – maybe that is best achieved through a product enhancement, maybe through helping customers succeed or maybe though something else. Don’t just span boundaries, rethink them. Start with the outcome and work back rather than starting with your own structure.
Q: How to start to introduce OKRs in corporate environment?
Q: What can be a first step with OKRs in deeply traditional company?
As always start small, run an experiment. However, there is a difference to agile. My approach to agile has always been very much “just do it.” There are lots of agile practices and you as an individual can just start adopting them, in time you can involve other people . Its far easier to introduce agile bottom-up than top-down.
But with OKRs things are a little different because OKRs are a team level tool. So right from the start you need to take your team with you. Second, because OKRs represent a communications interface – a team API if you like – and because Agile OKRs require respect for team autonomy you need someone a little higher up to support the move. That someone should be able to provide “air cover” for your experiment.
Once you have those positions in place then just try it, run an experiment for a quarter or two. Hopefully you will be able to see success which can propel you further and help enrol others.
One technique I’ve used before it a book study group: gather some people who are interested in learning and improving. Choose a book – my OKR book being the obvious choice! – and meet (lunch time if you want) every two weeks. Work through the book together, discuss every chapter.
I don’t think that prescription changes if the company is “deeply traditional” – although I expect the journey will be harder, you may have more trouble recruiting companions or securing air-cover.
Q: How do you deal with resistance of change in organisations?
Unfortunately there is no silver bullet. I feel introducing any change is often an exercise in throwing mud at a wall, or even banging your head on the wall. The level of personal perseverance can be very high, make sure you celebrate every win no matter how small.
Perhaps the best advice I’ve ever heard comes from the head of the IMF, Kristalina Georgieva, she was asked a similar question in a Financial Times interview last year: “The mistake we often make is to try to zero in on the naysayers and try to convince them, rather than empower and excite the agents of positive change and just ignore the noise.”
Q: How much would you like SMART kind of goals comparing to OKRs?
Most of SMART – specific, measurable, achievable, relative and time-bound – works, although more at the key results level than the objectives level. I would take issue with the A though – achievable or attainable depending on your preference.
Really you want goals which are a bit more than you think you can do. Otherwise you get a problem that economists call satisficing: people aim low, they play it safe as a result the whole exercise becomes a game play.
Now each organisation needs to make a call on what level of balance they expect. Google apparently only expect 70% of OKRs to be achieved, they lean towards more risk, less predictability and more misses.
I do think it is important that leaders stand up and say very clearly what they expect from teams using OKRs. Is the company challenging teams to do their best and accept some failures will occur? Or does the company value predicability and accept some slack in the system? Both are valid choices.
Q: How do you come up with the hypothesis of the Key Results?
Good question, and it is not one confined to OKRs. I’m going to duck the question and suggest you read Barry O’Reilly on Hypothesis Driven Development.
Q: It sounds like you view OKRs as a “root and branch” replacement – its all or nothing?
No, I think you can add OKRs to an existing agile system – that is what I was part of originally. But, once you start working with OKRs and once you start following the logic of OKRs, that is where you end up.
I’ve arrived at a point where I hope OKRs are the basis for a big change in the way we do agile. As I said at the start, many companies do a form of “corporate agile” which lacks the high aims that many of us who dreamed of when doing agile in the first decade of the millennium.
Q: Why do you think the corporate agile virus exists and what is the cure for it?
I could give you a dozen reasons and the truth will still be something different. Let us be clear, corporate agile is better than what went before but it falls far far short of what we dreamed about at the start of the millennium. Right now the biggest problem is probably scaling, companies want a high R-value but in chasing agile working they are getting teams with a very low E-value (effectiveness.)
The cure is the one true test of agile, ask the question: Are we still working the same way we were three months ago?
If you are (the same) then you are not agile. Agile is about learning and changing, hopefully for the better but there will be some backwards steps. Learning creates change and change creates learning – experiments help. Keep learning, keep trying new things, keep changing.
Q: How is this different from the OKR we apply to Strategic themes in Lean Portfolio Management?
I’m not familiar with Lean Portfolio Management so I can’t really comment. Quite possibly it is an alternative implementation of the same ideas.
Q: What if a company has Vision & Mission, and KPIs (company wide, squad wide). should we implement OKRs also?
First: are those things giving you what you want? If so then leave well alone! You could conduct an experiment with OKRs, take a couple of teams, relaxed the other metrics and let them run with OKRs for a year then look at the results.
I don’t know how exactly you are using vision and mission but I would assume you retain them. OKRs are about delivering, in the next three months, progress against your missions which themselves build towards your vision. They should all be expressing your purpose in different words over different periods.
KPIs is more tricky.
To my mind KPIs are a measuring tool, they are a way of saying “We are 1.4 meters high.” In that sense they are compatible with OKRs because you would just have an OKR to advance an KPI, “Objective: increase KPI to 1.8m.”
However, if you are using KPIs as targets things are different. They are overlapping with OKRs, in which case use one or the other.
Finally, mission, vision and KPI already sounds like a lot of competing techniques, if you are going to add OKRs please look again at how you manage “objectives” (in the broadest sense). You may have too many mechanisms. If you are adding OKRs be ready to remove something.
Q: What would you say is the biggest regret / challenge in Succeeding with OKRs in Agile? Something you wish you could have done differently?
Half of me wishes the book was smaller: I believe people are more likely to read (and buy!) smaller books. In terms of getting this message out there I think smaller is better.
The other half of me wishes the book was longer: there is more I have to say, some chapters were left “on the cutting room floor”. So there may be a sequel with these and some new chapters. Plus, a rewrite of a few chapters were I think the message could be reduced and made clearer.
Q: What is / will be the #-tag for these better smarter corporate agile virus enhancing OKR?
Ha ha, I was burned by #NoProjects, it made me famous but I still have the burn scars. So I am absolutely no going to say #NoBacklogs – although you could read that into some of my work.
Increasingly I think Agile needs to lay claim to bottom-up OKRs, not the MBO-lke top-down OKRs which I see some adopting and even hear being advocated. So maybe #AgileOKRs.
Audio book coming soon
Backlogs are a good idea. Backlogs ease the transition from the old “requirements up front” world to the new more dynamic agile world. Backlogs provide a compatibility layer for agile teams to interface to more traditional project management and governance. Backlogs even allow you to take a stab at done date!
Backlogs allow you to even out work between the quiet periods and the busy times. Backlogs give you a place to store good ideas which you can’t do just now. And because stakeholders can see their request is not forgotten they don’t need to shout for it today.
Yes backlogs are good. I’ve seen them work well myself and I’ve taught many teams to effectively use backlogs.
But – you knew there was a but coming didn’t you? – but…
Backlogs have problems, too many teams are labouring under the Tyranny of the Backlog, they have become backlog-slaves and practice something we might call BLDD – Back Log Driven Development.
(To be clear, when I say “backlog” I am primarily thinking of the product backlog – the long list of all the things the team (might) do in the future. This is different to the sprint backlog (iteration backlog). The sprint backlog is a shorter list of things the team aims to do this iteration. I am using Scrum terminology but the ideas are pretty much “generic agile” and I’m thinking more broadly than Scrum. Many implementations of Kanban feature a product backlog of sorts so while Kanban is less prone to these problem it is not immune.)
1) Lump of Work Fallacy
There is usually an assumption that the backlog represents all the work to be done – an impression reinforced by early implementations of Scrum. In the short term that leads to agile teams being seen as inflexible and prioritising process over need because new work is not allowed in.
In some cases teams even struggle to get started on work because a big-up-front requirements gathering and analysts activity is required to create a backlog. In the worst cases that work is even estimated and end-dates forecast before a line of code is cut or developers hired.
In the longer term it is simply unrealistic to assume the backlog is fixed. Even with more and better analysis it is impossible to foreseen future requests. The agile adage “it is in doing the work that we understand the work” cuts both ways: coders understand what they need to build and customers/stakeholders/analysts understand what they want.
Work will arrive after you begin, any system that does not incorporate that truth will fail one-way or another.
2) Bigger than you think
Not only does the backlog grow with completely new work the work in it changes – and grows. There are many reasons this happens: new opportunities appear, hidden ones become clear, requests require more work than expected and so on.
Humans are very bad at estimating, especially about the future, and, it turns out, they are also very bad at estimating time spent in the past. If you want accurate forecasts you need to invest in them, you need to make structural changes and you need to use statistics.
However, because of the lump of work fallacy and the belief that humans can make estimates, poor end-date projections get made and when they are missed (because they were wrong to start with) everyone gets upset.
3) Fallacy of Done
Backlogs come with burn-down charts and an assumption that there is an end; and that end is when everything is “done.” The team will be done when the backlog is empty. That assumption is baked into BLDD, traditional project management and even governance.
I have long argued that software is never done. I’ll accept that I might be wrong, but in the digital age, when business runs on digital technology (i.e. software) your products are only done when you business is done. The technology is the business, and the business is the technology. Stop the backlog growing, stop growing you technology and you kill the business.
4) Backlog Bottomless pit
Put all those reasons together and the backlog becomes a bottomless pit. In the early days of agile, when I managed teams myself, the backlog would often sit on my desk, written out on index cards and held together with rubber bands. I could get a sense of how big the backlog was my looking.
Today everyone uses electronic tracking systems. Not only do these allow an infinite number of items they rob us of perspective. To paraphrase Comrade Stalin: “2 outstanding backlog items is tragedy, 200 is a statistic.”
5) Backlogs obscure strategy & purpose
With so many backlog items it is easy to get lost – you can’t see the wood for the trees. Arguments over what will be done next start to resemble deciding who should get a lifeboat place on a sinking ship, add in the demands “when will you be done?” (plus explaining why the date has changed) and “the bigger picture” gets lost.
In Back Log Driven Development the sense of purpose and strategic goals is lost as teams struggle with the day-to-day demands of just doing stuff.
6) Powerless product owner (i.e. backlog administrators)
Tyranny of the backlog seems worst where product owners lack real authority and skills. They are little more than backlog administrators. They spend most of the week adding requests to the backlog, then passing a few chosen items to developers in planning meetings. A vicious circle develops, the product owner can’t win so people trust them less, their authority wanes, and the backlog spirals.
Few organisations give product owners the power needed to get a grip on this situation. Indeed, many product owners are plucked from the ranks for development or support and given a battlefield promotion to product owner but lack the skills required. (See The problem with Product Owners.)
For years I’ve been suggesting teams throw away the backlog – you will not forget the important things. But then how do you know what to do?
Take a step back, start with your purpose, your mission, the reason you team, your company, your organisation exists. What should you be doing? How can you fulfil that purpose and serve your customers?
This is where I see a role for OKRs and jobs to be done. Both these techniques – together, or separately – can be used as story generators. Every time you need to more work, more stories, you return to your OKRs and ask “what can we do now to move us towards our objective?”
When writing Succeeding with OKRs in Agile I became more and more convinced this is the path to take. Increasingly I sum this up as Purpose over Backlog.
Post publication addition: great suggestion fro Jari Mäkelä on Twitter to call this: Purpose Driven Development, PDD.
Step 1: Clarify your purpose – what is your overarching reason for existing?
Step 2: Clarify how your existing strategy builds towards that purpose, and if you don’t have a strategy create one.
Repeat steps 1 & 2 annually.
Step 3: Think broadly, set your OKRs as a team so you build towards your purpose by following your strategy.
Step 4: Spend the next 12 weeks executing against those OKRs
Repeat steps 3 & 4 every 3 months.
Step 5: In each planning meeting take stock of what you have done and progress against OKRs
Step 6: Ask “what do we need to do next to move towards the OKRs?”
Repeat steps 5 and 6 every 2 weeks
And if you are Kanban’ing then keep steps 1, 2, 3 and 4, adjust 5 and 6 as appropriate.
I’m delighted that my new book Succeeding with OKRs in Agile went on sale at Amazon yesterday. By this morning it was the number #1 best seller in Amazon’s IT Project Management category – and not doing badly in Computer Programming and Business Management & Leadership either. (Although the publisher has some power over which categories a book is in it is still a black-art.)
It is hard to express just how great it is to see the book in the number #1 slot. While I hope it stays at #1 for a while I expect it will drop down before long.
Print and audio versions of the book are in the works and should be released in the next few weeks so if you would rather read a physical version or listen, watch this space as they say.
The book has taken a little under a year to write and a few more months to make production ready. The wonders of LeanPub mean many readers have already been enjoying early versions of the book. If you would like to read the book on iBooks or as a PDF then LeanPub is the place to buy from.
I recorded the little video below to explain why I wrote the book.
I don’t read many books about software or technology these days, I tend to read outside the domain: economics, business and management – which after all is much of what I do in the technology world these days.
Recently I’ve been reading Winning now, winning later by David Cote and find really interesting. He hardly mentions software and never mentions agile but he is giving me a new perspective on technical issues, particularly technical debt (or technical liabilities as I prefer to call them). He talks about issues which have similar characteristics to tech debt but are completely different, legal issues for example. He sees these issues as conflicts between short-term thinking and long-term thinking.
Cote’s argument is that short term actions should support, not conflict, with long term goals. I agree. It might not be easy but if actions in the hear-and-now conflict with longer term goals then the chances of reaching those goals is diminished.
Cote is writing about his time as CEO of Honeywell – a US industrial conglomerate if you don’t know. Unusually Cote is honest about many of the dirty problems the company faced when he took over – a lot of business books glossy over such problems or talk about “challenges” or “opportunities”.
For example, Cote describes how Honeywell managers were chasing numbers and targets every quarter. They had no time for long term improvements because they were so busy “making the numbers”. One of his managers cut down a forest to sell as timber in order to make the end of quarter numbers. Sales people would give products away to new customers or offer large discounts at the end of the quarter. However customers knew this would happen so delayed orders until they were sweetened.
Making the short term numbers meant the company undercut itself so lost revenue next quarter. Management time was spent finding accounting tricks to “make the numbers” rather than improving the business. And since targets ratcheted up the next quarter was more difficult and required more diversions.
Other examples included legal cases Honeywell was fighting: spending time and money on lawyers, building up bad will with customers, politicians and local people. This in turn made it more difficult to get support when the company needed it.
I read these examples, and others, and I hear an engineer saying “Technical debt.” That is exactly what it is.
A software engineer who does a dirty job on a code change because they feel under pressure stores up problems for themselves and future engineers who need to do the next change. Which is exactly the same as a factory which dumps waste into a lake as a quick fix and then needs to clean up the lake later.
Actually economists have a term for this: externalities. These are the costs which are forced onto other payer, e.g. the factory saves money on waste disposal but the local government has to pay to clean the lake. I’ve long thought a lot of “technical debt” could be considered an externality because it pushed the cost onto someone else.
Today it is probably harder than ever to escape these cost – in code, in law, in financing – because there are more and more people out there looking for these things. Environmentalists look at waste in lakes, society expects companies to pay if they pollute and courts make companies pay. Smart investors will look closely at a firms accounts and discount the firm, or short them, if they see dubious practices.
This is Cote’s argument: in the short term it might save or generate money to fight legal cases (deny deny deny), sell off forests, discount sales and such, but, in the longer term – and the longer term might just be weeks – it will costs. And when it costs it will damage growth.
Doesn’t that sound just like technical debt/liabilities?
Naturally it is hard to see a company that chases numbers, pollutes and fights all legal claims caring about the quality of code. Engineers will have a hard job fighting for technical excellence there.
Cote argues, and I agree with him, that it doesn’t have to be this way. Acting responsibly and thinking about tomorrow – whether that is pollution, sales, accounting, code quality – will make it easier to grow later. Just because it is difficult to act in a manor that meets todays needs and make the world better for tomorrow does not allow use to ignore it: all of us need to think harder and find a solution that doesn’t mortgage tomorrow.
And sometimes the right answer is to accept the slow path, take it on the chin, pay the cost you’ve been avoiding. For Cote that mean settling legal cases and accepting some costs, for software teams that means doing the refactoring, rewriting a module or just saying No to more changes.
As I’ve said before: in software the long term comes along very soon.
As as I’ve blogged before there is no such thing as quick and dirty, only dirty and slow.
We might talk about debt/liabilities but really we are talking short-term v. long-term, a pay-day loan v. investment. Engineers have an unfortunate habit of talking about technical debt as a binary good v. evil debate with no other options.
Finding these less obvious paths which satisfy the short-term and long term is hard(er) but also offers the opportunity for higher, and longer, term improvement, something which is itself a competitive advantage.
Before Christmas I recorded a couple of new podcasts which went live this week. The first was with Luke Szymer for his Align Remotely podcast series and focused on the topic of my new book, Succeeding with OKRs in Agile and is release in two parts. Luke also has a new book, it is timely and well worth reading – as is anything Luke writes – also called Align Remotely.
- How to delegate remotely (part 1)
- How to Inspire Dramatic Change (part 2)
The second podcast was with Ian Gill of Agility by Nature. This was a casual, wide ranging, conversation.
Finally, the video above: Living Continously with Agile and Digital.
From time to time I also give private presentations to companies. Sometimes there are existing conference or user group presentations, sometimes this is new material. While companies generally pay me for these presentations I always feel the need to share further. So, after removing any client specific references I’m re-recording these and posting them on YouTube in a Private Presentations playlist.
For the record there are a few words I avoid using if I can.
Should: “we should feed the starving millions”, “we should create world peace.”
Should is useless.
It is also a declaration of what should be but also an admission of defeat, we give up immediately, we don’t even try.
Empower and empowerment: “I will empower the team”
It was Henry Mintzberg who alerted me to the problems with this word: empowerment is a loan. Empowerment is not real power, not real authority.
That I empower you means “I have the power, I am going to lend it to you… but I am still responsible and if you screw up I’m taking right back.” Thats why I prefer to talk about devolving, distributing and even sharing authority.
Commitment: “The Scrum team committed to delivering 20 points”.
Actually my dislike of commitment is usually confined to software teams and older implementations of Scrum specifically.
First commitment tends to be one sided: the development team are expected to commit but not their customers. And in an environment were the team is not completely independent (i.e. there are times when it needs non-team members to do something) it is unfair to ask them to commit.
This is very true in large companies where teams are often restricted by a multitude of rules, demarcation lines and restrictions. Such teams don’t have the power to commit on their own, they need others – and superiors – to join in making thing happen.
Second, because of those problems the word “commitment” itself has changed meaning. Originally when a team said “We commit” it meant “We are going to make this happen, come hell or high water, we will do everything in our power to make this happen.” Over time, because the team couldn’t move heaven and earth due to company policy, commitment has become devalued. Today, “commitment” has come to mean “This is the work we plan to do this sprint and we will try out best (but don’t get your hopes up too high).”
I’m sure there are some more words I avoid using but less often, I’ll make a note of them next time I’m temped and report back.
It is 2021 and unfortunately on Friday I felt the need to repost “Dear Customer, The Truth about IT“. Little has changed in the 10 years since I wrote the original – if I was writing it today probably the only thing I would change is “IT”, I’d write “Digital” (I should probably also change Manchester United but …).
Unfortunately the vast majority of supplier’s are engaged on the basis of their marketing materials, sales pitch and promises. This tells you nothing about their actual ability to deliver working software. The suppliers can all hire great marketing people and use the same words. They can hire and incentivise the best sales people, and they can all take you out for a good meal, a round of golf or to a strip-club. (O, and they can all find a few “satisfied customers” to provide a testimony.)
The only real way to know if a supplier can deliver is to see them in action. So how can you tell things might be going wrong? What are the warning signs?
With help from Mike Burrows and John Clapham I’ve came up with this list of early warning signs. We were thinking in the context of a client-supplier (outsourced) relationship but many of them apply if you are working with internal teams too.
1) Supplier loads teams up with extra managers: test managers a speciality
1.1) Team members don’t make decisions and defer problems to managers: there is a manager for every problem
1.2) Offshore teams have parallel management hierarchies
1.3) Suppliers feel the need to mark all your managers with their own manager (who is then duplicated offshore)
2) Inverted staffing pyramids (few devs at the bottom, lots of managers, BAs & other non-coders above)
3) People get swapped by suppliers with little notice
3.1) Short term substitutions are made: I once saw a supplier bring in a temporary SAP HR consultant to cover the usual consultant’s 2-week holiday. There was no way the substitute could come up to speed in that time let alone contribute positively.
3.2) People bait & switch: the people you meet first met didn’t last long, they were substituted for inexperienced people
3.3) “I can do that” – you get people new to their role, you get who they have available, people with experience in one role fill another role; a project manager plays coach, a delivery manager plays scrum master
4) Part time assignees (particularly managers): work a few hours a week on the project, see 1.1.
5) Long running “set up” phases
5.1) You spend longer pondering the future than the time it takes to create the future
5.2) A lot of time is spent agonising about infrastructure changes rather than just doing them
5.3) Team advocates for, and does, investment in infrastructure and “reusable code” before anything is usable is actually delivered
Reporting not delivering
6) Supplier does not deliver working software
7) Supplier does not deliver working software every two weeks
In 2021 delivering working software to production every two weeks, or at least usable, potentially releasable software, is table stakes. The best teams deliver multiple times a day. If the supplier can’t deliver something by the end of week 4 you have a second rate supplier. Get out now.
8) Reporting hours done rather than demonstrating working software and stories
9) “Watermelon report” Green on the outside when everything inside is Red; impressive looking reports which don’t distract from the fact that nothing, or very little, was actually complete
9.1) Claiming stuff is done when it hasn’t finished testing
9.2) A Definition of Done which leaves work not-done – Mike has a good post at agendashift.com/done.
Other warning signs
10) You invest as much time in their org design as your own, if this starts to include people performance monitoring and management what are you gaining over using your own people?
11) Suppliers always say yes: no push back and no negotiation, feedback and scrutiny of your requests are signs they are paying attention to your needs. It you ask for the impossible it is better the supplier tells you so than accepts what you ask for. Ideally you want a supplier who can highlight the difficulties with your suggestion and work with you to achieve something akin to what you want even if you have to rethink your request.
12) Your own people are disenfranchised/disgruntled/frustrated by the arrangement. Particularly noticeable where people are expected to work in a different time zone to suit the other partly and when outsourcer staff are elevated (faster, smarter, etc) over the existing people.
In most of these cases the supplier is working around their own constraints rather than putting your needs first.