The Agile Daily Standup - AgileDad

The Agile Daily Standup - AgileDad

By AgileDad ~ V. Lee Henson

Rise and shine, Agile enthusiasts! Kickstart your day with 'The Agile Daily Standup' podcast. In a crisp 15 minutes or less, AgileDad brings you a refreshing burst of Agile insights, blended seamlessly with humor and authenticity. Celebrated around the world for our distinct human-centered and psychology-driven approach, we're on a mission to ignite your path to business agility. Immerse yourself in curated articles, invaluable tips, captivating stories, and conversations with the best in the business. Set your aspirations high and let's redefine agility, one episode at a time with AgileDad!
Available on
Apple Podcasts Logo
Castbox Logo
Pocket Casts Logo
Spotify Logo
Currently playing episode

Fundamental Product Management is Most Important In the AI Age

The Agile Daily Standup - AgileDadFeb 20, 2025
00:00
09:28
Why Our Family Is "Different"
May 16, 202507:30
MVP is Dead!! We Should Focus on MLP Instead!
May 15, 202506:48
Remove From Your Process as Often as You Add To It - Mike Cohn

Remove From Your Process as Often as You Add To It - Mike Cohn

Remove From Your Process as Often as You Add To It - Mike Cohn

Can you imagine being so angry about a team doing something wrong that you institute a rule for them to follow for the next 100 years? Literally 100 years.
Queen Victoria was that angry.
One day in 1894, the Queen went to the Horse Guards building expecting her Household Cavalry to be ready to escort her back to Buckingham Palace. She instead found the guards either asleep, drunk, or gambling.
Infuriated, she commanded that an inspection of the Guards be held at 4:00 p.m. every day for the next 100 years.
I’m guessing the Guards got the message to stop sleeping, drinking, and gambling on duty long before 100 years. The 4:00 p.m. inspection could have stopped after perhaps a year or two. Maybe sooner.
Things that become part of a team’s process sometimes stay there too long, like that inspection of the Queen’s Horse Guards.
This happened in a company that had a large database that was shared by multiple applications. When one team changed the database, they screwed up the change and left other teams scrambling to quickly change their code in production.
They held a multi-team retrospective and agreed that each team would produce a Database Impact Report every sprint. The report would describe how a team’s work would affect the database.
This doesn’t sound horrible yet, except it was rare for most teams to do any work at all in a sprint that would affect the database.
These teams were still expected to complete a Database Impact Report each sprint that basically said:
 

  • No impact
  • No impact
  • No impact

These no-impact Impact Reports were emailed to all other teams.
After opening a PDF every two weeks that said “no impact,” recipients stopped bothering to even read the reports that were still being generated.
Stop. Just stop.
These reports were probably useful for a period. They may have helped identify a risk. They certainly made people more aware of the impact a database change could have on other teams.
But after a while, they should have been removed from the teams’ process, especially once the teams who actually did routinely alter the database had found better ways of communicating potential impacts.
In retrospectives, it’s always tempting to look for new things to add (“Let’s start using AI to inspect our code!”).
But make sure you also reserve time in retrospectives to look for things to remove.
Unless your team members are all drunk, gambling, or asleep at 4:00 p.m., you can probably find something to remove from your process.
A barely sufficient process with unnecessary actions and rules removed will help you succeed with agile

 How to connect with AgileDad:

- [website] https://www.agiledad.com/

- [instagram] https://www.instagram.com/agile_coach/

- [facebook] https://www.facebook.com/RealAgileDad/

- [Linkedin] https://www.linkedin.com/in/leehenson/

May 14, 202505:11
Advice From a Tech CEO - Learn Skills Outside of Tech
May 13, 202509:08
STOP Creating a Sense of Urgency. START Fostering a Sense of Purpose
May 12, 202507:45
18 Cheat Codes to Life, to Put You 10 Years Ahead of Other People
May 09, 202508:30
How To Defeat The 3 Most Common Arguments Against Technical Debt
May 08, 202510:16
Agile Is Broken, So What Should Startups and Tech Companies Do Instead?
May 07, 202512:43
Are Story Points Helping Your Team?
May 06, 202507:31
Scrum Masters Are Useless — Product Managers Should Run Their Own Scrum
May 05, 202507:25
The Time For You to Grow
May 02, 202504:39
The Job Market Rebound is Going to Catch Everyone Off Guard
May 01, 202510:08
Five Things You Should Know as a Leader Implementing AI
Apr 30, 202507:15
3 Key Lessons From My First Product Role
Apr 29, 202510:25
The 6 Skills You Need to Become a Strategic Leader
Apr 28, 202510:11
How Firm a Foundation...
Apr 25, 202506:07
Three Ways to Handle Unfinished Work - Mike Cohn

