At EuroPLoP last week I learned of a popular Open Source gaming framework (I forget which one) had instigated a blanket ban on AI contributions. It appears that AI meant there were more submissions coming in and the maintainers were struggling to understand and review them.

I hadn’t had time to think through the implication of this before the Financial Times carried a big piece on the same issue across the Open Source world (paywalled: Who cleans up after the vibe coding party?). It actually turns out this problem could undermine many of the OS libraries we’ve come to depend on.

Next a friend was telling me about his dozen AI coded mini-products, one of them has eight or so prototype. None are finished, none in the market, all sound like good ideas and potential products.

All these examples are perfect illustrations of Jevons paradox in AI: when things get more efficient (cheaper or easier) then more is consumed. AI coding agents make coding cheaper so we do more of it.

But, as we have known for years: build it and they will come rarely, if ever, works.

Since LLM coding agents appeared the number of submissions to app stores has rocketed and the number of available apps increased faster than before. Yet, the number of app downloads has not gone up. Say’s Law does not hold, supply does not create demand, just because there are more apps written doesn’t create more downloads.

One can reason that the same pot of customer money is now being spread across more apps so the average contributor makes less money – maybe that’s OK because the apps are so cheap to produce. Or maybe with so many more apps to choose from people stick with the popular ones and there is an even greater gap between the few “winners” and the “also rans.”

These kind of problems have always existed but by lowering the cost of change AI has made them more common. Previously, the slower pace of creation mean that more questions were asked and there was more time to catch such issues. Now things happen so fast there is no time to ask and new problems are appearing.

Understanding what customers will pay for is more important than ever. Can AI help there? Perhaps with market research but someone still needs to make a decision.

So much of our world is concerned with managing, controlling and rationing limited resources – indeed the “allocation of scarce resources” is sometimes considered the underlying problem in economics. But increasingly we see problems of too much and we lack solutions for too much.

That is not to say we don’t have solutions. In the 1970s and 80s we had over production of some foods, there were wine and milk “lakes”, and butter and gain “mountains.” The EU had to start paying farmers not to produce.

Software product companies traditionally have an spend split of 33%/33%/33% (approximately): one third on technology engineering, one third on sales and marketing and one third on everything else, like finance, HR, property, etc. Many of those cost remain even if the cost of coding goes down. If there are more competitors then maybe more needs spending on marketing.

More companies that aren’t software companies will find they have software which needs to be supported in some fashion. More software demands more cyber security and until machines replace all the humans those that remain will need more training, and even AI written systems will require maintenance and updates. Then there is the cost of complexity from all those systems which nobody quite understand.

As to Open Source projects, I don’t know. Maybe it will be a shift back to proprietary products, or maybe the submitters need to be charged.

Jevons paradox is working exactly as expected. Resolving the problem in one place is creating problems elsewhere. Problems are truly generative.

There is one lesson I re-learn there every year, and this year it seems particularly relevant – because of AI, because people are lazy, because of my current client, because I see the same mistake being made again and again.

Almost everyone at EuroPLoP brings a paper, I certainly did. And we read each others paper – by the time I get there I have typically read over 100 pages in detail.

The conference exists to review these papers. As a writer I sit and listen for over an hour listening – only listening, no talking, no saying “you don’t understand” – as other people discuss my paper. It can be joyous, it is also hard and can be hurtful. The lesson I learn again and again is simply: the person who decides the message the writer is sending is not the writer, it is the reader. The same applies for speakers and listeners: it is the receiver not the transmitter who decides the message.

As a writer you may think you are clear, unambiguous and to the point. You may think there is no room for misinterpretation or ambiguity but you are wrong.

Every reader brings their own context, their own concerns, problems and priorities. Readers read into your paper what they want.

This lesson goes beyond my writing, it goes into my speaking and my presenting, from there into my leading, my enthusing, my nudging.

Ultimately, it is very hard for me – or anyone else – to tell anyone else what to do because it is the receiver who decides what they have been asked to do. (More next time.)

I’d love to see you at EuroPLoP and see you learn this lesson but few can afford the time – and energy – so take this short cut: always assume people will interpret your words differently. Strive to keep you messages simple. Explain yourself, ask other what they have heard and always, always, give other people the chance to say something so you can receive feedback. Without feedback you can’t correct and you can’t improve.

