Agile and Scrum Videos

Watch Mountain Goat Software videos on agile, Scrum, product ownership, estimation, planning, and teamwork.

All Videos

Transcript

By 2026, most Agile practitioners have plenty of scar tissue when it comes to estimating and planning.
I hear the same stories over and over again.
Estimates treated as promises, plans turned into contracts, teams punished for being wrong rather than rewarded for learning.
Given experiences like those, it's understandable that many teams decide the solution is to eliminate estimating and planning altogether.
I think that's a mistake.
Estimating and planning still matter.
Not because the future is predictable, but because it isn't.
They matter because teams and organizations still have to make decisions about what to work on, what delay, and what risks they're willing to accept.
In this video, I want to explain why I believe that, And what estimating planning look like when they are used responsibly.
Anytime you choose one piece of work over another, you're estimating.
You're estimated cost, value, risk, or effort, even if you never put a number on it.
I've worked with teams who proudly told me they don't estimate.
But then I watched them make decisions based on unspoken assumptions about size and difficulty.
The estimates were still there.
They were just invisible and unexamined.
And in my experience, that's worse.
The real choice isn't whether to estimate, it's whether estimates are explicit or implicit.
One of the most damaging beliefs in agile is that estimates exist to be accurate.
That framing turns every estimate into a test and every miss into failure.
In healthy agile environments, estimates exists to support decisions.
Is this worth starting?
Should we do this now or later?
What are we trading off?
So a better question than is this estimate accurate is, Is this estimate good enough to support the decision we're making?
When teams ask that question, estimation becomes far less stressful and far more useful.
I often hear people say estimates are always wrong.
They're usually frustrated, and they're not entirely wrong, but being wrong isn't the real problem.
Estimates are hypotheses.
Reality supplies the data.
I'm reminded of this every time I run a training class.
If it's a course I've taught before, I can estimate almost perfectly how long it will take me to prepare for the class, But if it's a new class,
new slides, different exercises, and new discussion prompts?
When my estimate is off, it doesn't mean estimating was pointless.
It tells me exactly what I didn't yet know.
That's how estimation works on agile teams, too.
The failure isn't being wrong.
Failure is treating estimates as promises and punishing teams when reality turns out to be more complex.
Planning is often portrayed as the opposite of agility.
In practice, the OPPOSITE is true.
Good planning aligns assumptions and intent.
It gives teams a shared starting point so they can adapt quickly when things change.
What actually reduces adaptability is planning too far ahead and over-committing to uncertain work.
I like to think of planning the way I think about planning a hike.
You don't plan because you expect the weather to behave.
Flow metrics have added valuable grounding to agile work.
They tell us how work has flowed in the past, but they struggle with novelty.
Whenever work is new or risky, historical averages become less reliable.
That's where estimation still helps.
Not to predict precisely, But to reason about what might be different this time.
Rather than choosing sides, teams are better served using both.
Flow metrics for grounding, estimation when thinking through new work.
One of the surprises I've seen is that removing planning often increases pressure on teams.
Without boundaries, work expands.
Priorities shift constantly.
Overcommitment becomes invisible.
Lightweight planning creates focus and boundaries.
It gives teams a chance at sustainable pace.
Planning isn't bureaucracy.
it's one of ways teams protect themselves from chaos.
Before estimating or planning, I encourage teams to pause and ask three questions.
What decision does this support?
What happens if we're wrong?
And who will use this information and how?
If those questions don't have clear answers, the problem usually isn't how the team is estimatin.
It's why they're estimati.
Uncertainty isn't a flaw in Agile systems.
It's the reality those systems are designed to handle.
Estimating and planning don't eliminate uncertainty.
They help teams navigate it together.
Thanks for watching.

Transcript

