tardate 2026

my recent reads..

Feb 3, 2026 AI

AI in the Call Centre

AI is decimating call centres, but two can play at that game! Inspired by true events😂 hero_image

The Agile Embedded Podcast is as thought-provoking as ever with their take on the Tyranny of the Urgent. The discussion focused very much on how the agile mantra of creating immediate customer value can lead a team astray, but it made me think of all the other ways I’ve seen and experienced the “Tyranny of the Urgent” over the years.

Three thoughts came to mind:

We’re Not Being Honest about Impact and Urgency
We are ignoring the Full Feature Lifecycle
When Things are Always Urgent, it may just be a Capacity Problem

Tyranny of the Urgent: An anti-pattern where short-term urgent demands systematically override long-term important work, causing reactive behavior and worsening future urgency.

Problem 1. We’re Not Being Honest about Impact and Urgency

Task priority should be a factor of both Impact and Urgency. This is as true in agile environments as elsewhere. It’s a common prioritisation technique that appears in many guises (in project management, ITIL support, Eisenhower matrix, PICK Charts) but as a concept is trivially simple.

No matter how a team calculates priority, it is very sensitive to the fact that both impact and priority are hard to quantify and extremely subjective.

In reality, I’ve often had to deal with, let’s say “misleading”, assessments of impact or urgency. For example:

the product owner claiming a feature is critical based on an imaginary concept of the customer
- i.e. trust me, I know what the customer needs without any data or actual customer input to back it up
- it can be a symptom of a team that is far past their initial requirements efforts and is now coasting.
- Solutions?
  - without being rude about it, find a way to reset expectations around validating requirements before they are accepted for development.
  - Discuss the “definition of done” for a story/requirement itself.
  - May need a jolt to re-engage meaningfully with the customer group, perhaps with a new round of focus group, customer surveys, or customer visits.
a sales person claiming features are deal-breakers for a new customer and must be urgently delivered to close the sale
- sometimes this may be true, but in many cases I’ve discovered it’s not (most painfully, after the fact)
- it may be “lazy sales”: passing the buck to development rather than do the hard work of selling the solution as-is and overcoming customer objections
- but it can also be a skills gap: sales or pre-sales don’t know the solution well enough or have the requirements analysis skills to help best assess the solution fit and gaps for the customer
- Solutions?
  - the main way I found to battle this is greater involvement of development in the pre-sales process, proposal design and review.
  - it may point to a lack of training on your product with the sales, pre-sales, or customer care teams
whatever the C-suite says this week is the most urgent and important thing to work on
- i.e. if you have the authority, you can bypass whatever process is in place for product management
- This can be tough, because at the end of the day “the boss is always right”!!
- I’ve mainly seen this in places where senior management either don’t understand the processes used to manage product development, or they don’t trust it to deliver the necessary results
- Solutions?
  - invest time in building the stakeholder relationships and educating them on how development works.
  - nothing beats a good track record to build trust.
    - if execs only hear about development when things go wrong, they’ll think that’s the norm
    - make sure to provide regular updates that include all the good news about the process working correctly

Problem 2. We are ignoring the Full Feature Lifecycle

The podcast did touch on the Three Horizons model for ensuring there’s always an innovation pipeline, but on a smaller scale I’ve seen insufficient attention paid to appropriately balancing effort across the full lifecycle of features.

The most common anti-pattern I’m sure we’ve all seen is all effort consumed on new feature development, and only allowing for some effort to be clawed back to fix bugs. The team ignores the important work of taking features from good to great, and never gets around to retiring features that no longer add value.

I’m my own practice I’ve found “4Rs Feature Lifecycle Analysis” a very useful diagnostic to combat this. In essence, all stories get classified as belonging to one of the four stages of a feature lifecycle:

Stage 1, Reveal: new feature development
Stage 2, Refine: improving a feature
Stage 3, Rectify: fixing bugs, CVEs, updating dependencies etc
Stage 4, Retire: removing the feature when it no longer has sufficient value

Looking at where effort is bucketed makes it very clear if the product management process is delivering a pipeline of work that matches the maturity of the product. i.e.:

during initial product development, one expects most effort to go into new feature development
after launch
- if one is not seeing a shift towards refinement, it may indicate we are stuck in “new feature mode” and are not taking the time to improve the “v1” features already launched
- and if we see rectification starting to swamp feature development, it may indicate systemic quality issues
in very mature products, we’d expect to see effort largely shift to rectification and ideally an uptick in retirement effort

If we are using agile software development process, isn’t Feature Lifecycle Analysis redundant? A well-balanced and high-performing team should be able to find the optimal balance by trusting the process:

customer/business requirements rule, and are represented in the team through a product owner or even an onsite customer
we prioritise work for each iteration as a team, balancing customer/business requirements with other things that the team knows are important in order to meet customer expectations (like performance)
we keep our iterations short and continuously deliver working software, so even if we get things wrong we can course-correct in short order

That is of course the ideal. But we operate in the real world, and many things can upset the balance. For example:

Urgency Trumps Impact
- It’s easy to find a queue of people ready to argue for the latest urgent requirement, but there’s no-one around to champion the more impactful stuff that hasn’t also been called out as urgent. Result? Six months later, we’ve delivered all the urgent things, but 90% of the potential impact (“value”) is still on the table.
The New Shiny
- The new shiny trumps last week’s idea. This can be a problem in startups where the founder/ideas person is also the product owner. Excellent at generating new ideas, but no time or ability to follow-through. So the team leaves a trail of half-baked implementations but never seems to achieve anything great.
Uninspired Leadership
- The team is looking for insight and vision to drive priorities but just hears “meh”. So the results are naturally also meh.
Unreal Priorities
- A product owner who is (consciously or not) skewing priorities towards a certain theme or faction over all others, like one particularly vocal customer. Or perhaps lacking real customer insight, priorities are out of touch with reality.
Weak Team
- A weak development team that’s not able to put up a convincing case for something they believe is important.
Domineering Team
- Conversely, a development team that is too strong and always manages to spin the product owner to their way of thinking.
Group Think
- Although we use a strict planning game to prioritize stories, the team is suffering from “group think” and priorities end up skewed to one point of view.
ScrumMaster At Sea
- A scrum master that doesn’t recognise there’s an issue of balance until it is too late, or is running out of tricks to help the team fix it.

Feature Lifecycle Analysis is really just a diagnostic that can present in a picture what may otherwise just be a gut-feeling that something is not quite right.

Problem 3. When Things are Always Urgent, it may just be a Capacity Problem

We refined our scope to death, optimised all our processes, fine-tuned our tools, made all the improvements surfaced by our retrospectives, ensured all our people are well trained and working at their best… BUT we are still consistently failing to meet expectations for feature delivery.

We may just need to admit we have a fundamental capacity issue, and no amount of clever scheduling can plan our way out of the hole. Are we trying to do the work of an 8 person team with a team of 3?

If that’s the case, frankly it’s time for leaders to step up and either:

reset expectations with stakeholders
or make the case for investing in greater capacity

Listen to the Podcast

Yes, it is an old episode from 2023 but no less relevant for the fact. I’m busily catching up on back episodes;-)

After Pivotal Tracker

When Broadcom/VMware announced it was shutting down Pivotal Tracker effective April 30, 2025, it signalled the end of an era. And had me scrambling to find a replacement!

TLDR: I moved to BardTracker and LiteTracker.

Pivotal Tracker (PT) was created in 2008 by Pivotal Labs as an internal project management tool based on agile principles. It was later released as a commercial product but eventually became part of VMware Tanzu Labs after its parent company, Pivotal Software, was acquired by VMware in 2019. Following VMware’s acquisition by Broadcom, Tanzu Labs was shut down in early 2025, and PT was retired in April 2025.

2008: Pivotal Labs develops Pivotal Tracker for internal use.
2012: The company, now known as Pivotal Software, is formed.
2019: Pivotal Labs is acquired by VMware and renamed VMware Tanzu Labs.
2023: VMware is acquired by Broadcom.
2025: Tanzu Labs is shut down in January, and Pivotal Tracker is retired in April.

I was first introduced to PT while working alongside Pivotal Labs consultants on Rails projects in 2008/2009. For me, it represented the same simplicity and effectiveness in planning that Ruby and Rails brought to development itself.