Three Ways to Handle Unfinished Work - Mike Cohn

Three Ways to Handle Unfinished Work - Mike Cohn

Over the past three weeks, I’ve been sending you tips about spillover on agile teams. We’ve talked in depth about the problem of habitual spillover—when a team routinely rolls unfinished work forward from sprint to sprint.
This week, I want to share 3 ways to handle the unfinished work that will occasionally be left over by even a great agile team.
 

1. If You Want a Guarantee, Buy a Toaster


My first bit of advice for how to handle unfinished work is to remember that even the best agile teams sometimes miss their goals. That’s OK and even desirable to a certain extent.
Sprint goals are not guarantees. (As Clint Eastwood’s character Nick Pulovski says in The Rookie, “If you want a guarantee, buy a toaster!”) Leaders, stakeholders, and even the team themselves might need an occasional reminder about this.
A team’s commitment to a sprint goal is a promise to do its best to achieve that goal. If team members are perpetually forced instead to make a guarantee, they will guarantee less in order to be safe.
Sometimes a team needs to make a guarantee. There might be times when a client or customer needs a capability by a certain date. The finance group may need to run year-end reports in early January, for example.
In general, though, we don’t want to force a team into a guarantee. We ask a team to commit to something reasonable and then we’re understanding if they miss it. Falling short on the occasional commitment is not a failure-–it’s usually a sign of bad luck or a team that’s striving to do too much.
 

2. Don’t Roll Work Forward Automatically


My second bit of advice is to resist the urge to automatically roll over the unfinished work into the next sprint. Put it in the product backlog instead.
The item may be back on the product backlog for a millisecond, but there should be a conscious decision by the product to continue work on it.
(Logistically, I don’t care if it’s easier in your tool of choice to move the item to the next sprint rather than to the product backlog first. The key is that there is a decision to continue the work.)
If the product owner decides the team should work on the partly finished item immediately in the next sprint, bring in the product backlog item as is. 
Don’t re-estimate it. Don’t rename it. Don’t take partial velocity credit. Just bring the item into the next sprint and take the full velocity credit when it’s complete.
But if the item is deferred for later, go ahead and split the story into what makes sense. Take partial velocity credit for the work you completed last sprint, then write a new story that describes only the missing functionality and estimate that story.
 

3. Document the Cause


My final bit of advice for dealing with unfinished work is this: Whenever work is unfinished at the end of a sprint, the team should take time in the retrospective to consider whether it was preventable.
Sometimes unfinished work is just bad luck or bad timing, such as a team member being ill or a problem being found late in the sprint that could not have been found earlier. Sometimes it’s just the result of aiming too high for one sprint.
But you might uncover something that is becoming a bad habit.
Whatever the cause, it’s always worth considering whether something can be done to prevent it from affecting future sprints so that your team can succeed with agile.

How to connect with AgileDad:

- [website] https://www.agiledad.com/

- [instagram] https://www.instagram.com/agile_coach/

- [facebook] https://www.facebook.com/RealAgileDad/

- [Linkedin] https://www.linkedin.com/in/leehenson/


Apr 24, 202506:37
Is the Party Over For Scrum Masters and Agile Coaches?
Apr 23, 202509:51
Five Most Forgotten Parts From The Scrum Guide
Apr 22, 202508:42
Dependencies Destroy Agility and Predictability
Apr 21, 202510:49
7 Tips To Read Someone’s Personality in 10 Seconds
Apr 18, 202507:48
6 Daily Habits of Highly Effective Scrum Masters
Apr 17, 202506:17
Scrum Fails When Product Owners Think They Are The Boss
Apr 16, 202511:02
Why Your Scrum Teams Are Failing - The Hard Truth
Apr 15, 202507:30
Product Owners vs. Product Managers vs. Project Managers
Apr 14, 202508:06
The 5-Second Conversation Hack
Apr 11, 202504:48
The Great Agile Reset