AI does not eliminate teams.
It increases the need for great ones.
The faster a team moves, the more collaboration the team requires.The more productive individual contributors become,the more their work needs to be coordinated.
And the powerful AI becomes as a tool, The more dangerous it is when someone uses it in isolation.
Put simply, AI amplifies everything, including misalignment.
Unfortunately, many teams are responding to AI by collaborating less, and that is where things begin to fall apart.
Over the last few years, I've watched teams adopt AI tools in ways that unintentionally reduce communication.
Developers can now accomplish huge amounts of work on their own.
Product owners can use AI to generate and split backlog items, or even prioritize entire roadmaps.
teams start to believe they no longer need to talk as often because the tools are doing so much of the work.
The theory goes, if AI can generate stories, code, and tests, perhaps the team can get by with fewer discussions.
the reality is very different.
I've seen teams that, excited by AI's efficiency, quietly slip into working as a collection of individuals rather than as cohesive unit.
They may hold the same meetings, but the communication within those meetings becomes thin and surface level.
Outside the meetings collaboration dwindles even further.
AI is not just speeding up development.
It's reshaping what the key roles inside Agile teams actually do.
These changes are significant, and understanding them helps us understand why collaboration remains so important.
Product owners may be the biggest beneficiaries of AI in the short term.
AI can help them write backlog items, generate acceptance criteria, analyze customer sentiment, summarize research, even propose priorities.
For a role that has always struggled with having enough time to do the job, this is a welcome change.
But with that support comes temptation.
It becomes too easy to delegate too much thinking to an AI.
A product owner who lets AI drive backlog prioritization or roadmap decisions risks drifting away from customer needs, business realities,
and strategic intent.
AI can assist, but it cannot own core decisions such as product vision, market positioning, customer segmentation, or business models.
I've seen product owners who let the AI do most of the heavy lifting only to discover later that the product had wandered off course.
It's an example of how AI could be a powerful assistant but a poor navigator.
For years, I've believed the Scrum Master role would inevitably shift as teams became more experienced.
As a team becomes proficient with Sc rum, team members absorb some of the responsibilities of a Scum Master.
AI is accelerating that shift.
The future Scrum Master is less of a process guardian and more of human dynamics expert.
They will likely work across multiple teams, operate part-time on any single one, and spend far less energy worrying about prescriptive frameworks.
Instead, they will focus on helping people work well together, asking tough questions, facilitating constructive disagreements,
guiding the team through difficult decisions.
These human-centric skills will define the role.
Scrum Masters and Agile coaches who cling to checklists and frameworks will become less effective.
Those who cultivate emotional intelligence, facilitation skills, and the ability to coach collaboration will be essential.
I've seen Scum Masters who remain overly focused on rituals and mechanics while their teams quietly slide into dysfunctional communication patterns.
In an AI-driven world, that approach won't work.
Developers have also experienced extraordinary leaps in productivity.
AI helps them generate code, uncover bugs, explore architectural patterns, and write tests.
This enables them to accomplish far more in less time.
And with that increased capacity comes a shift in team design.
Many products that previously required teams of eight might now effectively be built by teams four or five.
This shift also changes how teams think about specialization.
We will still need world-class experts for highly specialized problems, but many teams will rely on strong generalists who possess broad skills and deep
AI fluency.
It also means that developers, moving faster than ever, must communicate more frequently to avoid stepping on each other's work.
AI accelerates their capabilities.
Human alignment ensures those capabilities don't create chaos.
All of these changes point toward a future where agile teams look different than they did even a few years ago.
I expect teams to become smaller and more fluid.
In many organizations, team membership will include a stable core supplemented by temporary specialists who join for a couple of weeks or months to work
on highly complex tasks before moving on.
Teams will also continue to become more globally distributed, though work from anywhere of movement has only strengthened,
and AI will make collaboration across time zones even easier.
Yet, despite these changes, the definition of a team should remain simple.
A team is a group of identifiable people pursuing a shared goal.
That definition still holds, even when membership becomes more fluid.
As AI lowers the cost of experimentation, teams will attempt more ideas, pursue more niche products, and pivot more quickly.
This makes leadership more, not less, important.
Leaders must provide direction, so experimentation does not devolve into chaos.
Leaders set strategic intent, define boundaries, and articulate a North Star that teams can use as an anchor.
Since AI accelerates work, the practices that hold teams together become even more essential.
The Sprint Review is one of them.
As AI speeds up delivery, ensuring alignment between what the team builds and what stakeholders expect becomes absolutely critical.
Only through real human feedback and the interpretation of that feedback can teams ensure that AI-accelerated work remains on target.
Backlog refinement is another practice that must remain human-led.
AI can draft backlog items or propose ways to split stories.
But only humans can decide if those items contain the appropriate amount of detail, whether the intent is right, and whether each aligns with the product vision.
Daily communication becomes essential as teams move faster.
That communication doesn't need to be in a formal meeting.
Many teams will choose asynchronous check-ins rather than a traditional daily scrum, but the keys are frequency and consistency.
When a team can build features in hours, they need talk about what they're doing more often, not less.
Iteration planning is similarly indispensable.
Even if AI assists in forecasting, the team must align on intent and understand how their work fits together.
Planning keeps the teams grounded in shared understanding.
The common thread is simple.
AI accelerates work.
Collaboration prevents accelerated mistakes.
Teams that reduce collaboration as AI usage increases will eventually undermine the very speed they're trying to gain.
Leaders often ask how they'll know whether AI is helping or hurting their teams.
The answer doesn't require a dashboard full of metrics.
It comes down to this simple question.
Are team members communicating more frequently than they did before AI?
If communication is decreasing, collaboration is weakening, and teams are heading into danger.
the faster the team moves, the more essential communication becomes.

Transcript

