There are those who think “projects can save money by going slow.” I’ve never quite understood this because the same things still need doing but even serious people say it (HS2 anyone?). Actually, they are trading reduced expenditure now for longer expenditure in the future. Maybe that means that less money needs to be borrowed now so interest payments are less over all, perhaps.

This kind of thinking also leads companies to split resources between multiple work streams: rather than having a team of 4 people work on 1 thing and get it done quickly the same 4 people work on 4 different things and all 4 get done slowly.

I’ve long argued that “shorter fatter” is better because that means the return on investment starts flowing sooner. It also means there is no “bulge” at the end when 4 projects complete and everyone is racing for the same scarce resources to complete.

This longer-slower thinking is common in the project mindset but is is absolute rubbish.

I see two reasons why people may choose to believe this.

One, people don’t like making decisions, and especially don’t like saying No. So rather than cancel a project it can be reduced in size so nobody is upset.

Two, people care far more about cost than benefits. Add to that, most people don’t understand cost of delay.

So what should teams do?

Recognise that when you start work on something you open a risk window. If you aren’t doing anything then there is no risk of doing – there may be risk of not doing but that is another story. Once you open the window you are at risk, at the very least you are at risk of needing to write-off expenditure in future.

The more you spend the more the more there is at risk. And the big risk is often that there is nothing to show for the expenditure.

What most people miss is: the longer the window is open the more chance you have of a risk happening. If your project last three months the chances of loosing a key member of staff in that time is low, if it lasts one year the risk is higher and if it lasts five years it will certainly happen.

Similarly, the chances of adverse weather hitting your construction site, a competitor launching a rival product, new technology rendering your work obsolete, a pandemic hitting or one of a million other things are all increased when your project take longer.

Once you start work you are in a race against risk.

Perhaps my industry knew this once upon a time and that is why IT projects used to have long drawn out requirements phases: low cost, low risk. Only when the coding starts and the costs go up does the risk get serious.

But we now recognise that the more requirements you gather the greater the risk that they change. The requirements risk window opens the day you start writing them. Only when you show customers working product do you know if you got them write.

Then, once work starts and big money is being spent go at it hell-for-leather. Concentrate your resources, aim to close the risk window but also deliver: early delivery further reduces risk but also increases the return-on-investment because there is no return, its not all spending.

My first blog of 2025, and following my annual procedure I have created a new archive for this year’s posts. Then I reviewed all posts that didn’t get published last year. Among all the posts you will have enjoyed last year there are half as many again which didn’t get published. Half a dozen have been carried over but most, about 4 times as many have been discarded.

A few of these are completely written posts awaiting a final edit but which I decided weren’t worth publishing.
A few more are posts I started to write but decided to they were too off-topic or too personal.
A few more never got beyond the first sketch.
And the remainder never got beyond the title and a note or two.

Broadly I’m following the same pattern I have been advocating with OKRs and Backlogs: decide your goals, drive work from goals and discard the backlog every few months. Let ideas go makes space for new ones, and if any are so great that I really should have them, then I’m sure I’ll think of them again.

It occurred to me the other day that this is the same logic I use with newspapers. I still buy and read a physical newspaper several times a week. There are several reasons I like the physical versions but one of them is the timeliness of it.

I buy the newspaper in the morning. The news has been curated for me: I don’t go hunting across websites to find news I might like. Then, at the end of the day the paper goes in the recycling. If I didn’t read a piece then too late. I had 14 hours to read it, tomorrow is new day with new news.

In all these cases it is only by letting go of the past – of ideas and partially done work which I’ve invested in – that I have space for the new. I wager that new ideas will be worth more than those of the past which didn’t make the grade. I accept that I might loose a few valuable ideas but I also know that if they are really good I’ll probably think of them again.

Now a question: are our technologies keeping the past alive too long?

Since my blogging is all electronic it would cost nothing to keep those old blog ideas hanging around. Similarly our backlogs only became bottomless pits when we stopped writing them on index cards.

Digital newspaper allow you to read today’s news, some of tomorrow’s and any day in the past – this means navigating them can be hard. I’m regularly struck by the way many blogs and online journals hide the publication date.