The Great Agile Reset

The Great Agile Reset

1. Framework Fatigue Is Real

Marty Cagan nailed it recently: “The product model addresses three major dimensions: how you decide which problems to solve (product strategy), how you solve these problems (product discovery), and how you build, test, and deploy your solutions (product delivery). Real Agile can certainly help with this third dimension.” (Source.)

Translation: Organizations are done with copying and pasting frameworks. They realize that true agility means finding your own path to creating value. Standardized training and certification programs? That train has left the station. #ParadigmShift

2. AI Is Eating Agile (Sort Of)

Have you played with DeepSeek R1 yet? This isn’t just another tech trend. This is a seismic shift in how knowledge work happens. No, ChatGPT or Claude won’t steal your job tomorrow. But what about your colleague who’s mastered prompt engineering, AI-based data analysis, and agents? They might make you obsolete.

How to connect with AgileDad:

- [website] https://www.agiledad.com/

- [instagram] https://www.instagram.com/agile_coach/

- [facebook] https://www.facebook.com/RealAgileDad/

- [Linkedin] https://www.linkedin.com/in/leehenson/

Apr 10, 202508:32
How to Break the Spillover Habit - Mike Cohn

How to Break the Spillover Habit - Mike Cohn

How to Break the Spillover Habit - Mike Cohn

For the past two weeks, I’ve been writing about the problem of habitual spillover—when a team routinely rolls over unfinished work from sprint to sprint.
So far, we’ve talked about why spillover happens, and why it’s a problem, plus I’ve given steps to start a reduction in your team’s spillovers.
This week, I want to share two ways to break your team’s rollover habit.
 


Sometimes teams miss their goals. That’s OK. Sometimes teams miss when they aim high and fall a little short. Don’t try to fix those teams—celebrate their effort.
Other times teams miss because they just hit a run of bad luck for a handful of sprints. Again, no need to intervene there. (Next week, I’ll share what to do with the unfinished work that results from either of these first two scenarios.)
Most often, though, teams miss because they are overly optimistic about what they can achieve. They plan each sprint to be a best-case scenario.
If you think that could be your team, in your next sprint planning meetings try asking questions like these:
 

  • What could go wrong that could cause the team to miss its goal?
  • What has to go right to achieve this goal? These questions can help a team see any risky assumptions they’re making about how easy the planned work will be.

 

 

As most of us who made New Year’s resolutions at the beginning of 2025 have re-discovered by now, old habits die hard. Sometimes you have to take drastic action to realize lasting results, and to succeed with agile.

Curb Their Enthusiasm   Drastically Under-commitIf these kinds of questions don’t help the team make more realistic guesses about what they can accomplish, you might have to resort to drastically reducing what the team commits to achieving.
At the next sprint planning, encourage your team to truly under-commit. I’m not talking about cutting the sprint goal by some small amount, like 10–20%. I’m saying you limit team members to committing to only 50% of what they believe they can accomplish.
The team may push back on this. They are used to filling up their sprint and will be optimistic that they can get a lot more done than the items they’ve chosen. Don’t give in.
When team members push back, remind them that if they run out of work to do, they can always bring more in. But hold firm that no work will come in until the sprint goal is achieved and all the work planned into the sprint is complete.
(You’ll likely need to have a talk with the product owner prior to sprint planning so they too can be prepared to hear that the team is bringing only a few items into the sprint.)
The goal in under-committing is to let the team feel what it’s like to add work into a sprint rather than always needing to drop work.
After they feel this, they’ll likely want to feel it again.
Encourage them to plan a bit more work into the next few sprints until they get close to missing their goals and rolling over again. Incorporate the enthusiasm-curbing questions as needed.

How to connect with AgileDad:

- [website] https://www.agiledad.com/

- [instagram] https://www.instagram.com/agile_coach/

- [facebook] https://www.facebook.com/RealAgileDad/

- [Linkedin] https://www.linkedin.com/in/leehenson/