Product backlog refinement is one of the most misunderstood activities in Scrum.
Many teams struggle with how much detail is enough before bringing a backlog item into a sprint.
Some teams barely refine at all.
Others over-refine and waste time eliminating uncertainty that doesn't matter.
The goal of product backlog refinement is not to eliminate uncertainty.
It's to build enough confidence to make a responsible commitment.
Refinement is about developing enough shared understanding that the team can reasonably believe a backlog item can be completed within a sprint.
That's the goal.
Here's the question I use.
Do we know enough to believe this item can probably be completed within a sprint?
I don't use, have we answered every possible question?
Or have finalized every design decision?
Just, do we have enough understanding to commit responsibly?
If the answer is yes, stop refining.
If answer's no, identify the biggest unknowns and resolve them before bringing the item into the sprint.
I think of refinement in three zones.
On one end, you have items that are too vague.
There are major unanswered questions.
The team can't responsibly bring them into the sprint because the scope could explode once work begins.
When teams pull items from this zone, they're uneasy.
You can see it.
People hedge.
They add buffers.
they commit without confidence.
On the other end, you have items that are over-refined.
The team is trying to eliminate every uncertainty.
They're refining work sprints ahead of time.
There are debating design details that may change once work starts.
In this zone, the team solving problems that never matter.
In the middle is the refinement zone.
That's where you want your items.
Enough clarity to fit in a sprint.
Major risks addressed.
Minor unknowns still present, but manageable.
There are still questions, But no one feels anxious about committing.
The goal is not to push items as far right as possible.
the goal Is to move them into that refignment zone and then stop.
Let me give you an example.
I worked with a team building a bioinformatics application with some fairly intense 3D visualizations.
One backlog item depended on how much data the system needed to support.
If the data size was under a certain threshold, the team could use an existing commercial visualization package.
if it was above that threshold the, team would need to develop their own.
That would make the story much larger.
During refinement, the product owner could not clarify the data size requirement.
That uncertainty mattered.
It could dramatically change the scope.
So the team chose not to bring the item into the sprint.
If that was the right call, they identified a sprint-threatening unknown and resolved it before later committing.
that's refignment working the way it should.
Now consider another common mistake.
Many teams think backlog refinement means making the entire backlog detailed and ready.
A healthy backlog doesn't work that way.
It should have a gradient of clarity.
items near the top, the ones you're likely to work on soon, should be clear and reasonably detailed.
items further down should less detailed, they might be nothing more than a sentence or two.
Leaving lower priority items vague is often the disciplined choice.
If you fully refine backlog items far ahead of when you'll work on them, you're investing effort in work that may change,
move, or disappear.
Focus your refinement effort where it matters most, at the top of the backlog.
There's also a simple way to diagnose whether refinement is working.
Look at what happens during sprint planning.
If during that meeting, team members are still unclear on what a story means or if they frequently need to split stories or they decide there are major unknowns,
that suggests refignment wasn't done well.
Poor refinement leads to longer sprint planning, which leads frustration and disengagement.
And over time, trust between the product owner and the team erodes.
Refinement isn't just about efficiency.
It's about predictability and trust.
I often say I don't want a team hitting its sprint goal 100% of the time.
A team that achieves its spring goal every sprint is probably playing it safe, picking easy goals.
But I also don' t want the team to miss the goal most of time If a team achieves its sprint goal around 60% to 80% of the time,
that tells me they're stretching but being realistic.
Well-refined backlog items make that possible.
One final caution.
Don't let refinement turn into a design meeting.
Design discussions are necessary, but refinement has a specific job.
It's about clarifying boundaries.
What's included, what's not included?
What assumptions are we making?
what could dramatically increase scope?
If the team can answer those questions and reasonably believe the item will fit within a sprint, refignment is done.
Design can continue during the sprint.
So if refinement feels heavy, try this.
Refine less.
Stop refining when the team knows the item will fit in a sprint.
Refinement is about smoothing the road so the teams can move quickly without avoidable surprises.
You don't need certainty.
you just need enough confidence to commit.
If you'd like a practical tool to help your team to decide when an item is refined enough, I've created a checklist and written a full guide.
You'll find links in the description.
And I'm curious, what does refinement look like on your Team right now?
Does it feel rushed, overdone, just right?
Let me know in comments.

Transcript

