The Daily Standup

What Seinfeld Taught Me about Iterative and Incremental - Mike CohnAgile is both an iterative and incremental process. I’ve taught this in classes for 25 years. Yet I’ve never felt like I had the right way to explain how they both differ and relate.
Until now.
I recently watched the documentary “Comedian,” about Jerry Seinfeld deciding to return to standup comedy after ending his long-running hit television series.
The film shows Seinfeld developing a completely new act. He couldn’t rely on jokes from his standup routines from a decade earlier.
He begins by performing for just a few minutes at small comedy clubs. After each performance he refines the wording, sequence, and pacing of his jokes. He’s iterating over each joke.
As he finds material that works, he adds time to his show. His performance goes from five minutes to ten. He is incrementally building his show. He continues adding increments (new jokes) until he achieves his goal of more than an hour of new material.
Refining each joke is iterating. Adding jokes bit by bit until he has a full show is incremental.
This example also shows why iterating and incremental aren’t very good on their own. Imagine a comedian who only iterates over existing material but never adds new material. Or one who keeps adding new jokes but never iterates to ensure each is funny.
Another thing the “Comedian” movie teaches is the value of experimenting. When Seinfeld (and another comedian profiled in the film) perform, their shows contain a mix of material they know will get laughs and some new jokes they’re trying out.
Experimenting is equally important in product development. Teams can experiment with their process or the product—by delivering small, partial features to confirm their value before going all-in.
I knew agile teams need to be iterative and incremental, but this documentary taught me comedians need to also if they want to succeed at comedy,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/

Top 4 Ways to Eliminate Backlog Bloating

1. Stop putting every idea into the backlog.
2. Stop keeping things that will never happen.
3. Stop tolerating tickets with no impact or product hypothesis.
4. Stop micromanaging tickets like a project manager.

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 Best Retrospective You’re Probably Not Doing - The Introspective - Ro Fernandezhttps://medium.com/@rociofernn/the-best-retrospective-youre-probably-not-doing-e2622c1ecd12A few months ago, we kicked off a cross-functional project that had everyone excited — product, design, engineering, marketing… Energy was high. The goal was clear. At least, we thought it was.Fast forward three weeks.Things were already slipping.
Some teams were waiting on decisions that hadn’t been made.
Others were building in parallel, but with different assumptions.
And one team member quietly said in a 1:1:“I’m just not sure what success actually looks like here.”That’s when it hit me:
We hadn’t missed the retro.
We had skipped the prevention.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/

Top 5 Ways to Be Better at Giving and Receiving Praise 1. Be Specific, Not Generic

• Giving: Instead of “Good job,” say “I really appreciated how you stepped up to lead the meeting today—it brought clarity and confidence to the whole team.”
• Receiving: Acknowledge it with gratitude and, if appropriate, reflect on what specifically helped you succeed.2. Be Timely

• Giving: Praise is most powerful when it's fresh. Don’t wait for formal reviews—speak up as soon as you notice something great.
• Receiving: Respond promptly and graciously. A simple “Thank you, that means a lot” goes a long way.3. Make It Personal

• Giving: Tailor your praise to the individual’s values or effort. People are more moved when the praise shows that you see them.
• Receiving: Don’t deflect or downplay. Accept that someone noticed your contribution—own it with humility.4. Focus on Effort and Impact

• Giving: Highlight the hard work, problem-solving, or collaboration that led to success—not just the outcome.
• Receiving: Recognize your role in the bigger picture, and consider how your work helped the team.5. Practice the Praise Loop

• Giving: Create a culture where praise flows in all directions—peer to peer, manager to team, team to leader.
• Receiving: Pay it forward. When you receive sincere praise, use that as a reminder to encourage someone else.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/

Dedicated vs. Rotating Scrum MastersI spent my first five years as a Scrum Master primarily dedicated to one team. As a result, I got to know team members deeply. Even 10+ years after I left, I’m still in close contact with some of them. Due to frequent changes in the team — people come and go — improving team dynamics was a continuous effort. However, after a while, our team understood Scrum, and I could shift my focus towards the broader organization and our customers.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/