I was converted, and while I’ve had to use many other systems before and since (Jira, Trello, bugzilla, even FogBugz and others), nothing has helped me to just get things done so well, without adding undue cost or complexity.

So like many others, I was in a desperate search for alternatives in 2024/2025, and even considered writing my own if I couldn’t find anything suitable. This was especially true as I’d long since internalised PT and used it for getting things done in all aspects of life.

The good news: I found answers and was able to smoothly migrate all my ongoing PT activity to alternatives. Here’s a quick summary of what I ended up using

BardTracker

I’ve moved all my personal and small project activity to BardTracker. It was specifically developed by Bot and Rose Design (BARD) as a PT replacement for their own consulting work, and they now offer it as a service for others.

What I like:

it has a nice free tier - perfect, especially for personal GTD/TODO lists
GitHub integration
looks and works similarly enough to PT
is really well supported. I’ve had very fast response to any issues or features requests I’ve raised.
it’s backed by an operating concern, so should have some longevity

To consider:

the UI is not identical to PT - there are differences, some of which may be significant for you
no API access (yet)
no mobile app, but mobile responsive view is quite OK

LiteTracker

It really is the most complete and “identical” PT replacement that has made it into full operation. If you want something exactly like PT, this is the best I’ve found. As it has no free tier, I haven’t adopted it for personal projects, but it would be my first choice the next time I start a new project with a larger team.

What I like:

every feature you ever liked from PT is here
it really is pretty much identical
after the initial focus on migrating from PT, they’ve continued to add migrations from other popular planning tools
now has a mobile app

To consider:

the developer API is still a work-in-progress
only paid tiers

Other Solutions

Quick notes on some of the others I considered when looking for a PT replacement.

Direct PT Replacements

Lanes

The secret superpower of the most productive teams.
- I applied for the beta but never heard back
- appears they have now launched with something that looks very much like PT.
- Doesn’t mention having any integrations or API
- Have not tried it though
Pivotal Replacement
- Never made it live (yet)
Storytime
- Began a discussion on PT replacements
- Not a solution itself

Airline: the DC-3 in Post-war History

I recently discovered the British TV Series from 1982, “Airline”, currently free to watch on YouTube, thanks to “Forgotten British Television”. The star of the show is really the DC-3 (and an Austin Tilly). I can give you at least 4 reasons why it is wonderful viewing, and 1 reason why you’ll hate it!

The good:

For TV made as late as 1982, it brilliantly captures the immediate post-war period in Britain. From rationing and the black market, to social upheaval of returned services and the changing role of women in society, to the expectation of a new social contract reflected by the Beveridge Report and the Labour victory in 1945 - all are handled with convincing realism.
It features the forgotten history of the end of the British Mandate and the Palestine Emergency, with the Airline being dupped into smuggling guns for Zionist militias who were fighting the British at the time. The show deftly presents the moral dilemma that continues to dominate western politics to this day: sympathy and a need to atone for the treatment of the Jewish people in Europe up to and including the holocaust; yet discomfort with Zionist methods and all that means for others in the middle east, in particular the people of Palestine and Lebanon. For more on the period, I can highly recommend The Hundred Years’ War on Palestine by Rashid Khalidi.
Later episodes depict the Berlin airlift from a perspective I’d never considered before: the rapid assemblage of motley crews and operators to provide an airlift capability that had been unceremoniously moth-balled at the conclusion of WWII. For more on the history, I really enjoyed reading The Berlin Airlift by Robert Jackson.
Finally, if you appreciate the DC-3/Dakota - it is really the star of the show. There is lots of footage of it in the air and on the ground, in pieces and various liveries. And as a bonus, the show regularly co-stars a period Austin Tilly.

In short, so many aspects of the story and production will have one thinking: “crikey, forgot about that!” Or even, “crikey, never knew that!”

So what’s not to like? Well in short: “Jack Ruskin”. This is a lead character you will learn to loathe, as does his fiancée who ends up leaving him by the end of season 1. For all his drive and passion to establish a new airline, he manages to be obnoxious to all concerned, far beyond just being a “blunt no-nonsense Yorkshireman”. Perhaps the main reason there is no season 2, is that there’s no amount of success he could have with the airline to redeem him as a character!