A key agile principle is the value of getting planned work done each iteration.
Yet many agile and scrum teams fall into the habit of letting unfinished work spill over every iteration Spillover is when planned work,
such as a product backlog item or story, is left unfinished at the end of an iteration and is carried over into the next iteration.
Spilover occurs for one of three reasons.
An overly ambitious sprint goal, too much unplanned work or underestimating the effort required to complete the work.
Occasional unfinished work is not a bad thing.
In fact, it's normal and desirable to occasionally aim a little high in an iteration, come up short.
Too many spillovers, however, can reduce predictability, diminish creativity, harm morale, and threaten project timelines.
Before I get into why spillover happens and what to do about it, I want to make this point.
A sprint goal is a commitment, not a guarantee.
Commitment is the promise to try to achieve a goal.
Sometimes we do need to guarantee, such as when a client or customer needs some capability or fixed scope by a certain date.
In these cases, to ensure they meet that guarantee a team would likely cut back on other work and set a less ambitious sprint.
In general, though, a team should not be forced into a guarantee.
Instead, the team be allowed to commit to something reasonable with leaders, understanding the difference between a commitment and a guaranteed.
By the way, my name is Mike Cohn, and I'm the author of three bestselling books on Agile and Scrum.
I help teams succeed with Agil.
Missing on occasion is not a problem.
Habitual spillover is different.
A habitual spill over is when a team carries work forward on a routine basis.
With habitual spillover, the end of an iteration becomes an arbitrary date.
and unfinished stories are just carried over into the next iteration as though it's no big deal.
Frequently spilling over unfinished story to the the iteration is a big for two main reasons.
It decreases predictability and it harms morale.
The main problem with habitual spillover is a lack of predictability and dependability.
Every organization benefits from some degree of predictable.
Predictability shouldn't be the primary goal, but it should be a goal.
When your team is predictable, stakeholders will trust you and your work.
There will be less second guessing and micromanaging.
So this trust benefits everyone.
But don't worry, you don' have to be perfect to predictable 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 depended on to makes most of their free throws.
Baseball player also strive get a hit every time they're at bat.
They're considered great, highly predictable hitters if they manage to hit about 35% percent of time.
Like those sports players, agile teams are expected to try to deliver everything they think they can every time.
But if an agile team delivers their goal 60 to 80% of the time, they're highly predictable teams.
A second related reason teams need to finish what they start most of time has to do with the power of small wins.
In a 2011 study, Amabile and Kramer found that the frequency of small wins is an important factor in creativity and people's enjoyment of work.
Successfully finishing the work of an iteration or achieving a sprint goal is a small win.
Getting close to done is not a big win!
So why do some teams routinely try to deliver more value than they can reasonably expect to delivery?
The most common source of this bad habit is pressure.
That pressure can originate from one of two places, external or internal.
External pressure can come from leadership, various stakeholders, or from any outside source.
An executive or stakeholder can exert pressure by establishing unrealistic expectations in terms of budget or scope.
Sometimes this leadership pressure is well-intentioned.
A leader gets excited about the opportunities presented by a product and wants more, Or they want to produce value faster because of the good it will do
to the company or the product's users.
More commonly, pressure comes from misguided leaders who think pressure is an appropriate way to motivate teams.
In other cases, overcommitment happens because of internal pressure.
Pressure team members put on themselves.
Some teams allow their optimism and high expectations of themselves to create pressure to do more than is reasonable.
Whether pressure to overcommit comes from outside or inside, it's neither a healthy environment for team members nor a good situation for the organization.
Remember, we want to stop habitual spillover, not all spill over.
Sometimes teams miss their goals when they aim high and fall a little short.
Don't try to fix that kind of effort, celebrate it.
Other times, teams missed because they just hit a run of bad luck for a handful of iterations.
Again, no need to intervene there.
But when unfinished work spills over from iteration to iteration too frequently, here are three things you can do to help.
One thing you could do right away to stop habitual spillover is to share data on how prevalent spill over is.
At the end of an iteration, note the percentage of product backlog items that are unfinished.
If you can, look back at a handful of additional iterations and do the same for those.
Bring this information to the next retrospective and ask team members why they think unfinished work has become a habit.
Walk them through exercises designed to uncover the root cause of a problem, such as five whys.
Then invite team members to discuss options and identify one thing they could try next iteration to alleviate that root cause.
Encourage team member to hold themselves accountable for actually trying that one things during the next iterations.
Incomplete work in the form of unfinished product backlog items is often caused by an overabundance of optimism.
A team plans an iteration as a best-case scenario and pulls more work from their product back log than they can achieve.
If that sounds familiar, in your next iteration planning meeting, try asking questions like these.
What has to go right to achieve this goal?
And what could go wrong that could cause us to miss our goal.
That might be unplanned work, a backlog item becoming bigger than expected, unforeseen scenarios such as critical bugs, integration issues,
and so on.
These questions can help uncover any risky assumptions about the work the team is about to bring into the iteration.
Think of it as a premortem for the Iteration.
If you're a scrum master and nothing you've tried can get your team to break their spillover habit, in the next sprint planning meeting,
encourage your teams to truly under commit in relation to their team capacity.
I'm not talking about cutting the sprint goal by some small amount like 10 or 20%. You want to reduce the amount of work they commit to so dramatically
that they are guaranteed to finally achieve everything they say they will.
The team will probably push back on this.
They're used to filling up their sprint and will be optimistic that they can get more done than the items they've chosen.
But their history shows they won't.
Scrum Masters should hold firm, reminding team members that if they run out of work, they could always bring more in.
Scrum Masters will 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
less work into the sprint, but with a goal of finishing everything for a change.
The goal in undercommitting is to let everyone on the Team, including the Product Owner, feel what it's like to add work rather than always spilling work
forward into next iteration.
After they do, they'll likely want to feel that way again.
Once the team has felt the joy of no spillover, the Scrum Master should encourage team members to plan a bit more work into the next iterations until they
get close to having to roll over in Complete Stories again.
Habitual spillover can be a hard habit to break.
Agile teams need to perform their best while also allowing the organization to create reliable plans.
To do that, you want a team that knows its capacity and at the same time isn't afraid to try hard things.
You also need a product owner and stakeholders who understand that an ambitious team will not accomplish its goal every iteration,
and that understands the difference between a commitment and a guarantee.
Old habits die hard.
Sometimes you have to take drastic action to realize lasting results.
The key to breaking the spillover habit is continuous improvement.
And that starts with better retrospectives.
Right now, you can get two brand new on-demand video courses, Better Retrospectives and Retrospectives Repair Guide for the price of one.
the offer expires at 9 p.m.
Pacific on Thursday, April 17th.
Don't let this opportunity spill over.
Click the link here or in the description.
Thanks for watching and I'll see you in next video.
The key to breaking this spillover habit is continuous improvement, and that starts with better retrospectives.
Follow the links here for a special half-price offer on two on-demand courses, Better Retrospectives and Retrospectives Repair Guide.
Thank you for watch and see in you the next one.