When the audience is important to you, when you actually care about them don’t just say “Any comments?” or “Does anyone have questions?” Instead, pause. Ask the person on your right what they think, then the person to their right, and go all around the circle. Don’t reply, let everyone have their voice and respect that voice.

You might not have time to do this too often but make some time to do it. When I do multi-day training sessions I usually do it each morning, or important meetings after a break or before we move to conclusion. Many people shy away from speaking so give everyone a moment to be special. Save your replies to the end.

Woody Zuill has a great catch phrase: “It is in doing the work that we understand the work.”

If you are like me your first response is to think about the problem domain: “The problem the customer wants solving is understood when we try to solve it.”. This certainly fits many of my client projects. When I was building electricity forecasting system it was by building the system that I came to understand how the electricity markets worked, how electricity was priced and how we could use contracts for difference to optimise spend.

Or when I was building telecoms software I came to understand how mobile phone network work and how protocols are wrapped in protocols, all the way down.

Complexity in the enterprise

Increasingly I see Woody’s maximum applying to the processes, authorisations, gateways, approvals that make up the way an organization works, or rather the way it think it works.

This was brought home to me recently when I went to visit a client’s offices – yes a physical visit! I was there with a dozen or so other consultants. This client took security seriously so as well as being on the guest list in advance we needed photo id and to pass airport style security.

Time consuming but it worked, in the morning that is. The problem came at lunch time. It was good whether so everyone left their bags, coats and gubbins behind – lunch would only be 30 minutes. As we were about to leave someone said “Do we need ID to get back in?”

Arh.

One of the hosts said “If you have it on your phone you are OK”

Someone check with the security guard: “If you came in this morning you are OK, you are on the system.”

Another said “Make sure you use the other entrance ‘cos you are registered.”

Needless to say, on our return, the other entrance wouldn’t accept us.

ID was demanded.

Digital ID was not acceptable.

Everyone needed to register all over again.

For a few crazy minutes it seemed I couldn’t enter the building to retrieve my ID to prove who I was to enter the building!

As it turned out: nobody really knew how the system worked. Not even the security people who were supposed to know. Everyone had an understanding but nobody really understood it until we lived it.

It was Woody’s maxim: despite our efforts to understand the building access rules it wasn’t until we had to live them did we understand them.

The larger the organization the more rules, standard processes, formal procedures, authorisation and systems there are. To make it worse, almost every company is in a state of continual changes: new processes and rules are being introduced and others retired. Some people think one set apply while others see others say other rules do.

Last year I found myself observing a project spend authorisation committee. As the committee ran over its regular questions the project was asked about stage gates:

Committee: “I don’t see any stage gate clearances”

Product Manager: “We have not completed any stage gates because this project is governed under the new life cycle model.”

Committee: “We’ve never had one of them before”

Committee other: “I’m not sure we are allowed …”

It was only by living the processes that the process could be understood. (My recent queuing post touch on the same idea.)

You don’t need many different processes, and updates to processes, in play before it becomes impossible to understand the interplay of these systems.

At the start of my career it was the technology – the solution domain – which was the difficult bit. Understanding it, making it perform, the limits of what it could do. Today technology power is almost unlimited and you can, supposedly, just ask it for what you want in plain English.

Next in my career it was the ask – the problem space – which was the difficult bit: understanding what the customer wants, defining the problem to be solves, sizing the opportunity and achieving market fit.

That is still the problem in smaller enterprises – start-ups and innovative companies.

Now, I find myself working with bigger organizations and this problem is rampant. Such places have processes, ways-of-working, procedures, rules, the systems of doing work – plus tools like Jira and DevOps which impose more – and nobody knows how they all hang together. The only way to know is to live the process.

Such places are caught by their own demands for processes and procedure. Many of these reflect a unwillingness to trust staff, or a decision to decompose work between different roles: project managers, analysis, coders, testers, devop, security, architects, …

Complexity

Consequently complexity and costs increase. Faced with these problems it is almost pointless to estimate effort or budget, the system is the governing factor.

Nor is it any use looking for a boss to solve the problem. Managers too are prisoners of the system, worse, they are expected to uphold the system and encourage people to follow it.

Complexity breads complexity. For my money less is more, they need simpler approaches that can be understood and reasoned about.

I’ve been really bad at sharing things recently so have a glut of things to share. Take your pick.

Agile Ideas for our AI future: my presentation to Agile Northants in April, the video is now online and the presentation can be downloaded from my website.

