goodpods headphones icon

To access all our features

Open the Goodpods app
Close icon

Agile Coaches' Corner

Dan Neumann at AgileThought

Agile Coaches' Corner shares practical concepts in an approachable way. It is for agile practitioners and business leaders seeking expert advice on improving the way they work to achieve their desired outcomes.
share icon
not bookmarked icon

All episodes

Best episodes

Top 10 Agile Coaches' Corner Episodes

Best episodes ranked by Goodpods Users most listened

In this episode, Professional Scrum Trainer Eric Landes addresses the questions: "Will the Professional Scrum Master Certification help me get a job as a Scrum Master?"

The Professional Scrum Master certification Bolsters your Credentials

Of course there is no guarantee of a job with a certification, but I believe it helps you have the intelligent conversations around scrum when you have the background from passing a certification in the Scrum framework. If you are already working in IT, one way to do bolster your chances for a job would be to take the class and go for the certification. Then in your current job, use Scrum with your team, at any opportunity you have.

Get Experience in the Scrum Master Role

If you can volunteer for other teams within your organization. This will help you get experience with the concepts. Then you are positioned to be a Scrum Master in your current organization should the opportunity present itself. Having the certification helps, and get as much experience as you can as you attempt to become a full time scrum master.

Want to Learn More or Get in Touch?

Register for our upcoming web meetings by visiting

See available training courses at

Visit the website and catch up with all the episodes at!

Email your thoughts or suggestions to or Tweet @AgileThought using #AgileThoughtPodcast!

plus icon
share episode
episode art

07/24/20 • 27 min

This week, Dan Neumann is joined by his AgileThought Colleague, Quincy Jordan!

In their conversation today, Dan and Quincy are diving into the world of online videogames — specifically Fortnite; the popular battle royale, sandbox game — and drawing comparisons between it and agility.

Having watched his son play Fortnite over the summer, Quincy saw how he remotely communicated with his friends online to come together as a team, seek out an objective, collaborate, and go after that goal. In this episode, Quincy not only highlights many of the similarities between online gaming and having an agile mindset, but he also shares some of what we (and our kids) can learn from playing these sorts of games and further improve our agility.

Key Takeaways

The overlap between an agile mindset and Fortnite/other online games:

In the game, you play in teams and the players coordinate and collaborate remotely through headsets

In both agile teams and Fortnite, you need to come together as a team, seek out an objective, collaborate, and go after that goal

In the game, you gather raw materials and architect right on the spot to create structures such as barriers or ramps (similar to the agile concept of solving problems with the resources you have at your disposal)

They do team working agreements (i.e. before they start, they set out their goals and agree on what they’re trying to achieve)

When their objective is at risk of reaching its goal (similar to a sprint goal), they reevaluate quickly, make adjustments, stay adaptable, and continue without losing sight of the goal

What Fortnite/other online games can teach us about having an agile mindset:

The team collaboration in Fortnite emphasizes teamwork and shows how having ‘hero complex’ does not get you to your goal (you have to work together, one person cannot do everything)

In Fortnite, your character can lose energy and need time to recuperate. In this scenario, a teammate will ask another for help to spot them as they recover, which is very similar to how high-performing agile teams should behave (i.e. being transparent with one another if you need help)

There’s a collective recognition that you win and lose as a team

The teams in Fortnite are self-organized and not afraid to take risks and fail fast — this is key to growth

They always stay focused on the overall objective, which is a crucial mindset piece for agile teams to have

Mentioned in this Episode:




The Decision: Overcoming Today’s BS for Tomorrow’s Success, by Kevin Hart

Quincy Jordan’s Book Pick:

Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs, by John Doerr

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on!

Email your thoughts or suggestions to or Tweet @AgileThought using #AgileThoughtPodcast!

plus icon
share episode
episode art

07/21/20 • 4 min

In this episode, Professional Scrum Trainer Sam Falco answers the question: "Why do you say that Sprint Zero is an anti-pattern?"

Why do you say that Sprint Zero is an anti-pattern?

“Sprint Zero” is a label applied to the indeterminate period of time used to gather product requirements and analyze them before a Scrum Team can start developing the product. Although “Sprint Zero” appropriates a Scrum term, it isn’t part of Scrum, nor is it a Complementary Practice that enhances Scrum. Sprint Zero undermines Scrum and agility.

