Even if you do not use OKRs and KPIs I’d appreciate a few minutes of your time, please read on.
And if you do use either OKRs or KPIs then please, take a couple of minutes to help me.
As some of you know I’ve given a lot of thought to the interaction of KPIs and OKRs lately – you can download my paper here (free).
Now I’m running a little survey to better understand the role KPIs play in organization. (This is kind of the wrong way around, I should have gathered the data first but I’m iterating, I hope to use what I find out with the survey in future work.)
The survey is here and should only take a couple of minutes.
If you would like to see my results then please share your e-mail address at the end.
And, as they say on the radio: if you would like to discuss any of the issues raised in the survey, or my paper last month, then please get in contact, even book yourself some time with me.
Many thanks – O, and please share this survey with anyone you think could help.
I was at the dentist recently. Don’t worry, my dentist is nice and my teeth are fine. I was in the chair for about five minutes. But the admin!
Until recently I had to fill in two or three forms: to confirm my health (good, no change), sign as an NHS patient (again), and possibly a marketing form for the dental practice (yawn). A couple of years ago they started sending me the forms by SMS in advance. But I never did them, far too fiddly on a phone screen.
Now the practice sends the forms in e-mail before hand. But their system didn’t recognise me I tried to complete them and I gave up. At the practice they have me an iPad with the form. That didn’t work well either and the receptionistists had to get involved.
Digital
The thing is: the dental practice has gone – or is at least trying – to go digital. Get rid of the paper, streamline the processes. But they’ve done it really badly. The technology they have put in doesn’t work, doesn’t enhance my experience as a customer patient, doesn’t save reception time and can actually make more work for the dentist!
Nor is there any point in complaining, sorry, make suggestions for improvement: there is nobody to listen.
In the “digital” world of today throwing technology at a problem fundamentally fails to appreciate how today’s digital is different to yesterdays IT. Being digital is more than having an system on a computer for people to use.
My dentist is not unique, either as dentist or as an example of how digital technology makes things worse – my gym/pool is just as bad. They have the most annoying app. Too often companies buy, or are sold, digital technology as a “point solution.”
Paper forms? – buy an app to send e-mail, box ticked, job done. (Although, if the system doesn’t integrate with the management system, confuses customers and makes work for staff there is no benefit.)
Booking need to be taken? – give people an app, box ticked. (Although, if it is slow, temperamental and posts too many notifications it won’t enhance the customer experience.)
Security needs to be improved? – ask for the password a second time, send them a SMS, give them a custom app. (Even if that means the average day starts with six password entries, four text messages and another four authentications in the app.)
Yes, all these problems existed in yesterday’s IT centric world and that is part of the reason things needed to change. In the Digital world the technology is not just a bag on the side, its part of the whole offering.
On the one hand this is everyones job to get right. But, there is one specific role which should be looking at this, connecting technology and business, thinking about the whole offering and putting customers first: the Product Manager role.
Let me suggest the common theme here is: Product Management is Missing in Action.
Failuring to think Product
Its not just that such companies haven’t hired a Product Manager or given them responsibility for the whole, it is that so many companies don’t even know they should have a Product Manager. They probably don’t even understand what the role is or why they exist. Someone needs to think about the whole product – the dental service, the gym experience.
Sure some of what I am describing is work for Business Analysis, some is work for Designers, some is simple technology, and there is work for User Experience Researchers. But where does all of that come together? Who owns it? Who connects it with the company agenda?
It is not just the Product Manager role which is missing, it is Product thinking that is missing. There is a failure to appreciation that technology is the business now. There is a product here, part technology, part physical or experiential and someone needs to consider the whole. If that doesn’t happen end result is not going to be good.
Take my morning swim: the pool operators repeatedly fail to refresh the app when opening times change. It is so bad I’ve given up using it, I take my chances. So what benefit are they getting?
This is more than just saying such companies need Product Managers. Those Product Manager needs to lead others to see that digital technology changes the customer experience and changes the product/service itself. Hence why I talk about Product thinking.
If a business is going to embrace digital it needs to do more than just use digital technology. It needs to think of the whole product and the whole customer experience. This applies too AI as well, AI is still digital technology and if AI is deployed without due thought to the whole product and digital experience, both customer and provider are going to miss out on benefits. It might even make things worse.
Once again I find myself coming back to Reid Hoffman’s quote about early products:
“If you’re not embarrassed by the product when you launch, you’ve launched too late.” Reid Hoffman, founder LinkedIn
Reid is articulating an idea that comes up again and again, whether called a prototype, technology demonstrator, proof of concept (PoC), steel thread or walking skeleton, or, the dreaded, minimally viable product (MVP) he is calling out the value gained by early feedback.
What is different here is Reid is directly challenging us to go below our own expectations and our own beliefs of what is truly needed. At the same time he is laying a trap: the need for more work is built in.
While PoC, walking skeleton, MVP (especially) and the others terms all have their own logic for going small, they are too often in used by those in power to get what they want while downplaying other people’s wants. Oddly, the person demanding the MVP is usually happy to pass over what others want while insisting the things they want is minimal.
What all these formulation are trying to do is learn and, perhaps, start the feedback loop.
A technology demonstrator or proof of concept aim to learn what the technology can do.
A walking skeleton, aka steel thread, aims to learn how all the pieces fit together.
An MVP, should, help us learn about what the market wants from the product.
Like doing a limbo dance, all these ideas are asking “How low can you go?”
Reid is saying the same thing, and at the same time saying “Don’t kid yourself or anyone else that it is done.” A useful addition.
Similarly, when I did Product Management training with Pragmatic they had a catch phase: “You opinion, while interesting, is irrelevant.” I even have that quote on mug from a grateful product manager!
Yet in the last few weeks I’ve been feeling guilty for my part in pushing this idea. I’ve used all these formulations over the years to say to people: “Lets do something small, see what happens and learn.” But this idea is being used wrong.
When challenged that this is irresponsible I’ve been happy to point out that this approach has limits: I won’t offer a cure for cancer to test market uptake. (This was particularly relevant with a client who was actively trying to cure cancer.)
I’ve been horrified by the actions of xAI as they released a product with no safeguards at all. This was going lower than I ever imagined possible.
Their product that removed the freedom of people, particularly women, to appear as they want to appear. I, and every other person on the planet, has the right and freedom to appear fully clothed, and the freedom to restrict images of ourselves.
The same is true in other fields recently. Copyright now only seems to apply to those with the money to enforce it – as was said about the English legal system: “justice is open to all – like the Ritz Hotel”. Or consider democracy: moving fast seems to have broken it and fixing it is hard.
While I have been challenging tech builders to build less and learn more for years I have always assumed there was a level of shared values, common understanding and simple decency that formed a lower limit. Something so common that it didn’t need spelling out.
Without shared values it is very likely that one side will feel cheated by the other. I’ve seen many engineers roll their eyes and shrug their shoulders when told to build a “minimally viable product.” Without shared values these engineers feel they are being asked to cut quality while stuffing the product with features. Akin to building a car with many cup-holders but no breaks.
I’d like to say the answer is shared values. On long lasting teams that can work, but often technology teams have only just met and share very little to start with.
The answer, as is often the case, is to step back and be clear about what you are trying to achieve, ask “why?” Be clear about what is minimal in the market and clear about what technology you are demonstrating. By all means challenge yourself and others but remember there are limited, don’t claim to cure cancer.
Many years ago I got to meet one of my heroes and better still share dinner with him: Charles “Chunk” Moore, inventor of the Forth Language. The reason Forth is called Forth if because Chuck saw it as a fourth generation language: one that could be used by regular people to instruct their machines. To anyone not blessed with a mathematical aptitude that might seem like a joke – in Forth if you want to add 2 and 2 you write “2 2 + .”.
But the “users” Charles had in mind were not average office workers. His typical user probably had PhD in maths, more likely astrophysics. If Forth was an everyday language it was the everyday language of rocket scientists.
Over dinner someone asked Chuck “What surprised him most about the way computers had developed?” (this was 30 years after he created Forth.) I remember his answer like it was yesterday “I alway expected people would write more of their own software for their machines.”
Today corporate IT department hate end-user written code, they go to great lengths to stop it ever existing. Once it does it poses security risks, it may create costs, it may be difficult to move to new machines or break when software updates, it diverts users from doing their real job. That said, end-user create systems can be among the most innovative systems in the company precisely because they were created to serve a real need.
What has this to do with AI?
Well, there is a lot of talk about AI making programming available to regular workers. If claims being made for AI are true then in a few years Chuck might not be so surprised. AI coding is offering a world were everyone can all tell their computer what we want and it will write the code.
In many ways I love this: programming will be democratised, anyone can do it, everyone can have the joy of coding. However, right now I’m doubtful this world will happen but lets accept it as so. In a world were average workers can create their own computer programs and systems there are going to be a lot of problems.
Imaging this world for the moment: there will be an explosion of “home made computer programs”. Jevons Paradox write large: why buy software when a tool can create it for you?
Shadow IT explosion
Corporations are facing an explosion of Shadow IT systems as users who can’t program use AI to create new systems.
One reason corporate IT hate such systems is because of they create security headache. Who knows what ports will be opened and vulnerabilities will be created. And when a popular library needs a security path who knows which shadow systems need an update? And what if the update breaks the system?
Of course AI might help with all the security problems but what about testing? (Especially when a naive user might accidentally create an ethical issue.)
Even programmers dislike testing. Every programmer is convinced they are the chosen one and don’t need to test. What about people who have never coded in their lives? And after all, how can a computer get it wrong?
Some errors might be acceptable, some might be fatal. What about regulated companies? What if a user automates their own work but fails to consider regulations?
If we are to see a boom in end-user systems we also need to see a boom in testing. As testers have always told us “you can’t trust the programmer” so who is going to do it? who is going to pay for it?
And what about usability and disability regulations? Particularly those included in employment law.
Anyone who has ever created a product knows how hard it is to create a product which many users love, let alone how to persuade other people to use it. Now, since everyone can magic up a similar systems for themselves why would they? Why should I learn to use your ugly system when I can create my own?
Which means, there is going to be proliferation of systems which do much the same thing. Yet each one will be different, different individuals different workflows, which means a lack of consistency – what does that do for the outcome and customer experience?
And anyway, if Jill and Josh both build a their own workflow systems, that is two systems that need cybersecurity, testing, maintaining and yet are slightly different and only usable by one person – Jill or Josh. Having two overlapping systems which cost is just the kind of thing corporate IT want to eliminate for good reason.
AI coding still takes time
Don’t forget either that every time some takes time to pause their regular work for long enough to engage with an AI code writer and create a new system to automate their work it takes time. Maybe 5 minutes but it could be 5 days. While they will be more productive in the long(er) run the immediate effect is to slow things down. Now multiple that by the number of people who create their own solution. In the short run we can expect to see a productivity dip while everyone goes off and automates their work.
Some percentage of those system will never pay back the time invested but since this is end-user IT those system will never appear on a portfolio investment plan. It is fantastic that opportunities for improvement that were overlooked, or couldn’t make a business case, will now be realised there is also a downside. These systems will impose costs of maintenance, duplication and misplaced effort.
Don’t take this as my conversion to corporate IT departments – they can be unbelievable painful to work with. The fact that it can be so very hard to exploit these opportunities is a damning indictment of corporate IT processes and ways of working.
In the short run the explosion of end-user AI generated systems are going to increase their workload and costs. Throwing corporate IT and checks away might cure the immediate problem but will store up more problems for later. Don’t throw the baby out with the bathwater.
Maybe I’ve been avoiding AI – so please forgive this rush of posts.
That may well be because it seems to be everywhere and constant at the moment. The hype is overwhelming. I use the word hype deliberately, certainly AI – specific massive neural-net systems – do make possible incredible changes, and will effect the way we work for decades to come.
I do not buy the argument that this means that everything that came before is irrelevant, or that anyone (like me) who does not lace every single statement with AI is in someway a cynic and needs to be left behind. Rather, I see these as arguments that are used to sideline naysayers.
I’ve been keeping my AI thoughts to myself because I feel it would be detrimental to share. I know I’m not alone here; discussing AI with a friend before Christmas he felt the need to add “Please don’t share these comments.”
This came home to me when I read this: “OpenAI in particular should beware hubris. One vc says discussion of cash burn is taboo at the firm, even though leaked figures suggest it will incinerate more than $115bn by 2030.” (OpenAI’s cash burn …, The Economist, December 30.)
So here are some thoughts on where we are with AI
#1 Hype makes it difficult
Between the bubble and the hype it is very difficult to have a have an informed conversation about AI. Even without the hype it would be difficult because this is an emerging technology.
#2 Fear over hope
Rationally I know that technology advances benefit humans, create new jobs and improve living standards. However, one can’t help fearing what is to come because of the constant repetition of “AI will cut jobs” (and who is saying it, #6 below.)
#3 Applications
While an LLM writing a document is impressive few of us spend our days writing documents. This is the equivalent of early micros shipping with BASIC. This was cool if you could programme (or learn); it was useful, to some degree but only if you knew what you were doing. Ultimately it was the emergence of games and then basic word processing and calculation applications which made micros worth the investment.
That is why Apple II was a hit and MSX was not, VisiCalc beat Microsoft BASIC. It is the ARM powered Archimedes failed (no killer apps) but ARM powered phones are omnipresent.
To realise the potential of AI/LLM/neural-nets those applications need building. Some are emerging, for example in healthcare, in law enforcement and environmental.
#4 What problem are you solving?
Applying AI to a problem means we need to have an idea what the problem is (requirements), then we need to construct a product (development), somewhere along the line we need to understand the details (specifications), as I described last time, we need to test the result (testing), get it into hands of users (deployment) and refine the result (feedback and iteration).
Recognise that? Just because it is a shiny new technology doesn’t mean those things go away.
This is one of the reason’s AI initiatives are failing. “Just use AI” may impress investors but simply asking an LLM for a document is little more than a party trick. While we need experimentation people are trying to force AI into every conversation and neglecting the basics.
#5 Unappreciated costs
AI is creating jobs, at the moment many of those jobs are low paid, tedious and hidden away behind sub-contractors in Africa, e.g. tagging and moderation.
Then there is the great unmentionable: Power consumption.
In an age of climate change, where we know the damage our power systems are doing to the environment it is disgusting that these systems are given away free.
Please don’t say “they are powered by renewables.” The world hasn’t finished removing fossil fuels so every data centre powered by renewables is reduces the fossil fuel removed form the mix. Nor is it just power consumption: there are grid connections.
Where I live in London companies are building data centres. But London has a shortage of homes. The data centres v. homes debate is only just getting going. Sometimes it can feel like machines already have mastery: people are loosing jobs and homes to machines.
#6 The rise of the right (sorry)
The AI cheer leaders – Thiel, Musk, Andreessen, Altman, etc. – are aligned with the right of American politics. It sometimes seems the AI revolution and the destruction of post-1945 world order are the same thing. ForAI to succeed, must we jettison post-1945 morals?
The arrival of the internet was associated with the creation of opportunities. People like Vince Cerf and Tim Berners-Lees were positive role models who kept their politics quiet. The American oligarchs leading the AI boom envisage a Brave New World rather than The Culture.
(Anyone else see Huxley’s “T” icon in the Tesla badge?)
Looping back, ironically, the “absolute free speech” espoused those oligarchs is not extended to anyone expressing scepticism about the brave new world.
Ultimately, it would be easier to be positive about AI if, instead of emphasising about job cuts we talked about new opportunities. But that itself is a political decision that few talk about.
“artificial intelligence chatbot Grok being used to create non-consensual sexualised deepfake images of women and girls” BBC website
The Grok story would have the power to shock even if it hadn’t become almost routine – both for Elon Musk and AI. It serves to demonstrate that AI systems need testing – and the test results need acting on. Machines have always done unexpected things, thats why we test. As they do more and get more powerful they need more testing.
I learned long ago that just because something is syntactically correct, and may even compile, does not mean it delivers the desired result. And even if something does deliver a result who knows if it is the correct result?
AI systems, and AI generated code, still needs testing. I don’t know how to be any clearer.
The Grok case is pretty extreme. In many ways the system does what it was designed to do, but a good tester would have noticed, and reported, that it went beyond expectations and delivered ethically dubious results.
Our previous generation of technology could mess up just as badly: look at the Post Office Horizon system which put people in goal and lead to suicides. And humans covered up.
Hopefully, once we understand AI and what it does we can avoid these things. But just this morning I discovered the AI Incident Database.
Ethics
Some of these things – like autonomous cars hitting pedestrians – are just good old fashioned failures. They are worse because we are asking the machines to do more and there are many more variables which aren’t tested for. Other things, like Grok undressing people are simply things humans know are wrong, humans know it so obviously that we don’t expect it to be coded, we don’t expect to need to test for it. There is probably no law against computer undressing but it is ethically wrong.
Testing computer systems for ethics isn’t something testers have had to spend much time on before. Complicating matters is that ethics are more difficult to define and vary across people, countries and culture. I’m pretty sure that what is ethically acceptable to Elon Musk isn’t acceptable to me. But then, gun ownership in the USA is ethically acceptable but not here in the UKs. Who’s ethics are we testing for?
But even at a more basic level how can you be sure your AI generated code is producing what you expect?
Imagine you have you AI generate code for an invoicing system. Did you ask it to include VAT? And if you did does it apply it correctly? To the correct products? Does it work correctly across national boundaries? – VAT rates and exemptions differ across countries.
Even if you give you AI your national VAT rule book can you be sure it produced the right results?
You still need to test it.
Which means: there is testing work to be done. And since the system does more there is more to test.
Sure you can have an AI write tests but are you confident in those tests?
Paul fed a specification into an AI and generated some code. To test it he fed the spec into an AI and asked it to generate tests. Not all the tests passed, the AI generated code contained bugs, fortunately the AI generated tests found them and Paul fixed them.
Paul then applied mutation testing to the code: >= became <=, == became != and so on. He ran the tests again: only 30% of the tests which should have failed did fail. Think about that, 70% of the tests passed when they should have failed.
This leave us with 2 facts:
AI can generate code with bugs
AI generated tests are not sufficient
Paul also pointed out that the specifications contained gaps. This fits with the older work from Capers Jones where he discusses defects in specification. I can’t remember if it was Jones or Tom Gilb (another old friend) who claims that 30% of defects are defects in the specification.
Now good specification take time to write – even with AI assistance. If you are happy for the AI to make all your decisions then OK, but if you have ideas on how you want the system to be you need humans in the loop. Anyone who has written specification will tell you how stakeholders often don’t agree on what is wanted.
Do you test your spec?
Where do your tests come from?
AI may help but is not enough.
Again, AI may help with the writing but it will need humans in the loop.
In fact, even if AI helps writing the spec, helps write the code and helps with the tests things are going to get harder. There will be more systems created, more code created, more tests needed.
Jevons paradox is at work: when things get more efficient we use more of them. The question is not so much, can AI write all the code? but How are we going to tests everything?
Enter ethical testing
When spec, code and test took time and many people there were more opportunities to for someone to raise the question of ethics. Having reduced the time and people in all those earlier steps there is now a new step that needs to be included: ethical testing.
The process of programming was never just about cutting code nor was the writing of the code the limiting factor – typing is not the bottleneck. In the creation of a system – specification, coding, testing – lots of decisions were being made. Those decisions still need making. Ignoring them simply lets an AI decide, for better or worse.
Do you know all the decisions the AI silently made? Do all your stakeholders agree with those decisions? Are those decisions legal and ethical?
This is not the post I intended to open 2026. In recent weeks several threads have come together to challenge my thinking and I feel compelled to share with my readers. So, a slightly long and philosophical start to the new year!
A while back I read Amethodical systems development (Truex, Baskerville and Travis, 2000), it has stayed with me and has been a major influence on my reasoning about software. The authors argue that every development, contains unique aspects and is not replicable. However, by focusing on “a method” engineering has elevated the processes used to a privileged position and neglected what actually happens. To some degree the emergence of methods based on experience (e.g.XP) in the years after the paper addressed some of this concern but not all. It also means that Scrum, XP, PRINCE2, SSADM, SAFe – or any other brand names method – overlook many important factors. (Hence why I always describe Xanpan as a model of what you can create yourself.)
Rational irrationality
For a few years now I’ve been meaning to write a blog about Rational Irrationality. This is a phenomenon I’ve seen again and again inside corporate environments. In a nutshell this is interplay of rational processes which combine to produce irrational systems. Rational processes and systems are put in place with the best intentions but once you have a few, independently rational, processes in place the interaction of these becomes irrational.
Perhaps the simplest example I remember was a Senior BA who refused to let his analysts look at user requests until the Technical Architects had proposed a design. He reasoned that his BAs were stretched, many user request never went anywhere so until the Architects had given it their backing he wasn’t going to allocate any BA time. Meanwhile, the Lead Technical Architect, quite rationally, didn’t want his people designing systems which hadn’t been scoped, how could the design something if they didn’t know what it was? Both were acting rationally but the result was irrational.
The two times were irrational rationality seems to peak are around project inception and kick-off, then when moving to live production environments, however they everywhere. Perhaps the problem is not with irrational processes and corporations but with me – and maybe you. The problem could be less these systems but our engineering brains which expect there to be a rational, systematic, logical, way through this problem.
Just because my brain can see these systems interlocking, connecting, blocking and deadlocking doesn’t mean others do. Perhaps it is because I’m an engineer, or perhaps because I’m dyslexic and visualise, I can see these things like machines and gears in my brain, the same way I used to imagine code working.
The garbage can model goes a long way to explaining rational irrationality and how it comes about: despite what an organization says, and despite artefacts like org charts, the organization is anarchy. Attempts to control it as a rational thing don’t work.
Now I think back to my experience, organized anarchy is probably a better mental model than rational entity in many places. The interplay of all those rational processes creates irrationality and disconnects people. The more people try to join up work the harder it gets, too many connections, Declare independence and you are seen as disruptive and “not team players”, the corporate anti-bodies come out.
The garbage can holds a collection of problems. These may get resolved, delayed or subsumed into something else. These problems are complicated by fluid engagement from stakeholders (they only sometimes join meetings), unclear technology and problematic preferences.
There are solutions too, although not necessarily solutions to the problems in the garbage can. These solutions are products, perhaps backed by vendors but not necessarily so. These solutions are looking for problems they can be applied to. Once in a while decision opportunities arise – IME typically when money needs allocating or a deadline hits. Still, delaying a decision means problems remain.
What ideals are lying around?
The economist Milton Friedman once said: “Only a crisis—actual or perceived—produces real change. When that crisis occurs, the actions that are taken depend on the ideas that are lying around. That, I believe, is our basic function: to develop alternatives to existing policies, to keep them alive and available until the politically impossible becomes politically inevitable.”
Friedman is arguing for the creation of products (policy alternatives) which then wait until a decision point. Friedman is telling us how to work in the garbage can, whether economics, systems development, or geo-politics.
From a amethodoical view engineers are trying to create rational solutions and processes while others are biding their time until their product/solution can have its day.
Fake it
Of course, when we look back and try to explain it – or when someone says “Can you do the same for me?” – we rationalise it. We don’t admit it was a garbage can or lacked method, that some stakeholders never turned up or decisions were delayed until they became irrelevant. We explain it as if it was meant to be, or as Dave Parnas put it “A rational design process: How and why to fake it.”
After all, who would admit their process was amethodical and wasn’t the result of apply career enhancing frameworks? Or that their decision making was little more than a garbage can that only produced decisions when crisis hit?
Now, when someone believes their organisation is rational, maybe they think it follows SAFe, or maybe they the hierarchy works, they treat it like such. But their mental model does not reflect the reality. Consequently the system doesn’t respond as they expect, even if it isn’t anarchy it looks like it.
So what good is this?
I would like to think that I will stop looking for engineering solutions. That I will accept more of the rational irrationality in corporations. That I will practicing patience.
I think it is more likely that simply knowing my engineering brain is wrong to expect a well oiled machine I will be more tolerant. At the very least, I will tell myself to tolerate more. Still, I will endeavour to make my bit of the world a little better, and a little more rationale. Perhaps knowing the world is irrational will help me be rationale.
One question that comes up regularly is: “Why do managers accept on too much Work In Progress?” – or “Why is it so hard to reduce WIP?”
Once you understand how more work-in-progress means less work-done it is a plague that you struggle to overcome. And for some reason it is always other people who allow too much WIP. Over this last weekend I had some insights…
You see, last week I realised I was had too much WIP myself. As I wondered across Hampstead Heath on Sunday I found myself wondering “Why have I allowed myself to take on too much WIP?” I came up with some answers for myself which I think might apply more generally. They may even go a little way to answering that “Why do we have too much WIP” question.
Always optimistic
As individuals and organisations we are repeatedly optimistic. We confuse “what we want to do” with “what we can do” or “what we have capacity to do.” Indeed, one can argue that if we were not optimistic, if we did not try and do too much and do things beyond our ability we would never learn and grow. Perhaps taking on too much and then discarding some is the natural state of affairs. In which case, we need to acknowledge that we sometimes need to cull work.
Can’t decide
Ultimately its a question of not being able to prioritise and decide. But first one has to realise that there is a problem and a decision needs to be made. In my own case I “should” be able to just make that decision. In a work environment there may be multiple people who have influence over what is done and not-done. It may well be unclear who can decide to say No and do less.
Yes is easier than No
Saying Yes is easy: saying No is hard, to oneself and to other people. And once you have said Yes there is an element of commitment. Even saying to oneself “I’m not going to do this” can be hard, telling others is hard even before they object.
Postponing a decision makes it go away, for a while at least. But it still takes up cognitive space, part of our brain knows it will still need to be made. Unfortunately postponing a decision can also mean something fails: it delivers too late, or it deprives something else of resources and that fails.
In the IT/digital world people are accustomed to failure. Sometimes it feels like the expectation is for failure, at least one organisation I’ve worked with didn’t know how to manage success. Their processes and procedures were set up in the expectation that work would go wrong. When a project was proceeding well obstacles appeared.
It can be more acceptable to be seen to fail while trying two rather than succeed with one, and fail another by not trying. Consequently, knowing that saying Yes to two different pieces of work will increase WIP, slow delivery and increase the risk for both, but you still say Yes. Failure will probably happen but it is more acceptable than saying No in the first place.
Just too interesting
Personally, I’m just interested in too many things. Half of my WIP is because I like switching between things. I want to too much. And I need to switch between things, my brain gets bored in one venture so need to switch to something else. I know I should “do one, do it to completion and move on” but that requires discipline.
This applies directly to companies. They want it all, everything looks good, each piece of work has its own supports who will be upset if it doesn’t happen so lobby for it. Again it is more acceptable to fail at many things than focus, succeed at one while postponing the others.
While I’m waiting
If you understand WIP you probably understand queuing theory. While we know that we should work with queuing theory and reduce WIP there are somethings which still entail queues. For example, you need to speak to someone, perhaps for market research. It takes time to book them and it takes time before you speak with them. What do you do in the meantime? Surely you could do something value adding while you wait?
Its bad enough when I do this to myself, in organisations the opportunities are unlimited – especially when you need to interface to people and teams outside your immediate area.
Making many bets
Perhaps a variation on “can’t decide”. One of the reason I have several projects on the go is because I don’t know which one is the “right” one to pursue, I don’t know which one(s) will pay off. Therefore I invest a little in each one. I make many small bets.
If I could decide, if I could throw all my efforts into one it has a better chance of success. But I don’t know. Nor is it clear how to decide which one to back. Unless I work on it I won’t know.
I’m sure that this sometimes plays out explicitly in companies. I’m sure some will decide to make small bets on three or four projects and see what happens. However, I think more often than not this is done without such explicit logic. It happens by accident.
Now what?
So now I have a better understanding of how excessive WIP comes to be. The question I have now is: how to I change this?
Sorry. I’ve deliberately avoiding the click-bait “Agile is Dead” topic, until now.
For the last few years I’ve delivered a lecture on Agile to Oxford University students and this year the tutor specifically asked me to say something about the state of agile. When I looked over last years slides I see I was already talking about this. I’ll write more about this soon, if you can’t wait checkout “Xanpan 2021” from Frug’Agile en Arménie.
So, is Agile Dead?
Clearly not. (Albeit agile mania probably is.)
Agile is all around us. Teams work in sprints, hold daily “stand up” meetings, tools like Jira continue to sell, requirements documents are full of user stories, business journals regularly talk about “agile” and “agility” without any reference to software.
That doesn’t mean the result is perfect. The “agile” which prevails today falls short of what I and others in the community dreamed. As I’ve said before, Agile won the war but lost the peace.
Right now, agile isn’t getting attention because AI is. AI is soaking up all the discretionally time and budget so agile is squeezed out. Ironically, to get the most from AI you need the learning processes embedded in Agile to find better ways. Right now we don’t now the best way to use AI. We are in a vast experimental phase and we need more of the learning and feedback in agile.
Back to the question, is Agile Dead?
The common agile that prevails is a watered down, corporately acceptable version that is still a lot better that went before.
But then, most people don’t remember before agile. The Big Up Front practices which gave massive requirements and functional specifications; the defined process and ISO-9000 process audits, the guilt of “not doing it properly” and the inability of those doing the work to influence how it was done.
While many of those problems have resurfaced under other names in the agile world things are still a lot better. If we had stayed with that approach there would be no automatic updates to the apps on your phone, no digital business, nor much of the other technology that surrounds us. Maybe Apple and Google would be OK but legacy banks, airlines, telecos and Governments would be even worse than they are now and a million start-ups would never have started.
In truth, many of the “waterfall” processes were never followed. I worked on exactly one project that did it by the book, Railtrack Aplan. Officially it was a success, it went live. But what went live was a shadow of what was supposed to be delivered.
Everywhere else did something that (kind of) worked and then felt guilty for not doing “properly”. When I was at Reuters they tried to force us to work by the book, they destroyed much of their own capability in the process.
What has agile ever given us?
Agile showed there was another way and added democracy by opening the debate on “how we work”. The Internet help agile spread and opened up the debate in a way that had never been possible before.
If nothing else Agile gave us a better reference model, a better way of describing our work.
Actually, it gave us several reference models, Scrum, XP, DSDM, etc. Always, and everywhere, people adapt, when processes work they use them, when defined process don’t work they work around them. For a while agile licensed that working around, experiments were everywhere.
Agile was not so much new in itself as a new combination of ideas which were lying around.
Lean thinking draws on many of these ideas directly but lean also begat its own software process in Kanban.
As for the Frankenstein’s monster that is SAFe… you can decide for yourself whether SAFe is agile but it is definitely not lightweight. Because of its size alone it is hard to adapt SAFe and involve the workers.
The return of Agile?
Can we expect Agile to return to its previous permanence? Will the day come when everyone wants to hire a Scrum master? No.
That has passed. Organisations have ticked the Agile box – if only because they have moved on to AI. The days of big agile transformations are largely over because companies have declared success.
Put it another way: Management fads don’t return.
Imperfect agile is here, hopefully enough of it has been adopted that companies will continue to improve.
More importantly, those ideas underlying agile – quality, sociotechnical, cybernetics, learning – are still valid and will continue to have influence. Some companies will embrace them and get a lot from them, some will continue to reject and most will dip-in-and-out. These ideas will return, albeit in a different package and with a different name.
But none of that means agile is dead. Agile mania might be over but agile is continuing to evolve out of sight. Agile wasn’t the first coming of these ideas and it won’t be the last. Next post I’ll talk more about how I see it evolving.