Transcript

It's unrealistic to insist a team finish everything they start, every sprint.
If you do, most teams will respond by very conservatively planning their sprints so they can finish every thing.
But when a teams consistently fails to finish everthing, the end of a sprint becomes an arbitrary, meaningless date.
It arrives and team members just move work forward into the next sprint, no big deal, they think.
You want your team to instead think of the end of a sprint as significant.
Each time they finish what they said they would, they gain a little more trust from the business stakeholders.
That trust translates into an improved relationship.
Hi, I'm Mike Cohn, and I am the author of three best-selling books on Agile and Scrum.
I help teams succeed with Agil.
To solve the problem of letting work carry forward, you need to break the team's habit of over-committing.
Have them commit to what seems ridiculously easy in the next sprint, then add to it later if it becomes clear they'll finish.
In this way, they'll feel what it's like to over deliver rather than to continually under deliver on what they said.
Don't forget to subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching and I'll see you next time.

Transcript

Can you do Scrum without a Product Owner? To answer that, remember that a product owner establishes the vision for the product, gets others bought into that vision, and creates, maintains and prioritizes a project backlog that will achieve the project goal. In short, the Product owner decides what the team will work on and in what order. If a team is not given a product owner, someone will inevitably step up to fill that role. Someone will say, I guess we should start by building such and such. And this person has just become the productowner, at least until that thing has been built and someone else decides what the team should work on next. These people filling the void left when there is no product oner are not necessarily the best at deciding what they team work, but atleast they're helping by giving the direction. So, can you do Scrum without a Product Owner? Not really, since someone will inevitably fulfill at least the essential duties of the Product owner.

Transcript

If you want your team to behave a certain way, you need to reward those behaviors.
U.S.
President Theodore Roosevelt knew this when he created Arbor Day as a new holiday in 1907. Arber Day is not much of a party holiday.
There's no green beer, no free-flowing margaritas, not hot dogs on the grill, and no big family gatherings.
But it is a holiday meant to celebrate the importance of trees.
President Roosevelt knew that if we celebrated trees, people would plant more of them.
This sentiment was echoed 100 years later by Frank Blake, CEO of Home Depot, who said, you get what you celebrate.
Blake wanted to improve customer service in his stores.
He knew celebrating examples of great customer services would help.
What do you celebrating in your organization?
Early in my career, our CTO celebrated people who put in extra effort.
He celebrated those who worked late into the night.
I remember one all-hands meeting where he praised one of my coworkers for his extraordinary effort fixing a major bug.
The CTO didn't know that this programmer had also caused the bug.
The rest of the team had embraced a quality-first mindset and had adopted practices to support that.
This programmer resisted those practices, caused a bug, and was then praised by the Cto.
You get what you celebrate.
Here are a few things to celebrate that can help encourage better teamwork.
Someone trying something they've been resistant to.
Starting work on backlog items without resolving every open issue first.
A well-run retrospective.
This is on my mind as I watched Brian Milner, our SVP of Training and Coaching, run an excellent retrospect of this week.
celebrate someone who spoke up more or less during a meeting, celebrate a team disagreement that was resolved productively,
or a decision that worked out, Celebrate a Decision that did not work out but still seems like it was the right decision.
Celebrating team members who go out of their way to help, Or celebrate achieving a sprint or product goal.
Because you'll get what you celebrate, be sure you Celebrated behavior that makes your team better.