Airline: The Synopsis

After the end of the Second World War, Jack Ruskin, a demobbed pilot, attempts to make a living from his one-plane airline business.

Newly-discharged from the RAF after World War II, Jack Ruskin, a blunt no-nonsense Yorkshireman, decides to set up his own airline, Ruskin Air Services. Something of an idealist, Jack is prepared to bend every rule in the book to achieve his goal of flying a Dakota once again. He soon does a deal with Ernie Cade, a notorious spiv who can lay his hands on any item of war surplus - for the right price - and then enlists Peter Witney as co-pilot and Jock McEvoy as maintenance engineer. But his long absences start to put a strain on his relationship with Jennie, his girlfriend.

Episode summary:

S1.E1 “Look After Number One”: In 1946 Flight Sgt. Russell tries to stay in the RAF as a pilot. A former mentor falls under suspicion of massive illegalities and needs a favor, leading to a brush with smuggling.
S1.E2 “Brave New World”: Demobilized from the Air Force, Jack Ruskin hustles to start his own private air service with a few other men.
S1.E3 “Conscience”: Ruskin Air Service’s first cargo run is a failure when the cargo of eggs is confiscated. Debts and interest on the aircraft loan pile up. A load of tractor parts headed to Palestine goes awry when a fuel stop leads to a change in cargo.
S1.E4 “Touch and Go”: February. Ruskin Air Services is grounded: locked in the icy grip of winter, Enter Ernie Cade, with a proposition the men find hard to refuse, Had they known what they were letting themselves in for, they would have remained earthbound.
S1.E5” Fool’s Errands”: March 1947, Ruskin is broke. His plane is badly damaged and Cade is putting the screws on. Hardly the time to expand, one would think, But Ruskin’s determination to succeed knows no bounds.
S1.E6 “Captain Clarke Plus One”: Spring 1947, With the forces of bureaucracy massing against him in England, Ruskin finds himself in Malta, with no fuel, no cooperation and no way out. All seems lost until the winds of fortune change - for the worse.
S1.E7 “Not Much of a Life”: Stripped of his pilot’s licence and no airline to run, Ruskin, undaunted, embarks on a new ‘money earner’ - and that’s where he comes unstuck: military training hasn’t exactly prepared his crew for carrying passengers.
S1.E8 “Officers and Gentlemen”: Spring 1948. Dark clouds are gathering over Jennie and Jack’s wedding plans, The airline is in deep -and deadly - trouble. Ruskin must make a decision which will affect the lives of everyone around him, But will he make the right choice?
S1.E9 “Too Many Promises”: Autumn 1948. With high financial rewards to be made from the Berlin airlift, independent operator Ruskin has nothing to operate. He has lost his licence, one of his planes and most of his crew. Can he save himself from disaster.

Airline: Playlist by Forgotten British Television

Available on YouTube

For Modellers: The DC3

The Douglas DC-3, also known in its military role as the Douglas C-47 Skytrain or Dakota (RAF designation), is a propeller-driven airliner manufactured by the Douglas Aircraft Company. It had a lasting effect on the airline industry from the 1930s, with examples still in use today.

In 1:72 scale, Airfix is the queen of the sky. It’s new tool from 2013 has shown up in a number of releases - most recently in 2022 as the Airfix Douglas C-47 Skytrain No. A08014.

Other recent toolings of the DC-3 in 1:72 include:

A&A Models Basler BT-67 No. 7242 from 2024
HobbyBoss C-47A Skytrain No. 87264 from 2017
Amodel Li-2P/T No. 72244 from 2011

In 1:144 Ukrainian manufacturer Roden has a 2013 tool, most recently released in 2015 as the Douglas AC-47D Spooky No. 310.

Hasegawa seems to dominate “airline scale” 1:200 offerings, with a 1994 tooling, most recently released in 2012 as the L2D Type Zero Transport & C-47 Skytrain “Pacific Carriers” 2 kits in the box No. 10687.

For Modellers: The Austin Tilly

A Tilly is a utility vehicle produced during the Second World War based on existing car designs for use by the British armed forces. They were all officially classed as Car, Light Utility 4 x 2.

The Austin variant is used in the show:

tilly