As usual I’ll be at EuroPLoP in Bavaria this year, so if you want a very different type of conference please join us.

No presentations. No keynotes. In fact, no speakers.

Lots of discussion. Really learn about feedback, learn about writing and cutting edge ideas.

Plus enjoy games, sauna and outdoor swimming. Honestly, its a serious conference!

Perhaps more importantly, my paper from EuroPLoP 2025 Learning to Learn: Patterns for Building the Learning Organization is now available either from my website, or, if you like a more formal version from Springer Nature.

Still on conferences, I’m delighted to announce I’ll be at the Oredev Developers Conference in Malmo again this November.

It is four years since I delivered the keynote there and this year I’m giving two talks in the main programme: Ideals shaping our AI future and The Good, the Bad and the Ugly of the The engineering mindset.

Finally, as some of you already know, I quietly released my first online self-paced course with LeanPub recently: Long term Product Goals for creating superior products. Subscribers who use this link, or simply use the code SubscriberJ26, can get 30% off.

For the last four years I’ve been saying: “There will be some interesting papers written in future about Ukrainian strategy and command.” While I had hoped for peace and serious studies by now neither has occurred so let me start.

The change paradox

First, remember that the protagonists started in the same place in 1991. While they both changed a lot over the following 20 years they retained much in common. As I understand, it was less than 10 years ago that Ukraine set about modernising their army and moving away from Soviet style command-and-control.

Yet in that time Ukraine moved from a very hierarchal structure to mission command (next up). Importantly, they have done this under intense pressure: they were at war.

I have seen this change paradox many times. Everybody knows “the time to fix the roof is when the sun is shining”. The problem is, when you have time and resources to change and fix things the motivation is low. When times are tough the resources are limited but the motivation is high.

My heart sinks when companies tell me: “We want to make this change but right now we have an urgent project to finish.” They should be thinking “This urgent project is the reason to change how we work.”

Mission command: Leadership for agility in battle

“Frequent and rapid decisions can be shaped only on the spot according to estimates of local conditions.” Moltke quoted by Tetlock

One side: big, powerful, well equipped with a strict command and control approach.

The other: small, under equipped, few plans, responding to what happens.

Everyone expected the bigger to win in days but the smaller one repulsed the attack. A small team out performs a larger team.

The difference was mission command: a philosophy that gives commanders a mission, an objective, an outcome and lets them decide how to achieve it. This has been American doctrine since the 1980s and asks the local leaders to : “think. If necessary, discuss your orders. Even criticize them. And if you absolutely must … disobey them. … Clarification of the enemy situation is an obvious necessity, but waiting for information in a tense situation is seldom the sign of strong leadership—more often of weakness.”

American doctrine became NATO doctrine became Ukrainian doctrine. Perhaps troublingly, America didn’t invent the idea, they took it from the Wehrmacht. Auftragstaktik as it was known lead to victories in the early years of WWII but was later undermined by leadership who involved themselves too much.

(The quotes are from the best introduction I’ve read to mission command, Philip Tetlock’s book Superforecasting.)

Product Development: Drones

Like computers, airplanes and radar before them the pace of drone innovation and manufacturing on both sides is a sharp reminder of how war can drive rapid innovation. Ukraine in particular stands out as a world leader, perhaps the world leader, both in drone innovation and battlefield tactics with drones.

Ukraine stands in sharp contrast with western efforts which, while not insignificant, are very much in a peace time mode. An increasing number of start-ups are bringing modern digital product development skills to bear but since the major customers are still in peace mode even these are frustrated.

A few years ago I met a team building a weapons system. The first systems test was two or three years off. When I asked why they couldn’t do it sooner they looked at me as if I was mad “too expensive, we can’t just blow up an expensive prototype.” So every decision was considered, reviewed, re-examined, and took time.

They would say they were saving tax payer money but I saw a waste of money because they were trying to learn (slowly) on paper. (I asked about digital tools: another, disconnected, group.)

As I keep saying: engineers engineer within constraints. For the legacy armaments suppliers the main constraint is Government funding, not just the amount of funding but the strings that come with it. Before any money is spent all sides need to show that the money is being spent wisely, fairly, and that no unnecessary money is spent. This results in procurement and approval systems which are themselves long winded and expensive to operate – queuing again.