Transcript

Last week, a client mentioned they were using feedback they'd received on a minimum viable product to make course corrections.
My ears bristle whenever someone talks about correcting course on an Agile project.
There's no such thing as course correcting in Agiles.
Am I crazy?
After all, the fundamental part of Agil is acting on feedback to improve a product.
My problem with the concept of course corrections is the way it presupposes there is one correct course and that it's possible to know that course in advance.
That's not the case.
Sure, many products begin with a product backlog that describes what the product owner thinks will be the right combination of features to achieve desired outcomes.
But on any non-trivial product, this recipe cannot be fully known in advanced.
Successful products are created by iteratively homing in on the right combination of features.
And that set of futures can only be discovered through trial and error.
No matter how much research a team does before developing a feature, they never know how users will respond to the new feature.
Will users love it?
Will they hate it, will they use it as intended?
So a product owner or manager places a sequence of bets.
The result of each bet guides the product owner in placing the next bet.
Course correcting means there was a single correct course.
It implies that development has somehow deviated from this corrects course and must be brought back in line.
Instead of talking about course corrections, I talk about Course Adjustments.
As a team learns more, it adjusts Course rather than correct Course.
If you found this video helpful, please do me a favor and hit the like button.
It really does help YouTube know to show the video to others.
And click the subscribe button if you'd like to be notified of future tips.
Thanks for watching, and I'll see you next time.

Transcript

I recently posted something saying that frameworks enhance creativity.
I was told I'm wrong.
Let's use William Shakespeare, the TV show Friends, and Wiley Coyote and the Roadrunner as examples of frameworks enhancing creativity!
In addition to all his plays, William wrote 154 sonnets.
Each sonnet had to follow a strict rhyming scheme.
The first and third lines need to rhyme, so do the second and fourth.
Shakespeare's most famous son is number 18. You've almost certainly heard at least the opening line, Shall I compare thee to a summer's day?
That needs to rhyme with line three, Rough winds do shake the darling buds of May.
This pattern of rhyming alternating lines repeats for three sets of four lines.
After that, the last two lines have to rhyme, without a line between them.
A poet like Shakespeare has to work within this framework.
The constraints of a sonnet forces poets to get creative and find rhymes that help say what they want to say.
Each episode of Friends followed a structure.
That framework constrained each episode to be told in three acts.
Act 1 establishes the main characters and their goals.
ACT 2 raises the stakes for the characters.
The conflict escalates.
And then in Act 3, the story is resolved.
Think about the episode in which Chandler and Joey fight over who gets to sit in the comfy chair.
Act 1 introduces that situation.
In Act 2, they become increasingly and ridiculously stubborn about who get to seat in comfy chairs.
Finally, the situation is resolved when Joey gets out of the comfortable chair Essentially, all TV shows, movies, plays,
novels, comic books, and more follow the same storytelling framework and its constraints.
My favorite framework involves Wiley Coyote.
Chuck Jones, the creator of the cartoon, established nine rules he forced himself to follow with each episode.
Those rules include that the roadrunner cannot harm the coyote except by going beep beep.
No outside force can harm the Coyote, only his own ineptitude or the failure of the Acme products.
No dialogue ever except beep beep.
And whenever possible, make gravity the coyote's greatest enemy.
You can see the full list in the description.
By forcing these constraints on himself, Chuck Jones created an enduring masterpiece of cartoons.
Agile and frameworks such as Scrum put constraints on teams using them.
Scum teams, for example, are constrained by needing to find a way to fully implement features, even if very small within each sprint.
Agile teams are generally constrained by how big they're allowed to become.
A team of seven given a significant challenge in objective will have to get creative in how they achieve that goal.
a team that knows it can always just add more team members is freed of that constraint and will not be as creative and how to achieve their goal I'm not
alone in thinking this way.
In 2015, Adam Morgan and Mark Barden wrote a book, A Beautiful Constraint.
And it they share scientific research into the psychology of breakthrough.
They share stories of how a lack of time, money, resources, attention, or even know-how can be turned into advantages when coming up with creative solutions
to problems.
Next time you find yourself frustrated by a constraint, whether on an Agile project at work or in life, see if you can use it as a boost to finding an
innovative solution.

Transcript