Facebook makes it hard to loose friends and LinkedIn makes it hard to forget past work colleagues. We are captive to past posts, pictures and comments.

Forgetting has a role to play in letting in the new and allowing us to advance.

Just because we can keep the past current should we? I don’t think so. Even if it costs nothing in terms of storage and archives the past makes it harder to see what is before us because we are trying to see so much more.

(Image from Jose Antonio Gallego Vázquez on Unsplash)

Shall I tell you a story of a failed corporate transformation project?

A story of executives who enthusiastically embarked on a journey to greater employee involvement utilising new technology – embracing self-organisation in teams, or to use an older term sociotechnical systems.

A story of well intentioned, experienced, consultants who bit of more than they could chew. Consultants who would have followed organic, piecemeal growth, elsewhere but driven by executive desire to get the project done fast misled themselves. Consultants who adopted a cookie-cutter approach, expanded their team with less experienced consultants, while neglecting the very client employees they sought to enlighten.

Perhaps you are already bored, you’ve heard this story before. But what if I tell you it was PacBell in 1986? – 15 years before the agile manifesto.

This story, together with many others is in a book called Age of Heretics. By the end of the book I felt I had seen a glimpse of the future, and it wasn’t a happy future.

While I knew bits of the story – or stories – the booked filled in some pretty big gaps. It turns the “agile revolution” is a remake on a bigger scale, there is no happy ending but maybe there is reason to hope.

For most of the last 20 years me an others have been talking about a collection of ideas known as agile. It is well known that most of these ideas go back far further…

Eric Trist described “sociotechnical systems” which were the fore runner of self-organizing teams.

Edwards W. Deming and Philip Crosby began a quality movement which was the pre-cursor of technical excellence and things like pair programming, refactoring, automated testing, etc.

Toyota’s Lean system teaches the importance not just of quality but managing workflow, involving the workers, stockless production and just-in-time working.

But it turns out there are many more stories which are less well known. I knew a little of the Topeka Work System but was oblivious to similar experiments at Procter and Gamble.

Nor did I appreciate just how many of these ideas were interconnected already. That in the post war period the academics and practitioners who invented and experimented intermingled, shared ideas and built on one another.

It turns out that what were a few experiments in the 1950s grew in the 1960s. By the 1970s General Foods and P&G were building new factories on these principles and Shell was abandoning its Unified Planning Machinery.

While growth continued into the 1980s there were failures like PacBell. Despite great success General Foods was never able to capitalise on the Topeka success. In fact, in an eery future echo others in the company found it difficult to work with the self-organizing teams at the factory.

And thats why Age of Heretics also reads like back-to-the-future for agile practitioners. While many of the experiments were a great success many of them eventually succumbed to normality.

In some cases the guardian angel boss moved on and their successors failure to appreciate or protect the experiment.

Ideas failed to travel and experimental plants were seen as odd or difficult. When ideas did travel the transplanted seeds failed to grow. It turns out copying processes is only part of the change needed.

Just about all the case studies given in this book will resonate with those in the agile community. The PacBell case in particular could have been written about many large companies, particularly banks, on an agile transformation in the 2010s.

(There are some other pre-cursors of our current world in here too. Like the 1972 Limits to Growth report which pre-shadowed many of today’s environmental discussions.)

Its very easy to be depressed about agile transformation after reading these stories but I shouldn’t be. After all, now I understand things better maybe I can avoid them?

Perhaps more positively, despite all these failures these ideas keep coming back. Haighmoor coal mine may have been the first self-organizing team in 1950 but by 1960 there were more. Not all survived but more followed them.

Topeka may have been the largest example when it opened in the early 1970s. Despite facing challenges – the loss of key staff, neglect by the parent company, changes of ownership, expansion and down-sizing – it was still self-organizing until 2002.

Repackaged as agile these ideas have reached more teams than ever before. While there have been lots of failures and sacrifices in this time the ideas live on. Slowly, the superior performance of this way of working, the applicability to work in the digital age and the expectations of younger generations probably guarantees that this is the future.

However, that doesn’t guarantee success for any one company or team. There will continue to be failures. So, as we pause for breath I suggest you read the fascinating Age of Heretics – it may not contain the word agile but it is a both an agile history and prophecy.