Sprint Zero isn’t a Sprint

The Scrum Guide tells us that “The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created.”

That’s enough on its own to dispel the idea that Sprint Zero is a good Scrum practice. Sprint Zero rarely has a timebox— I have seen organizations where Sprint Zero lasted for months—and no potentially releasable product is produced by it.

Sprint Zero inverts agile values

The purpose of Sprint Zero is to generate comprehensive documentation. The practice rests on the false belief that we can and should understand and predict all of a product’s requirements before we start building. We often use the phrase “gather requirements,” as if they are some harvestable commodity. For complex efforts like software development, nothing could be farther from the truth. Requirements emerge as we build and are often obvious only in hindsight. Spending time trying to predict them is wasteful.

Not only does Sprint Zero value comprehensive documentation over working software, it values contract negotiation over customer collaboration. The implicit promise of Sprint Zero is that once we have defined and analyzed our requirements, we can arrive at an agreement about scope and no further interaction with customers will be necessary until the product is completed. By attempting to define scope up front, we miss out on the value of working with the customer over the course of the development effort to ensure that the customers true needs are met.

Sprint Zero undermines agile principles

It delays the beginning of product development—so forget about satisfying the customer through early delivery of valuable software. It violates the principle of welcoming changing requirements. It prevents emergence of requirements, designs, and architectures.

Articulate a vision and start building

Sprint Zero is nothing more than the earliest stages of waterfall disguised by an agile-sounding term. But it’s not necessary—or possible—to know everything up front. All those features and requirements that seem so important during a requirements-gathering phase often turn out to not be needed at all.

The best way to handle the uncertainty of product development is not extensive up-front analysis, but to articulate a clear product vision and start building toward it.

Want to Learn More or Get in Touch?

Register for our upcoming web meetings by visiting

See available training courses at

Visit the website and catch up with all the episodes at!

Email your thoughts or suggestions to or Tweet @AgileThought using #AgileThoughtPodcast!

plus icon
share episode
episode art

07/17/20 • 30 min

In today’s episode, Dan Neumann is joined by return guest, Andrea Floyd! Andrea is an enterprise agile transformation consultant at AgileThought. Andrea has 25 years of experience in software development and management. She is an innovator who has led multiple organization-wide scaled agile implementations, and she has also architected innovative solution strategies and roadmaps across many frameworks (including Scrum, Kanban, and the Scaled Agile Framework).

Dan and Andrea will be discussing the premise of agility and the common misunderstanding that it is only an IT ‘thing’ and is software-centric. Andrea explains how agility addresses needs across the enterprise and that it is about collaboration with many different areas of the business beyond IT. She shares how a shift from software agility to business agility drives the enterprise; and talks collaboration, feedback loops, design-thinking techniques, the importance of being customer-centric, applying agility across the organization, and key considerations around bringing the technology side and business side together.

Key Takeaways

Considerations when shifting to a more business agility:

Be careful not to create “us vs. them” scenarios (‘us’ as in the technology side and the ‘them’ being the business side)

As leaders, it is important to open up about the way you think about Agility and the principles

It is important to create a united effort of working together to achieve the desired outcomes (moving from ‘doing’ to ‘understanding’)

Be aware of cognitive biases, for instance, the ingroup and outgroup bias (where people tend to ascribe positive behaviors/attributes to people they consider to be in their group vs. ascribing/amplifying negative behaviors/attributes to people they consider to be outside of their group)

It is important to expand your ingroup bubble to at least your whole company (which would lead to more interpretation of positive intent and better collaboration)

It’s not about the individual developer getting to done; it’s about the team getting to done

Being more inclusive and valuing what every individual is bringing to the table has an incredibly profound impact

Key pieces in shifting from a software (or IT-centric) view of agility to business agility:

Start to reimagine roles and how you operate together

The business side needs to welcome the technologists to their side/domain and vice versa

Everyone needs to understand that there is huge value in understanding their customers/users and understanding the ‘why’ behind delivering

Allow people to be free and feel safe enough to create and innovate

Invite everyone into the full conversation

Truly value being engaged

Work towards building empathy between the people building the software and the people who will be using it

Apply the Agile principles, practices, and mindset pieces across the organization