You're probably doing your daily scrums wrong.
If you're asking each team member to give an update on their progress, plans, and problems, there is a better way.
Hi, I'm Mike Cohn, the author of three best-selling books on Agile and Scrum.
I help teams succeed with Agil.
And I want to help you too.
Today I am going to tell you how to get team members more engaged in their daily scrums, how to learn more about each other's work,
and how more easily to notice if a product backlog item is going off the rails and needs attention.
Most daily scrums are conducted person by person, often still with the three traditional but no longer required questions of the daily Scrum.
What they did yesterday, what they'll do today, or what if anything is in the way.
After each person gives their update, the next person give their full update.
This is a very natural way to do a meeting.
One by one each says what they have to say.
A problem with this approach is that each speaks only once.
After I give my update I'm done.
I may not say anything else the entire rest of the meeting, In fact, a rule of no problem solving during the daily scrum encourages me to remain silent
after giving my update.
There's no rule that says you have to do it this way.
For most teams, I found a better approach is to go backlog item by backlog.
The scrumm master, or whoever is facilitating the meeting, calls out a first product backlog and asks who worked on this item yesterday.
Anyone who did states what they did yesterday, The facilitator then says, great, and who will work on it today?
Anyone who plans to work in that item today shares what they plan to accomplish.
Finally, the scrum master or facilitators asks, is anything holding anyone back on this item?
Team members answer, then the facilitater repeats this process on the next product backlog item.
I want to highlight a couple of benefits to this approach.
First, team members are likely to talk more than once.
Suppose I'm heavily involved in one product backlog item, but also doing a few little things on a second item.
I will talk twice during the meeting as each item is discussed.
In the traditional person-by-person approach, I would give the same update, But I do it all at once Second, it's much easier to understand which backlog
items are being worked on.
Imagine a team that has brought 10 items into their sprint.
The team should be working on perhaps two to four of those at any time.
If you run the meeting item by item and team members give updates on all 10 item in the sprint, that's a problem.
It's too much work in process.
Doing the meeting item by item makes this much more obvious than if you do the meaning person by person.
Third, it's easier to gauge what work will be completed in the sprint.
If three or four people each give an update on a given item, that item will probably be finished in this sprint, or at least the team is trying to finish it.
On the other hand, if no one mentions a particular item and you're nearing the end of the Sprint, you can start to think that one item won't be finish.
Fourth, the number of people who talk about any item indicates the degree to which team members are collaborating.
If only one team member comments on each item, there isn't a lot of collaboration occurring.
This can help the Scrum Master notice a problem sooner.
I think doing daily Scrum meetings person by person is a legacy of the old status meetings many team members will have participated in during their pre-Agile days.
In those meetings, a manager would ask each person to provide an update.
And so when teams move to Agile, they start by doing Daily Scums the same way.
It's a natural way to do the meeting.
And it can be very efficient.
Each person can provide their complete update all at once.
So for some teams, going person by person may be best.
But in my experience, a lot of teams benefit from going item by item.
I suggest mixing it up.
Do this sprint item-by-item, then next sprint person- by-person.
See how it goes.
You might find one approach is best for you.
Or you might find it's good to keep Daily Scrums fresh by changing the approach now and then.
How do you conduct Daily Scrums?
Is it one of these approaches?
Let me know in the comments how you do Daily scrums and what you think is best.
I read and appreciate every comment.
Also, if this video has been useful, click the like button.
And if you're new to this channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.

Transcript

Some people just won't shut up.
Maybe they're nervous about something, so they talk.
maybe they think everyone wants to hear their every thought.
May be they are not even aware they talking so much.
But talking too much can be a huge problem, especially in a meeting with a short time box such as the daily Scrum.
Let's see what you can do about it.
Hi, I'm Mike Cohn and I am the author of three best selling books on Agile and Scum.
I help teams succeed with Agil and want to help you too.
A common solution to an overly talkative team member is for someone to start a one-minute timer as each person begins to give their update during the Daily Scrum.
This is okay, but I find it often forces a team to finish too quickly.
Someone's update would often benefit from taking two or three minutes.
That's discouraged, though, with a 1-min timer on each member.
A scrum master, Kaylee, taught me our second technique.
As each person gives an update, they hold a three kilogram, about six and a half pound, medicine ball straight out in front of them.
The ball isn't very heavy, but holding it straight in from of you will get harder the longer you talk.
What I love about this technique is that it gets harder, the more you go.
That makes it highly effective.
Here's a third tip for dealing with an overly talkative team member.
Interrupt them, especially if you're the scrum master or coach.
We hesitate to interrupt because we think that would be rude.
Instead, what's rude is that person monopolizing the meeting with their soliloquy.
If someone is truly rambling on, the scrum master, or really anyone on the team, needs to interupt that personally.
Otherwise, it's rudely to everyone else in the meetings.
Here's a good way to interrupt politely.
Tell the speaker that it seems like they have something more to say on this topic.
Then add that everyone needs a chance to give their update within the prescribed 15-minute time box.
Finally, offer to come back to the loquacious speaker after everyone has had a change to share.
Some teams use the well-known idea of a parking lot for such topics.
Just announce that you're adding that item to parking a lot and we'll come to it after every one provides an update.
Other teams get a little bit more into the agile spirit of things and will refer to the parking lot as the 16th minute.
If you find it hard to interrupt someone, here's a technique that will help.
Instead of actually interrupting the person, give team members a way of politely signaling the people that they've gone on too long.
Think about Academy Award acceptance speeches.
Talk too long and the orchestra starts playing.
Keep talking and they play louder.
A fun way to achieve the same effect is with Elmo, the Sesame Street character.
Then use his name as an acronym, enough, let's move on.
If you're all in person, buy a stuffed Elmo and have it in your meeting room.
Anyone can hold up the stuffed elmo if they think someone is rambling.
It works even better for video meetings.
Encourage everyone to find their favorite Elmo background and pull it up when someone talks too long.
Daily scrums are meant to be brisk, fast-paced meetings I don't want a typical team to finish in five minutes.
That's almost certainly too short for anything meaningful to have been discussed or shared.
But I also don't want the meeting to go too long, and I certainly don' t want one person to monopolize the conversation.
How have you managed to prevent a team member from going on too-long during your daily stand-ups?
I'd love to hear from you in the comments section.
If this video has been useful, click the Like button.
And if you're new to this channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching and I'll see you next time.