Apr 09, 202505:11
Grow Your Product Management Skills
Apr 08, 202508:31
5 Things a Manager Should NEVER Do...
Apr 07, 202506:22
From Dreary to Dazzling - 1 Young Man Makes a Difference
Apr 04, 202506:25
Effective Storytelling in Product Management
Apr 03, 202508:06
3 Ways To Improve Team Morale
Apr 02, 202509:37
Welcome to AgileJudith
Apr 01, 202502:09
Transitioning from a Product Manager to a Product Lead
Mar 31, 202505:26
Shake Off The Winter Blues, Spring Is Here!
Mar 28, 202503:39
Start With No... Why Most People Should NOT Be Managers
Mar 27, 202510:54
The 2025 Product Manager - Winning Playbook
Mar 26, 202508:19
The 2-Minute Meeting Hack
Mar 25, 202506:01
The Top 3 Weekly Meetings That Will Help You Be the Best Leader!
Mar 24, 202510:30
Welcome Home Anthony Henson!
Mar 21, 202504:56
Lead an Agile Team With Context and Control - Mike Cohn

Lead an Agile Team With Context and Control - Mike Cohn

Lead an Agile Team With Context and Control

You can only get so far by attempting to manage the performance of people through control. It is far better to lead or manage people by defining the context of their work.
I was fortunate to learn this lesson early on when I worked in...a fast food restaurant. My manager, Jim, trained me that each burger was to be dressed with:
 

  • 2 leaves of lettuce
  • 2 tomatoes
  • 3 slices of onion
  • 3 pickles
  • defining the wildly important goal (WIG) the team is working toward
  • helping people deeply understand and empathize with users
  • guiding a team in defining its igniting purpose, an intrinsic motivation that inspires exceptional performance
  • understanding the strengths and weaknesses of competitive products


He didn’t drill this into my head. He didn’t inspect my burgers. He didn’t pop-quiz me.
Instead, he explained the context, the reason why our burgers should be dressed exactly that way.
He told me to imagine a customer who orders a burger with extra pickles and a cook who loves pickles and puts five on each burger by default. When asked for extra pickles, that cook puts on seven.
That’s too many for the customer who, on a return visit, asks for “light pickles.” That burger is made by a different cook who would normally put on three pickles and so puts just one on when asked for light pickles.
My boss gave me a vision of hapless customers alternately ordering extra or light pickles and never getting what they want due to the preferences of the cooks.
I remember the context he defined 40+ years later. How long would pimply-faced me have remembered these amounts if my boss had merely presented them as rules?
My manager defined the context of my customer—a hungry person seeking consistency. And that was enough.
Leading through context can involve of mix of things such as:
 
Leading an agile team—whether as a manager, executive, Scrum Master, product owner, team lead or other leader—is different. It requires new skills.
A self-organizing team resists rules and thrives on creativity and freedom. Leading such a team by providing context can also cause it to excel,

How to connect with AgileDad:

- [website] https://www.agiledad.com/

- [instagram] https://www.instagram.com/agile_coach/

- [facebook] https://www.facebook.com/RealAgileDad/

- [Linkedin] https://www.linkedin.com/in/leehenson/


Mar 20, 202504:18
The Art of Strategic Decision Making - Product Manager Edition

The Art of Strategic Decision Making - Product Manager Edition

The Art of Strategic Decision Making - Product Manager Edition

In the fast-paced and ever-changing world of product management, the role of a senior product manager stands out owing to the exceptional combination of talents, perspectives, and strategic thinking that they bring to the table. Senior product managers take a different approach to their position than their junior colleagues do, as they are frequently faced with a large array of responsibilities. They have mastered the capacity to maintain a balance between thinking about the large picture and thinking about minute details, deliberate product direction while managing cross-functional teams, and link product decisions with the outcomes of business operations.

How to connect with AgileDad:

- [website] https://www.agiledad.com/

- [instagram] https://www.instagram.com/agile_coach/

- [facebook] https://www.facebook.com/RealAgileDad/

- [Linkedin] https://www.linkedin.com/in/leehenson/

Mar 19, 202505:21
The First Principles of Product Management
Mar 18, 202514:45
Agile is NOT Dead... It is Just in a New Era!

Agile is NOT Dead... It is Just in a New Era!