Understand the ‘why’ behind why you’re doing agile practices as well as the intention behind them

Key places to have dynamic conversations with technology and the business:

Through backlog refinement — the inclusiveness comes from the product owner being able to articulate

Come up with a more creative ‘how’ or an ‘incremental how’

The product owner can communicate “no” or “not yet” to their stakeholders

The software on its own is not the product; there are other key pieces that create the ‘shrink-wrapped’ product

“When we think about business agility, what we want to do is understand what it takes to really get that product into the hands of our customers”

How you coordinate across the teams so you get that “shrinkwrapped product increment” is important

Think beyond just getting the software to ‘done’

Key points around accelerating the value chain:

Look to make ‘idea to value’ as short of a line as possible

Reference The Age of Agile’s three laws of business agility: the law of the customer, the law of a small team, and the law of the network

Empower your team and allow for autonomy

Feedback loops with your users/customers are key

Design thinking techniques are a great way to learn more about your customers/users

Empathy is huge — it is the basis for innovation and creativity

Mentioned in this Episode:

The Agile Manifesto

Modern Agile — Joshua Kerievsky

The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done, by Stephen Denning

plus icon
share episode
episode art

07/14/20 • 5 min

In this episode, Professional Scrum Trainer Sam Falco answers the question: "Is it OK to plan several Sprints in advance?"

I’ve seen this practice in many organizations. Product Owners plan four, five, even six Sprints of work for their teams. The result is something like a Gantt chart with Sprints instead of weeks as the unit of measure. It’s a bad practice with many drawbacks and no real benefit.

It diminishes transparency

The Scrum Guide’s description of the Product Backlog gives us our first clues that planning Sprints in advance is a bad practice.

  • “The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.”

Assigning Product Backlog items to future Sprints means that you’re splitting your Product Backlog into multiple lists. The order is more difficult to see, and instead of a single source of requirements, you now have several.

The Scrum Guide also says that the Product Backlog is dynamic and constantly changing. Having Product Backlog Items scattered over a number of Sprints makes managing this dynamic change more difficult than if you have a single artifact. In one organization I was in, Product Owners would plan an entire Program Increment and then spent a significant amount of time trying to manage multiple forecasted Sprint Backlogs as well as the remaining Product Backlog.

It diminishes self-organization

When multiple Sprints are planned in advance, the Development Team loses its role in collaborating with the Product Owner to craft a Sprint Goal and select Product Backlog Items into the Sprint Backlog that they believe will help achieve that Sprint Goal. Often, no Sprint Goal is identified—instead, the goal is for the Development Team to “do all the things.” The Development Team’s autonomy is hobbled, and it is robbed of the opportunity to self-organize around a coherent, meaningful goal.

It diminishes inspection and adaptation

The Scrum Guide closes its definition of the Product Backlog by pointing out that while forecasting progress may prove useful, forecasting techniques “do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.”

Planning multiple Sprints in advance means that we are making decisions about the future based on what we expect will happen. Sprint six is planned based on what we expect to do in sprints one through five, for example. We’re making assumptions about the future before we have a chance to validate what we’re doing right now. It tends to result in attempting to produce to a forecast rather than basing our work on current business conditions.

But how do I forecast?

Proponents of planning multiple Sprints in advance say that they need to do it in order to forecast release dates. But as Scrum Master Yoda said, “Always in motion is the future.” Planning several Sprints at a time, only to have to re-plan them as things change is wasteful and doesn’t create certainty.

Instead, we should embrace uncertainty and incorporate it into our forecasts, providing a target range that widens the farther out we look.

Forecasting with Scrum is best done by understanding our team’s velocity (as it actually is, not as we want it to be). We can use what we know about the team’s historical ability to deliver to make a “good enough” estimate of the least and most they are likely to produce.

Want to Learn More or Get in Touch?

Register for our upcoming web meetings by visiting

See available training courses at

Visit the website and catch up with all the episodes at!

Email your thoughts or suggestions to or Tweet @AgileThought using #AgileThoughtPodcast!

plus icon
share episode
episode art

07/10/20 • 32 min