War changes the constraints, now time to market – time to kill – is more important than saving money. Test and learn opportunities are plentiful. Fear of a failed test, or wasted money is less than the fear of defeat. Money hasn’t gong away, but it is not saving money in development, it is reducing cost of manufacturing.

As always: there is more than one way to solve a problem and the constraints determine how you go about solving the problem.

Put it all together

Ultimately all these three examples are about learning and acting on that learning. Most learning occurs early on. Planning is learning but so is doing. Plan a little, do a little, learn a little, keep iterating.

Motivated people, devolved authority, clear constraints and a need for action. Isn’t that what every team would like?

Perhaps it is also a check list:

• Are your team motivated?
• Is authority close by?
• Are the constraints clear?
• And is there a need to act?

There is going to be more to learn from this war but lets start with that checklist.

By the way…

One of my pet hates is “what we can learn from the military” talks when the speakers have no military experience. I’m breaking my own rule here. In my defence, I do have a little first hand knowledge of both countries and peoples, I’ve a little contact with British military industrial complex and I read some credible sources (e.g. The Economist.)

“Our bosses should be here”

“You should tell this to our boss”

Over the years I have heard this again and again, typically when I’m delivering training. I teach my stuff, I’ve people exercises to practice new techniques and ways of working, I inspire them as a group to do something different. Time and again I’m told “Our bosses should hear this too.”

Sometimes I’d say “But your bosses want these changes, the fact that they have given you time to be here, and pay me to train you shows they want the change.” While I think I had a pretty good success rate in generating change I’m also sure all too often nothing changed when I left.

The catch is, they are right, but so am I.

Each and every one of us has a mental model which says “we need our bosses authority to do this”, or “our boss can make this change.” And sometimes bosses do need to put their money where their mouth is, to spend on new tools, resources, and training, or to allow time for people to practice their new skills.

But, bosses are themselves prisoners of the same system, if anything more so.

For a start those leaders got where they are today because of their past success, that success was based on certain ways of working, certain beliefs about the way to get things done. At the same time they didn’t upset the wrong people, they didn’t make life difficult for those they worked for. Doing something different means can mean breaking with that, potentially upsetting people, possibly changing ones own behaviour.

Those leaders have to follow the same processes and practices as everyone else. If leaders break the rules why would anyone else ever follow them? They are expected to lead by example.

Those leaders have more to loose than workers: they may well hold senior positions with higher salaries. If they are seen to act irresponsibly they may loose their job.

They may be looking to become an even more senior leader – either in the same company or by going elsewhere. They won’t get those promotions if they are seen as trouble makers, don’t work well with others, ask too many questions or if they break too many rules.

Imprisoned by expectations

They are surrounded by expectations from their own bosses and those they must report too. In fact everyone has a boss: as a self-employed person have no boss on paper but I have to answer to clients. CxOs have to answer to CEOs who have to answer to a board. The chair of the board has to report to shareholders, all directors and many executives are legally responsible; plus they can get called in by politicians.

Politicians might seem more powerful but they have to answer to voters. (Not to mention allies and enemies.) Many of those voters are also shareholders – perhaps through pension funds.

Shareholders, pension funds, directors, executives, leaders, workers, everyone has to answer to someone.

Everyone is prisoner to the system. The more system – the more processes, procedures, tools, standards – you have the greater the change, the greater the difficulty in change and the greater the risk,

Doing something different entails risk, but at the same time there is risk in not changing.

Those people saying “You should tell this to our boss” are right, but at the same time the bosses are often looking to them to take the lead and make the change.

Kindling change

My mental model for leaders looking to create change is to “take both ends at once” – top-down and bottom-up. This is like starting a fire.

The leader who wants change needs to kindle the change. They need to get the fire started by encouraging people and providing resources to start the fire. But it is very very easy to extinguish the change with too much support. A fire without oxygen will not start, but too much oxygen will blow the fire out before it takes hold.

Your bosses might be far from perfect but remember: they are a prisoner to the system as much, or even more, than you are.

Please join me online next week when I deliver a brands new presentation for the first time: Agile Thinking for our AI Future.

Thanks to Agile Northants for organizing this Register now to join the call. Tuesday April 28, 2026 at 6.15pm.

Sergio Seelocahan invited me to join the celebrations for Agile Nottingham’s 11th birthday last month. It was a brilliant. I loved it. Great people. A great set of lighting talks. So what if I spent six hours getting there and back? I got to share the return journey work Noel Warnell which gave me an extra 2 hours of learning.