Bring Focus to Your Refinement Meetings - Mike CohnYour team is spending too much time in product backlog refinement.
How can I make such a bold claim since I didn’t participate in your most recent refinement meeting? I can make it because the vast majority of teams spend too much time refining their product backlogs.
So I’m playing the odds, and betting your team is among them.
 Teams spend too long in refinement because they misunderstand the purpose of refinement, so let’s start there. As a reminder:The purpose of backlog refinement is to ensure the highest priority items are small and sufficiently understood that they can most likely be completed within a single iteration.This means that during a refinement meeting the team does not need to get answers to every conceivable question about each backlog item. Some questions can be answered during the iteration without quashing the feasibility of finishing the backlog item in the iteration.
For example, suppose a team wants to know how long a failed transaction should be retried. Perhaps 30 seconds? A minute? Two? The product owner says she’s not sure but she’ll decide within a couple of days.
Even if the team doesn’t get that answer until after the iteration has begun, that’s fine.
The team should not need to have all questions answered or all open issues resolved before an item is brought into an iteration.
 
In this example, whatever answer the product owner provides about the retry duration will not affect the two concerns of backlog refinement:
 

• Is the item small enough to be brought into an iteration?
• Is it sufficiently understood to be completed within an iteration?

This means that the amount of time spent retrying failed transactions should not be discussed during refinement. (Actually it could warrant just the briefest discussion to confirm that the retry period is minutes—not months, because *that* difference could matter.)
From just this example we can see that some questions do not need to be discussed during refinement. Sure, the team will eventually need to know how long the product owner wants to retry transactions. But team members don’t need to know that during refinement. And they don’t even necessarily need to know it before starting work on the item.
Conversations between team members and their product owner during refinement should be focused on confirming an item is small and well understood. Discussions beyond that are often very fun, but they’re best had either during the iteration itself or possibly the sprint planning meeting.
Keeping off-topic discussions out of your refinement meetings will shorten those meetings with no adverse effect on meeting your iteration goals, which will help you succeed,The Main Reason Refinement Bogs Down Focus on the Two Concerns of Backlog Refinement 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/

10 Human-Centered Leadership Principles1. Ask for forgiveness, not permissionInnovation rarely starts with approval.
Build what you believe in — and deal with the politics later.
You will be remembered for the rules you break.2. Build teams first, then productsGood products are built by healthy teams.
Invest in trust, care, and clarity — and the product will follow.3. People and interactions over processes and toolsStolen from Agile, and still true.
Tools are only as good as the humans using them.
Build relationships before systems.4. Find a way — or build oneConstraints don’t stop creativity.
They shape it.
Be scrappy. Be resourceful. Be relentless.5. Never build what is askedDig deeper.
Understand the real need.
Then build what actually matters.6. Less talking, more buildingEndless alignment leads nowhere.
Create momentum by making things.
Then talk about what’s real.7. Live off the landUse what you have, don’t wait for ideal conditions.
Work with the terrain, not against it.
It takes knowledge, humility, and creativity.
But that’s how great work gets done.8. Everyone is a designerDesign is not a job title — it’s a mindset.
Everyone on the team shapes the experience.
So give them the tools, the trust, and the invitation to contribute.9. Good management is as little management as possible.The best leadership is invisible.
Create clarity, then get out of the way. People want clarity not transparency.
Support, don’t control.
Unblock, don’t bottleneck.10. We all have wings, but some of us don’t know whyThere’s magic in everyone.
Part of leadership is reminding people they can fly —
even if they’ve forgotten how..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/

Breaking Down The Spotify Engineering Culture ModelThe Spotify Engineering Culture Model is one of the most widely referenced frameworks for scaling Agile and creating autonomous, innovative teams. Originally popularized by Henrik Kniberg and Anders Ivarsson in their internal videos (now public), the model describes how Spotify organizes and empowers teams to deliver software at scale while maintaining a strong culture of innovation, speed, and flexibility.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/

Become A Life Changer...Do you have the power to change a life? Listen today and reveal the answer to this powerful question. 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/

Can We Do 100% Scrum And SAFe Simultaneously? - NOPE...This question emerged during a recent Scrum.org Professional Scrum Master Advanced training in Germany 🇩🇪. Some time ago, the company started an Agile transformation and hired me to learn more about Scrum and how it could benefit them.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/