This week on the Agile Coaches’ Corner, Dan Neumann is joined by a new guest, Michael Guiler! Mike is an Agile Consultant at AgileThought. He has been an Agile coach for over 13 years now and has tons of experience helping geographically dispersed organizations (both business and technology) transform to better achieve their goals. His focus is on helping organizations learn and apply the values and principles of the Agile mindset to continuously improve.

In this episode, Dan and Mike will be focusing on the topic of intent-based leadership and the key leadership characteristics that allow for intent-based leadership. Mike shares how an organization can begin to take the first steps towards intent-based leadership, how to avoid common pitfalls, and shares his best practical tips and advice on embracing intent-based leadership throughout the organization.

Key Takeaways

What is intent-based leadership? What problems does it solve?

Helps to get the entire team to chip in and no longer wait for approvals and sign-offs

Takes the pressure off of one single leader and unlocks the potential of every employee

The opposite of directive leadership

Changing the pattern from leader-follower to leader-leader

Those in the leadership level are not telling people what to do/how to do it; they are setting goals and directions

The ‘followers’ are engaging their creativity, mind, and intelligence and leveraging those skills and sharing their solutions with the leadership (this gives the organization a great opportunity to learn and exposes leaders to things they hadn’t thought about before)

Getting started with intent-based leadership/Characteristics of leadership to allow for intent-based leadership:

Before the leader-leader pattern can take place a lot of growth has to take place

Keep in mind that this process won’t happen overnight

Immediately begin to address competence — leadership at all levels can’t thrive if your team doesn’t have the skills or knowledge to prioritize and take action

Establish safety — mistakes will happen; it’s how we react to those mistakes that will enable leadership at all levels to thrive or to fail miserably

Use mistakes as a learning opportunity rather than punishing an individual

Be curious and ask good questions from a place of true curiosity

Challenge your preconceived notions of how things have always been done

Embrace new ideas and thoughts — there’s a real chance you’ll learn something!

Allow time for the team to talk out loud

Respect others opinions and encourage others to have their own point of view

It’s hard and will take a lot of time and investment (but it’s money well-spent — the productivity will explode)

It’s important to set guide rails in the technology world

Focus on the goal/outcome instead of the ‘how’; set clear intentions and let the team figure out how

Adopt the “I intend to” language pattern

Mike’s intent-based leadership tips:

Once the competency is established and you’ve gotten your organization thinking about it, it is important to establish safety (without safety people won’t bring their creative-selves or do anything new)

It is key crucial for the team to know what the goals are

Have an “ish” mindset; decisions and actions being taken won’t match yours and that’s OK!

Overcome urges to command and control

Be tolerant of differences and encourage different points of view

Mike’s recommendation to further learn about intent-based leadership:

Turn the Ship Around!: A True Story of Turning Followers into Leaders, by David L. Marquet

Mentioned in this Episode:

Michael Guiler

Agile Coaches’ Corner Ep. 84: “Getting to ‘Finish’ as a Scrum Team with Andrea Floyd”

Turn the Ship Around!: A True Story of Turning Followers into Leaders, by David L. Marquet

Forbes article regarding psychopathology in CEOs

Michael Guiler’s Book Picks:

The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done, by Stephen Denning

plus icon
share episode
episode art

07/07/20 • 5 min

In this episode, Professional Scrum Trainer Sam Falco addresses the question: “How do you escape the tyranny of the burndown chart?”

The Problem with Burndown Charts

This was the question a student asked last week. I knew exactly what he meant. I experienced it myself with my first Scrum Team, and I’ve seen it many time since. Teams try to predict every task they’ll have to do during a Sprint, estimate the hours for each, and make sure that the team’s capacity is fully allocated. As the Sprint progresses, they discover new work. Work that was predicted takes longer than usual. The burndown rises instead of falling, or it plateaus. The burndown chart becomes a burden that destroys morale and effectiveness.

After a few Sprints of this experience, teams either abandon the burndown chart or they start playing games to make the burndown “look right.” In both cases, the team loses out on a valuable tool for helping them achieve the Sprint Goal.

Does the Scrum Guide Require Burndown Charts?

To be clear, the Scrum Guide does not mandate the use of a burndown chart. Here’s what it says about tracking Sprint progress:

“At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.”

Tracking total work remaining provides transparency about the team’s progress toward the Sprint Goal. That transparency allow the team to make informed decisions about how to adjust the scope of its work throughout the Sprint. If the team doesn’t know how much forecasted work remains, the Sprint Goal may be placed in jeopardy.