Agile is NOT Dead... It is Just in a New Era!

The New Agile Principles

1) Own The Problem & The Solution

Agile addresses complexity, where uncertainty reigns. There simply is no clear-cut solution to your problems. What is worse, the moment you apply a solution without understanding it, you surrender control and become a spectator.

The first principle is to understand and fully accept that the only person who can decide what the solution might be is the person who is closest to the problem — you. Embrace this responsibility.

2) Be a Learner

Effective problem-solving requires knowledge. The only way to take responsibility for your problems is by having the necessary knowledge at hand. And the only way you can do this is by becoming a scholar. Continuously learning.

Knowledge is power. The more you know, the better you can understand your problem and the more solutions you will be able to come up with. The better you will be able to spar with others. The better you can take responsibility for your problems.

Innovation rests on the shoulders of those who came before you.

3) Be Critical

Knowledge is merely information. To wield knowledge effectively you need wisdom.

Wisdom comes from scepticism, from asking questions, being aware of assumptions, deep analysis, seeking diverse perspectives and engaging in thoughtful discussion. Strive to understand the context and the limitations of the knowledge you have. Strive to discover the gaps in your knowledge.

Being critical is the only way to discern what the value and applicability is of any knowledge.

4) Be Creative

Complexity means continuously facing novel problems that demand original solutions. That can only happen with creativity. Experimentation.

Accept that! Realize that that is the job!

Again, you may stand on the shoulders of geniuses and most of what you create may be derivative, but in the context of your particular problem, the solution will always be an act of creation, something unique.

5) Be Humble

Wielding the previous principles effectively will do awesome things for your self-confidence. Solving problems will become a game you love to play.

But beware! Arrogance is fatal. The only way to remain effective is by embracing humility and always accepting that whatever you come up with may and probably will fail, and can always be improved.

Humility is the foundation of continuous improvement. It leads to the need to experiment and validate, a need to second-guess yourself, a quest to make absolutely sure your solutions truly work.

6) Be a Teacher

Last of all, be a teacher. This may sound weird, but the truth is that teaching solidifies understanding. Teaching, whether through your teams, through writing, presentations, or mentorship, forces you to articulate your thoughts clearly, and forces you to structure your knowledge and identify gaps in your understanding.

This is the true sign of mastery of your profession.

How to connect with AgileDad:

- [website] https://www.agiledad.com/

- [instagram] https://www.instagram.com/agile_coach/

- [facebook] https://www.facebook.com/RealAgileDad/

- [Linkedin] https://www.linkedin.com/in/leehenson/

Mar 17, 202508:13
Bring Out Your Stagnation!

Bring Out Your Stagnation!

Bring Out Your Stagnation!

In the bustling village of Progressia, every Tuesday morning, the town crier—an overworked man in a tattered robe named Nigel—pushed his old wooden cart through the cobbled streets, shouting:

"Bring out your stagnation! Bring out your stagnation!"

It was a longstanding tradition. Villagers would shuffle out of their homes, dragging out bad ideas, outdated habits, and half-baked projects, dumping them onto the cart so they could be disposed of properly.

One day, old farmer Reginald hobbled out, dragging something heavy behind him.

“Here’s my career,” he grumbled. “It hasn’t moved in years.”

Nigel peered down at the heap of dusty resignation letters, ignored training courses, and a suspiciously untouched LinkedIn profile. He poked it with a stick.

“Oh no, that’s not quite dead,” Nigel said. “It just needs a bit of effort!”

“Nonsense,” said Reginald. “I’m stuck, out of ideas, and might as well give up.”

Suddenly, the heap of career mistakes coughed and sat up. “I’m feeling much better,” it croaked. “I think I’ll take a course on Agile leadership and try networking again.”

Reginald frowned. “Look, can we just throw it on the cart? Makes things simpler.”

But Nigel shook his head. “You see, mate, the problem isn’t that your career is dead. It’s that you stopped improving. If you’re still breathing, you can still grow.”

A murmur of agreement spread through the crowd. People began dragging out their own half-forgotten goals—neglected gym memberships, dusty musical instruments, and an entire sack labeled "New Year’s Resolutions (2009-2024)".