Transcript

Let's talk about not talking.
How do you get someone to speak up in a meeting?
I'm thinking about daily stand-up meetings in particular.
I don't mind if someone is silent in the meeting when they don' have anything to contribute.
That's fine.
And it's to be commended over the behavior of someone who feels compelled to chime in on everything.
But being silent on a daily standard is a problem because each person is expected to contibute.
Hi, I'm Mike Cohn and I am the author of three best-selling books on Agile and Scrum.
I help teams succeed with Agil and want to help you too.
For years, daily stand-ups or daily Scum meetings followed the same format.
Each participant was expected to say what they had done since the prior meeting, what to do before the next meeting and to describe anything impeding their progress.
Those three items represented a person's progress, plans, and problems.
These three are no longer required of a Scrum team in its daily scrums, but they remain a good default option for most teams in what should be covered
during the meeting.
But what should you do if you're a scrum master or a coach with team members who give an update but don't say anything meaningful?
Something like, yesterday I worked on a few tasks, today I'll work on few task, no blockers.
I've heard essentially that too many times to count and it's worthless.
When someone gives you an update like this, you need to push them on specifics.
If they merely say that they worked on some tasks, have them name the specific tasks.
Or if you're physically together with a task board or a Kanban, had them point to the specifically rows or cards.
Additionally, ask people who give vague updates one question at a time.
If your team follows the convention of talking about progress, plans, and problems, Ask first, just about Progress.
Don't let this person tell you about all three aspects of their work.
If they start shifting into plans or problems, bring them back to progress first.
Say something like, that's great, and we'll all want to hear more in a minute about your plan for today.
But which specific tasks did you work on yesterday?
Bring them to that one topic.
Often someone who gives a vague update, like saying they worked on some tasks, is an introvert.
And I can relate, so am I.
But something worth knowing about introverts is that while we may dread small talk, most of us are OK with structured conversations.
So reinforce the structure of these meetings.
If you want people to cover progress, plans, and problems, emphasize that structure by asking about each intern.
I'm actually not a big fan of a scrum master or coach calling on people and asking questions in this way.
i'd prefer to let a team self-organize in how they go about the meeting.
But with quiet individuals, bring back some structure.
It will help the introverts on the team.
Another way to add structure to the meeting is to have people give their updates in a known order.
And consider having the quiet, vague team members go first.
Or you may even go yourself.
Yes, I think scrum masters and coaches should give updates too.
A good way to do that is to start with something like, OK, let's hear from AJ first and then Astrid, but I'll start us out.
Then give your update, which gives the person or two you named a chance to mentally prepare their update.
Why do I like to start with the folks who give vague updates?
Because otherwise they're nervous throughout the meeting that they'll be called on next.
It's better to let them know when they go.
And by you going first, it gives them a moment to collect their thoughts.
Another step you can take is to reinforce the purpose of daily stand-up meetings.
They aren't to micromanage a team.
There aren´t status meetings designed to check up on people.
Their synchronization meetings, team members are synchronizing effort to make sure nothing important is being overlooked or two people aren�t doing the
same thing without being aware of each other.
When people know the purpose of a meeting, they're more likely to understand why they are being asked to participate by giving an update.
Do you have team members who give vague noncommittal updates?
How have you handled the situation?
Let us know in the comments.
If this video has been useful, click the like button.
And if you're new to the channel, subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time.