A sprint burndown chart is one way to fulfill the need to sum up the remaining work and make that data visible. So why does the burndown chart so easily become a burden to the team, rather than a tool?

Often, it’s because of a holdover from the mistaken belief that software development can be managed through predictive processes. Even in organizations that recognize the folly of predictive planning on a macro level, teams fall into the trap of thinking they can and should plan every minute of a team’s capacity.

How do we use a Burndown Chart Effectively?

Software development falls into the realm of complexity. Even within a Sprint, we have to allow for emergent understanding of the work. Requirements, understood well enough for the work to begin, become clearer. New work emerges as a result. Teams that have strived for efficiency in allotting their time find that there’s no room to adjust as new information and understanding becomes available.

The secret to avoiding the tyranny of the burndown chart has nothing to do with the burndown chart itself. The secret is to let go of the belief that we can know everything up front and that efficient time usage is a worthwhile goal. Instead, strive for value delivery, select work that the team understands well enough to start on, and don’t strive for 100% utilization. The only thing certain about software development is that it is filled with uncertainty. In Sprint Planning, you need only look a few days into the future, and allow remaining details to arise as work gets underway.

Want to Learn More or Get in Touch?

Register for our upcoming web meetings by visiting

See available training courses at

Visit the website and catch up with all the episodes at!

Email your thoughts or suggestions to or Tweet @AgileThought using #AgileThoughtPodcast!

plus icon
share episode
episode art

Has COVID-19 Accelerated Agile?

Agile Coaches' Corner


07/03/20 • 32 min

In this week’s episode, Dan Neumann is joined by frequent guest of the show, Quincy Jordan — principal transformation consultant and agile competency lead at AgileThought! Together, they are exploring COVID-19 as an agile accelerator.

In the agile space, there has been a long-time myth that face-to-face is synonymous with colocation and that you cannot have effective agile teams if they are not colocated. However, in the past year or so, many companies have been beginning to consider going to a hybrid remote model. But, when COVID-19 hit, their 12-month transition plans quickly became one-week transition plans. And though this has been very difficult for many, this acceleration due to COVID-19 has actually been a good thing in many cases — which is what Dan and Quincy will be talking about today!

They discuss which types of things got accelerated, beliefs about agility that got challenged due to COVID-19, what the ‘new normal’ post-COVID-19 may look like, and how these changes will be made to be sustainable going forward.

Key Takeaways

Beliefs about agility that got challenged due to COVID-19:

Those people in the agile space that were especially adamant that you cannot have effective agile teams that are remote were shown that it was possible

Some people believed that doing training in a distributed way would bring the quality down — however, the quality of training that is being delivered has not gone down since going remote

What COVID-19 has accelerated:

When pressed, many people are able to do very impressive things and accomplish more than they thought possible

It accelerated ingenuity and creativity

It accelerated the decisions to collaborate with one another as teammates and to quickly come together on a situation to figure out the most effective solution

It helped accelerate clarity on what was truly important to accomplish

It has driven companies to really start embracing business agility a lot more

Agility went from a concept that companies only thought about to a concrete concept that they embraced

Organizations have been focusing on value more due to embracing the agile mindset (and COVID-19 has been pushing this to further bounds)

It has helped push organizations to further their alignment on business agility and focus on the problems that need to be solved

COVID-19 has also accelerated businesses beyond those in software (it permeated into all facets)

Challenges regarding COVID-19 and the acceleration it has brought:

How do we maintain alignment between business and IT in this remote world? (How often do we need to meet? What do we need to be aligned on?)

Video conference fatigue

How do we ensure that the right problems are being solved, that the vision is clear, that the business objectives at hand are clear, and that the teams know how to tie their work to meaningful outcomes for the business?

People don’t adapt as fast as technology

What might the new ‘new normal’ look like post-COVID-19?

There most likely will be more remote work and more emphasis on collaborating remotely

There may be a bigger demand for remote tools (such as digital whiteboards) and they will become even more efficient going forward

People will most likely be more intentional about how they are showing up to video conferences with clearer goals in mind

Mentioned in this Episode:

From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver, by Johanna Rothman and Mark Kilby