Nottingham reminded me of the old days, the happy days. How things should be. And it seeded an idea: did the decline of agile transformations bring about the fall in meet-ups and knowledge sharing, or did the decline of sharing precipitate the decline of agile initiatives?

Despite one post I’ve mostly kept quite about The Death of Agile. Mostly because agile is everywhere, it is not dead. What is dead is the market for agile and agile transformations.

Murder?

Till now my own theory has been that the rush for AI has absorbed all the discretionary time and money people and companies.

In Nottingham, Noel suggested agilistas didn’t do enough to show the benefits of agile is hard numbers. Heck, despite the story point fetish most teams have trouble telling you how many points they average each sprint. Despite my best efforts few teams know their burn rate, or expected ROI. While the world loves big data there is gold to be found in small data.

Jay Hrcsko suggested it was the rush for money. 2001-2011 was spent craving the endorsement of managers and big name consultancies. Agile became manager friendly in the 2010s, the consultants rushed in, cashed in, and gave agile a bad name. Basically this is the “SAFe killed agile” theory.

All these ideas, and others, probably played a role. Now I want to suggest that the agile community gave up.

Agile is learning

Remember the opening words of the Agile Manifesto: We are uncovering better ways.

It wasn’t just that we discovered better ways in the years leading up to 2001. We continued discovering them in 2002, 2003… we have continued to discover them every year, every month, since. But maybe we stopped sharing.

To paraphrase myself:

Agile is learning.

The opposite of agile is not waterfall, the opposite of agile is static. Not changing.

The only way you can do wrong in agile is do things the same as 3 months ago.

You should always be experimenting, changing and trying new things.

We stopped moving

Or out is another way: Agile is like a Shark, it needs to keep moving or it dies.

We stopped moving, agile stopped changing, stopped advancing. Yet, this is exactly the time when we should be learning and changing the most: AI LLMs have huge potential and we are only just scratching the surface.

We aren’t.

SAFe played a role. This Frankenstein Agile method – froze experimentation. It gave consultants a product to sell and executives a solution to buy. Like Scrum and PRINCE2 before it: nobody does SAFe perfectly, we we feel guilty about not doing so and keep trying to. That kills experimentation.

But maybe more of the blame goes to ourselves, the agile community. If true that also means we might be able to fix it ourselves.

You aren’t going to like this

This will challenge many readers. It will mean some will stop reading. So let me say, right now I want to talk about a side effect, not the thing itself.

Post COVID working from home has become very comfortable. for individuals.

It means that come 6pm we don’t leave the office and to the car/train/bus. We walk to a different room and rejoin our family. Going to a meetup is much harder: who wants to leave home office at 5.30pm, journey to a meetup in town and not get back to nearly 10pm. (You have to have a pint afterwards!)

Far easier to stay home, on the sofa, watch Netflix with your nearest and dearest.

But it means our learning is reduced. We hear fewer talks, we talk to few random people, we are exposed to fewer war stories and hear less about the promised land of agile perfection. We stop learning, we stop dreaming and yearning for better.

If we, the agile community, want to see agile rise we need to make it happen. We do that by learning.

Let’s get learning again

Let me finish on a positive note – how we might restart the flywheel.

Since Agile Nottingham things seem to be picking up – for me and the community!

XTC in London is still going, I was back at The London Pride a few weeks ago and they have a hosted event coming up.

Agile Oxford is reviving thanks to David Michel and Mike Harris.

Agile Northants is reviving, albeit online – I am speaking next month.

Steve Forbes if rebooting both Agile Standup in London and Agile Champions

More technically focused groups are still alive, local ACCUs seem to be thriving.

While I’ve stepped back from Agile on the Beach it is still going, as is Agile Cambridge.

Plus, I hope to be in Sweden this autumn for a big conference (watch this space).

Be the change you wish to see

My advice: if you want to see an agile revival get back to learning with other people.

Get out and about. Press the flesh. Yes, it requires making and effort, the law of two feet as it was once known.

Maybe ask your employer if you can host an event. I know more groups who would meet but they need venues. If your employer wants people back in the office they should make the office more attractive.

By the way, that also means you could try asking speakers in for private talks. Ask me! – I regularly do this sort of thing.

Even if you don’t get out physically just start joining more online meetings. Yes I know they are tiring at 6pm after a day of calls.

If the change you want to see is an agile revival then you need to be that change.