The Daily Standup

Psychology of High-Performing TeamsThe most critical psychological factor in team performance is psychological safety. This concept describes a shared belief held by members of a team that the group is a safe place for interpersonal risk-taking. In environments with high psychological safety, team members feel confident that they will not be embarrassed, rejected, or punished for speaking up with ideas, questions, concerns, or mistakes.When a team lacks this foundation, members enter a state of self-protection. This cognitive load diverts energy away from problem-solving and toward managing one’s own reputation. Google’s extensive “Project Aristotle” study confirmed this, finding that psychological safety was the single most important factor in determining a team’s success, outweighing the individual intelligence or experience levels of the members.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/

A Beautiful Day In The NeighborhoodWe all have a LOT to learn from Fred Rogers! His kindness and willingness to serve has not gone unnoticed! 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/

Traditional Product Management Is Ending in 2026For years, product management followed a familiar playbook.Gather requirements. Write PRDs. Prioritise backlog. Run sprint rituals. Coordinate across teams. Ship features.That model worked in a world where building software was slow, expensive, and engineering bandwidth was the biggest constraint.But in 2026, that world is changing fast.AI is reducing execution time. Prototypes can be built in hours. Research can be synthesized in minutes. Code generation is accelerating delivery. Design iterations are faster than ever.Which means something important is happening:Traditional product management, built around coordination and process, is losing relevance.And a new version of product management is taking its place.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/

What Cinco de Mayo Can Teach Us About Agile - Mike CohnToday seems like a good day to celebrate Cinco de Agile.
Cinco de Mayo commemorates the Battle of Puebla, when a smaller, less-equipped Mexican force defeated a larger French army.
There’s an agile lesson in that.
The side with the bigger plan, more resources, and more confidence doesn’t always win.
Sometimes the winner is the side that can adapt faster.
That’s one of the biggest differences between agile and waterfall.
Waterfall assumes that if we plan thoroughly enough up front, we can control the outcome.
Agile assumes that once real work begins, we’ll learn things we couldn’t have known at the start.
When customers change their minds, markets shift, or the team learns something new, fast feedback beats slow certainty.
A team that delivers something small, gets feedback, and adjusts can outperform a team that spends months moving confidently in the wrong direction.
That’s the real lesson.
It’s not that small always beats big.
It’s not even that agile always beats waterfall.
It’s this:
In changing conditions, adaptability is your biggest competitive advantage.
So if your current plan feels a little too certain, it may be worth asking one uncomfortable question:
What are we doing to learn faster?
Because in product development, learning speed often determines who wins.
Happy Cinco de 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/

The Hole in Your Product Team That Keeps Swallowing UsersA new employee engagement platform launched its pilot with a perfect customer. Warm relationship at the CEO level. Company-wide mandate. Strong early results from the users who engaged. One problem: most of the company never touched it. Despite the mandate. Despite the results sitting right there in the data.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/

What Servant Leadership Actually MeansWhen I first heard the term “servant leader,” I pictured someone endlessly helpful. Always available. Always saying yes. Smoothing every edge, softening every message, making sure nobody was ever uncomfortable.I was wrong. And for a while, that misunderstanding made me a less effective Scrum Master.Here’s the truth I had to learn the hard way: Servant leadership isn’t about making everyone comfortable. It’s about making everyone capable.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/

Be Quick NOT To JudgeAre we quick to form opinions about others? We should not be... 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/

AI Breaks the Agile Sweet Spot For Team SizeHow big should your Agile taem be? Does Agentic AI change everything? Lets listen and explore how team sizes may EXPLODE! 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/

A Plan is Not a Commitment - Mike CohnOne of the fastest ways leaders create overcommitment is by treating a plan like a guarantee.
An agile team builds its plan from what it knows at the time: assumptions, estimates, priorities, and constraints. That means every plan is probabilistic. It has some chance of coming true, but that chance is not 100%.
That is why I coach teams to aim for about 80% success.
Aim much higher than that, and teams will often bring too little into the plan. Aim much lower, and others in the organization do not get the predictability they need to make their own plans.
So yes, it is fine to ask a team for a commitment. But the team determines what they can commit to.
And leaders need to understand what that requires.
A team asked for a commitment will include a margin of safety between its plan and its commitment. It has to. A commitment has to survive interruptions, surprises, dependencies, and the normal friction that shows up once work begins.
That means a commitment needs margin.
And margin is the part leaders often resist.
A team may plan to complete forty points of work. That does not mean they should commit to forty.
If they commit to all forty, they are assuming very little will go wrong.
That is not a real commitment. It is simply hoping the plan goes perfectly.
Real commitment is what the team can stand behind, even when the sprint is not perfect.
So if you want an honest commitment, do not ask the team to commit without changing anything else.
Ask instead:
 

• What could you commit to with confidence?
• What margin do you need?
• What would have to be true for this to be a real commitment instead of a hopeful plan?

Those questions force the real tradeoff into the open.
If the date is fixed, scope may need to flex.
If the scope is fixed, time may need to flex.
But something usually has to move.
That is the part leaders often skip. They hear a plan, silently upgrade it to a commitment, and then act surprised when the team misses it.
Do not do that.
A plan is useful. A commitment is valuable. But they are not interchangeable.
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/

Your Retrospective Never Actually Fixes the Alignment ProblemThe retrospective is one of the most protected ceremonies in agile. Scrum teams hold it every sprint. SAFe bakes it into every iteration. Coaches run workshops on how to run better ones. And yet, the same misalignment issues resurface sprint after sprint.This isn’t a facilitation problem. It isn’t a psychological safety problem. It is a structural mismatch: teams are applying a periodic, backward-looking review to a continuous, structural problem.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/