The Decision: Overcoming Today’s BS for Tomorrow’s Success, by Kevin Hart

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on!

Email your thoughts or suggestions to or Tweet @AgileThought using #AgileThoughtPodcast!

plus icon
share episode
episode art

06/30/20 • 6 min

In this episode, Professional Scrum Trainer Sam Falco addresses the question: "How do we avoid Scrum adoption pitfalls?"

Last week, a student asked me what are some common pitfalls that we see when organizations shift to Scrum from a “big design upfront” process like waterfall.

A big one is that they think it’s a silver bullet

Adopting Scrum doesn’t solve problems overnight. It doesn’t solve problems at all! Scrum will surface the problems in your ability to deliver so that you can fix them. Too many organizations falter when Scrum runs up against an organizational impediment and “the way we’ve always done it” wins out. One example of this phenomenon is when there’s an onerous change management system that prevents code from getting into production. Scrum teams complete an increment and it sits there waiting until someone approves it to be moved to production. Sometimes, the wait is so long that multiple increments pile up.

Some organizations will cling to that change management system even though it’s getting in the way. Success comes when they adapt to the new way of working. At one organization I worked with, the solution was to set up an experiment with one team working on a less risky area of code. Once they proved that they could safely put code into production without breaking things, it paved the way for broader changes to their process.

Another pitfall is that the organization doesn’t really adopt Scrum

In many cases, organizations claim to adopt Scrum, but what they really do is apply Scrum terminology to existing roles and processes. I frequently see the term “Product Owner” used—or maybe I should say abused—as a new name for a Project Manager. But those Project Managers carry on pretty much the way they did before. They lack any of the accountabilities or authority of a Scrum Product Owner. They shift from using Gant charts measured in weeks to plotting out a project in Sprints over several months.

And that’s another way this behavior manifests. They’ll use the name of Scrum events without understanding their underlying purpose. A Sprint lacks the focus of creating a usable increment. “Daily Scrum” is a daily status report. “Sprint Review” is a carefully orchestrated smoke-and-mirrors show with limited, if any feedback or collaboration with stakeholders.

Without using all of its roles, events, and artifacts—and the rules that bind them together—you’re not using Scrum. You’re probably perpetuating your existing system. You know, the one that wasn’t working for you before. This is the realm of “Scrum, but.” And “Scrum, but” is not Scrum at all.

They don’t make other necessary changes

Even when an organization adopts Scrum’s mechanics, they sometimes find that Scrum doesn’t provide the benefits they hoped for. Delivery improves a little, but it soon plateaus and it’s a struggle to keep improving. That’s because other changes are necessary to really reap the gains of Scrum.

A common organizational structure is to have teams organized around technical layers or components. For example, a User Interface team, a Data Access Team, a Service gateway team, and so on. Scrum requires that we produce a working increment each Sprint, which means one that’s in usable condition. Teams organized by layers or components face numerous handoffs and challenges integrating their work. There’s a loss of transparency, and they struggle to compete that working increment.

The solution is to form teams that can deliver complete features that cut across all layers. Scrum doesn’t tell you to do that, but it works best if you do.

Scrum also doesn’t tell you to adopt good DevOps practices, or incorporate Kanban techniques, or to refactor your code. They’re all still good ideas.

Scrum is incomplete for a reason and that’s so that you can identify what works best for your organization. You have to go beyond Scrum. I talked about the pitfall of “Scrum, but,” earlier. But “Just Scrum” isn’t enough. You need “Scrum, and.”

Adopting Scrum requires a shift in organizational mindset. Without that, people revert to familiar behavior, even if that behavior wasn’t effective. And adopting Scrum can’t be an endpoint. It’s the beginning of a journey of experimentation and continuous improvement. In the Trainer Talk episode “Why Does Scrum Have So Many Meetings?” a few weeks ago, I mentioned that implementing Scrum requires intentional, thoughtful organizational redesign. That’s true of implementing the basics of the framework, but it’s equally true about the wider ecosystem that Scrum teams work in. And just like I said in that earlier episode, that’s why you need a good experienced Scrum Master—and sometimes more than one—to guide your organization’s Scrum adoption.

Want to Learn More or Get in Touch?

Register for our upcoming web meetings by visiting