Nigel grinned. “See? You don’t need to get rid of your past—you need to upgrade it! Continual improvement, people! That’s how you avoid ending up on the cart.”

From that day forward, Progressia changed. Every Tuesday, instead of throwing away their “stagnation,” people took their old ideas and revitalized them—learning new skills, trying new methods, and embracing a growth mindset.

And as for Reginald? Well, he got himself a Scrum Master certification and became quite the success. (Though he still grumbled about it.)

Moral of the story: Don’t throw yourself on the cart too soon. If you’re still breathing, you can still grow!

How to connect with AgileDad:

- [website] https://www.agiledad.com/

- [instagram] https://www.instagram.com/agile_coach/

- [facebook] https://www.facebook.com/RealAgileDad/

- [Linkedin] https://www.linkedin.com/in/leehenson/

Mar 14, 202504:52
The Top 5 Daily Rituals of Highly Effective Leaders
Mar 13, 202507:13
Why a Spillover Habit Is So Harmful - Mike Cohn

Why a Spillover Habit Is So Harmful - Mike Cohn

Why a Spillover Habit Is So Harmful - Mike Cohn

Welcome to the second email in the spillover series. We’re talking today about why habitual spillover—the phenomenon of unfinished work piling up and carrying forward sprint after sprint—is so harmful to teams.

As a reminder, 

  • Last week, I explained why spillover happens
  • This week, I’ll describe why habitual spillover is a problem
  • Next week, I’ll give you some ideas for how to break your team’s rollover habit
  • Finally, I’ll talk about what to do with unfinished work when spillover happens

 

Why is Habitual Spillover a Problem?

As we talked about last week, teams will sometimes miss their sprint goal, especially when that team is ambitious and aiming high. And that’s OK.

But teams that develop a consistent pattern of overcommitting and then carrying work forward cause problems for themselves and for the organization as a whole.

Teams That Deliver Routinely Are Predictably Dependable

The main problem with habitual spillover is Lack of Predictability / Dependability.

Every organization benefits from some level of predictability. I worked with a company once that was preparing for its IPO.

Despite the tremendous pressure to meet revenue goals prior to going public, the CEO told me he’d happily trade some revenue for greater predictability. Being predictable is that important.

Predictability shouldn’t be the primary goal for an agile team, but it should be a goal.

It’s the same in sports. Basketball players strive to make every free throw. But a player who sinks the ball in the basket about 80% of the time is considered a high performer. That player can be reliably counted on to make most of their free throws.

Baseball players also strive to get a hit every time they’re at bat. And believe it or not, they are considered great, highly predictable hitters, if they manage a hit about 35% of the time—reflected in their .350 batting average.

Like those sports players, agile teams are expected to try to deliver everything they think they can, every time. But realistically, if an agile team achieves its goal 60–80% of the time, they are providing a high level of predictability.

Teams That Demonstrate Frequent Progress Are Happier & More Creative

A second, related reason your teams want to finish what they’ve started most of the time is a phenomenon called the power of small wins. In a 2011 study, Amabile and Kramer found that tangible, visible progress is a key factor in people’s enjoyment of work, and by extension their level of creativity.
It’s almost impossible to get a true sense of progress on “mostly done” work because until it’s fully done, you can’t really gauge the amount of work remaining.

This is known as the 90% syndrome. Software projects are 90% done for 90% of their schedule, and that’s hard on everyone.
When progress stalls and work rolls over, teams lose their sense of accomplishment from making measurable, demonstrable progress. (Want to know more? Read this blog and discover several reasons why it’s so important for teams to get to done.)

Teams that routinely fail to deliver on their goals lose trust with the organization and miss the sense of accomplishment that comes from finishing. That’s why next week’s tip will be things you can do to help break your team of the spillover habit so they can succeed with agile,

How to connect with AgileDad:

- [website] https://www.agiledad.com/

- [instagram] https://www.instagram.com/agile_coach/

- [facebook] https://www.facebook.com/RealAgileDad/

- [Linkedin] https://www.linkedin.com/in/leehenson/

Mar 12, 202508:02
Did We Fail Agile? Shame On Us!!
Mar 11, 202513:41
How To Prioritize Risk As a Product Manager
Mar 10, 202508:13