plus icon
share episode
episode art

07/31/20 • 38 min

Today on the podcast, Dan Neumann and Christy Erbeck are discussing how to lead in times of crisis and come out of it stronger than ever.

As a leader, it is critically important to take care of yourself during crises to be able to lead others through them, as well. In this episode, Christy shares her tips for leading through crisis, key strategies leaders can begin to implement, and how to cultivate a healthy work environment for everyone involved.

Key Takeaways

Christy’s tips for leaders, leading in a time of crisis:

Use it as a time to reflect on where you are now and where you want to be on the other side of it all

Take time to process your emotions and lead from a place of truth

Lead by example; take care of yourself and work at a sustainable pace while encouraging the rest of the team

Transparency is key — be transparent about where you are, as a team, as an organization, and in relation to the difficult decisions you’ve had to make to survive the crisis (transparency offers the opportunity for growth and building trust within the organization)

Understand your audience in your approach with being transparent; it is important to care for the person receiving the information

Going hand-in-hand with transparency, it is also critical to communicate (and the need for communication exponentially rises, the greater the crisis)

Meaningful, intentional communication and on-going dialogue between the employee and the leader (or the team and the team members) is critically important for minimizing the stories they may be telling themselves when there is a gap in communication or lack of communication

Connect in a meaningful way with your employees vs. walking away or being silent

Authenticity is critically important in leading through a crisis — it’s not about what you know; it’s about what you’re willing to learn

Do not defer taking action until the last possible moment

How to come out of a crisis stronger than ever with your team:

Delegate decision-making and allow other people to make decisions within a framework

Take pragmatic action

Ensure you are still meeting and talking about your longer-term strategy beyond COVID-19

Examine how to position your organization so that when you come out on the other side of COVID-19 you are attractive to the marketplace and your customers

Leverage OKRs

Apply an experimental mindset and conduct experiments (one way you could do this is to utilize Kanban boards)

Implement empirical process control

Cultivate a culture steeped in trust and forgiveness

Continual planning

Reach out to others as a leader so that you’re not making decisions in a vacuum and are leveraging other people’s expertise

Imagine what the leader that you most respect would do; how would they handle this situation? And how can you tap into this person’s expertise?

Make the time to reflect and gain perspective

Be courageous as a leader by being vulnerable

Mentioned in this Episode:

The Dave Ramsey Show

Brené Brown

“A Guide to OKRs,” KOAN

Agile Coaches’ Corner Ep. 5: “Exploring an Experimental Mindset with Adam Ulery”

“What is a Kanban Board?”

Small Business Administration (SBA)

SCORE — Service Corps of Retired Executives


The Conference Board

Harvard Business Review

“Microsoft Analyzed Data on its Newly Remote Workforce,” Harvard Business Review

“Managing When the Future is Unclear,” Harvard Business Review

“Leadership in Times of Crisis,” American Psychological Association

plus icon
share episode

Show more

Toggle view more icon


How many episodes does Agile Coaches' Corner have?

Agile Coaches' Corner currently has 270 episodes available.

What topics does Agile Coaches' Corner cover?

The podcast is about Podcasts, Technology and Business.

What is the most popular episode on Agile Coaches' Corner?

The episode title 'Will getting a Scrum Master certification help me get a job?' is the most popular.

What is the average episode length on Agile Coaches' Corner?

The average episode length on Agile Coaches' Corner is 28 minutes.

How often are episodes of Agile Coaches' Corner released?

Episodes of Agile Coaches' Corner are typically released every 7 days.

When was the first episode of Agile Coaches' Corner?

The first episode of Agile Coaches' Corner was released on Nov 23, 2018.

Show more FAQ

Toggle view more icon



out of 5

Star filled grey IconStar filled grey IconStar filled grey IconStar filled grey IconStar filled grey Icon
Star filled grey IconStar filled grey IconStar filled grey IconStar filled grey Icon
Star filled grey IconStar filled grey IconStar filled grey Icon
Star filled grey IconStar filled grey Icon
Star filled grey Icon


Star iconStar iconStar iconStar iconStar icon

Review or comment on this podcast...


External Reviews

Imported reviews from Apple Podcasts.

Generate a badge

Get a badge for your website that links back to this

Select type & size
Open dropdown icon
share badge image