Agile Coaches' Corner

Dan Neumann is joined by Senior Agile Coach at AgileThought, Adam Ulery, to discuss the concept of Agile forcing continuous improvement.

Does agile “force” continuous improvement? What does this mean? Is this inherently negative or positive? How does agile implement continuous improvement as a natural consequence? Dan and Adam address these questions and share their tips on how to leverage agile to maximize your continuous improvement in all levels of your organization!

Key Takeaways

What does “Agile forcing continuous improvement” mean?

Agile “forces” continuous improvement because continuous improvement is inherently baked into agility

“Force,” not as coercion, but as a natural outcome of adopting an agile mindset

The frequent use of feedback loops is built into the way you work in an agile environment, “forcing” continuous improvement

How Agile implements continuous improvement as a natural consequence:

Regardless of the framework, there is a feedback loop with the goal being to deliver as much value as possible to the end consumer

Inspecting and adapting the product and the process at regular intervals

Agile encourages and fosters teams to be able to talk about things transparently and openly and not see impediments as an indictment of their performance

Through failing fast (i.e. learning fast through your failures or mistakes) the team will continue to improve

Tips for leveraging Agile’s continuous improvement:

Address the fear of speaking up by teaching leadership roles on how to make the environment safe for the delivery teams

Acknowledge that the environment may have not been safe in the past but that changes are being implemented and it will be different going forward

The shorter the feedback loop, the shorter the risk (so if something doesn’t go right, you’re not that far from recovery)

Deliver early and often, get the feedback loops working so that teams can course-correct as they learn

It’s important to get to a point where it is understood that quick learning is what the team and leadership is looking for (and that failure is not failure; it’s learning)

Leadership needs to be supportive of the mindset shift regarding quick learning/failing fast so that the team can feel encouraged in exhibiting these behaviors

If you are a leader who wants to begin to make their team more comfortable with quick learning you need to educate yourself, believe it, communicate with your team, be transparent that you’re still learning and growing, set your expectations about what you’d like to see, and call out real examples as they happen so that the team can begin to recognize it

As a leader, display vulnerability and acknowledge that you have not done the best with communicating in the past but that it will be different, going forward 

Model the behaviors you want to see as a leader

You need to create safety and support your team in order to thrive and increase performance

Mentioned in this Episode:

Leaders Eat Last: Why Some Teams Pull Together and Others Don't, by Simon Sinek

Radical Focus: Achieving Your Most Important Goals with Objectives and Key Results, by Christina R. Wodtke

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 AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

In this episode, Dan and Sam are exploring the topic of evidence-based management, which was first mentioned in Episode 101, “Are Scrum Masters Expendable?” In that conversation, they discussed some of the things that Scrum Masters could be doing beyond the team and one of them is in helping manage the product suite.

Dan and Sam unpack the concept of evidence-based management and share how this model can be used alongside Scrum to help people and organizations improve the way they deliver products and improve the value of their products.

This episode is rather timely too, with the newest edition of the Evidence-Based Management Guide just being released on Scrum.org! If you’re new to EBM (or didn’t fully understand it before) there is no better time than the present to learn about it.

Key Takeaways

What is evidence-based management?

It’s an empirical approach to help organizations

EBM provides a framework to get a better feel for what is valuable so you can base the decisions you make on actual data (rather than gut-feeling) and run experiments that improve metrics

Through intentional experimentation and evidence, EBM enables organizations to systematically improve their performance over time and refine their goals based on better information

The EBM model:

It has five key elements:

A Strategic Goal — something important that the organization would like to achieve; this goal is big and far away with many uncertainties (similar to a product goal) — because of this, the organization needs a series of practical targets, like:

Intermediate Goals — achievements which indicate that the organization is on the path to its Strategic Goal (the path to the Intermediate Goal is often somewhat uncertain but not completely unknown) (kind of like a release goal)

Immediate Tactical Goals — critical near-term objective toward which a team or group of teams will work help toward Intermediate Goals (similar to a sprint goal)

A Starting State — where the organization is relative to the Strategic Goal when it starts its journey

A Current State — Where the organization is relative to the Strategic Goal at the present time

EBM focuses on four Key Value Areas (KVAs):

These areas examine the goals of the organization

As an organization, you want to measure and evaluate these

Current Value (CV) – the current value that the product is delivering today

The purpose of looking at CV is to understand the value that the organization is delivering to customers and stakeholders at the present time

Organizations need to be continually re-evaluating and looking at customer/user happiness, employee happiness, and investor and stakeholder happiness

CV helps the organization understand the value that their customers or users are experiencing today

Unrealized Value (UV) — additional/potential value the product could realize if it was pursued

UV could be features that the organization hasn’t considered developed yet (but could) or markets that the product could serve (but doesn’t currently)

The organization should be thinking about: “Can we get any additional value out of this product?” and whether or not it’s worth it

Comparing UV and CV can help an organization decide whether or not they should continue investing in a product

Time to Market (T2M) — how long it takes the organization to deliver new value

The reason for looking at T2M is to minimize the amount of time it takes for the organization to deliver value (without it, the ability to sustainably deliver value in the future is unknown)

Ask: “Are we spending too much time estimating?”

Questions the organization needs to continually re-evaluate for T2M are: “How fast can the organization learn from new experiments and information?”, “How fast can you adapt, based on the information?”, and “How fast can you test new ideas with customers?”

Ability to Innovate (A2I) — the effectiveness of the organization at delivering value

The goal of A2I is to maximize the organization’s ability to deliver new features and capabilities that customers will find valuable

When evaluating A2I, an organization should be asking: “What is preventing us from delivering new value?” and “What prevents customers from benefiting from the innovation?”

Having a hypothesis and executing an experiment:

A hypothesis is a proposed explanation for some observation that has not yet been proven or disproven

After forming a hypothesis, run the experiments, and then inspect the results

Was the hypothesis proven or disproved? Once you have this data you can evaluate it and make adjustments as needed

“Explicitly forming hypotheses, measuring results, and inspecting and adapting goals based on those results are implicit parts of an agile approach. Making this work explicit and transparent is what EBM adds to the organizational improvement process.” — EBM Guide

Mentioned in this Episode:

Evidence-Based Management Guide | Scrum.org

Agile Coaches’ Corner Ep. 101: “Are Scrum Masters Expendable?”

Agile Coaches’ Corner Ep. 78: “Exploring OKRs with Felipe Castro”

Three Horizons Framework

The Anarchy: The East India Company, Corporate Violence, and the Pillage of an Empire, by William Dalrymple

The Creative Habit: Learn It and Use It for Life, by Twyla Tharp

Hillbilly Elegy: A Memoir of a Family and Culture in Crisis, by J.D. Vance

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

In this episode, Dan and Sam are exploring the topic of evidence-based management, which was first mentioned in Episode 101, “Are Scrum Masters Expendable?” In that conversation, they discussed some of the things that Scrum Masters could be doing beyond the team and one of them is in helping manage the product suite.

Dan and Sam unpack the concept of evidence-based management and share how this model can be used alongside Scrum to help people and organizations improve the way they deliver products and improve the value of their products.

This episode is rather timely too, with the newest edition of the Evidence-Based Management Guide just being released on Scrum.org! If you’re new to EBM (or didn’t fully understand it before) there is no better time than the present to learn about it.

Key Takeaways

What is evidence-based management?

It’s an empirical approach to help organizations

EBM provides a framework to get a better feel for what is valuable so you can base the decisions you make on actual data (rather than gut-feeling) and run experiments that improve metrics

Through intentional experimentation and evidence, EBM enables organizations to systematically improve their performance over time and refine their goals based on better information

The EBM model:

It has five key elements:

A Strategic Goal — something important that the organization would like to achieve; this goal is big and far away with many uncertainties (similar to a product goal) — because of this, the organization needs a series of practical targets, like:

Intermediate Goals — achievements which indicate that the organization is on the path to its Strategic Goal (the path to the Intermediate Goal is often somewhat uncertain but not completely unknown) (kind of like a release goal)

Immediate Tactical Goals — critical near-term objective toward which a team or group of teams will work help toward Intermediate Goals (similar to a sprint goal)

A Starting State — where the organization is relative to the Strategic Goal when it starts its journey

A Current State — Where the organization is relative to the Strategic Goal at the present time

EBM focuses on four Key Value Areas (KVAs):

These areas examine the goals of the organization

As an organization, you want to measure and evaluate these

Current Value (CV) – the current value that the product is delivering today

The purpose of looking at CV is to understand the value that the organization is delivering to customers and stakeholders at the present time

Organizations need to be continually re-evaluating and looking at customer/user happiness, employee happiness, and investor and stakeholder happiness

CV helps the organization understand the value that their customers or users are experiencing today

Unrealized Value (UV) — additional/potential value the product could realize if it was pursued

UV could be features that the organization hasn’t considered developed yet (but could) or markets that the product could serve (but doesn’t currently)

The organization should be thinking about: “Can we get any additional value out of this product?” and whether or not it’s worth it

Comparing UV and CV can help an organization decide whether or not they should continue investing in a product

Time to Market (T2M) — how long it takes the organization to deliver new value

The reason for looking at T2M is to minimize the amount of time it takes for the organization to deliver value (without it, the ability to sustainably deliver value in the future is unknown)

Ask: “Are we spending too much time estimating?”

Questions the organization needs to continually re-evaluate for T2M are: “How fast can the organization learn from new experiments and information?”, “How fast can you adapt, based on the information?”, and “How fast can you test new ideas with customers?”

Ability to Innovate (A2I) — the effectiveness of the organization at delivering value

The goal of A2I is to maximize the organization’s ability to deliver new features and capabilities that customers will find valuable

When evaluating A2I, an organization should be asking: “What is preventing us from delivering new value?” and “What prevents customers from benefiting from the innovation?”

Having a hypothesis and executing an experiment:

A hypothesis is a proposed explanation for some observation that has not yet been proven or disproven

After forming a hypothesis, run the experiments, and then inspect the results

Was the hypothesis proven or disproved? Once you have this data you can evaluate it and make adjustments as needed

“Explicitly forming hypotheses, measuring results, and inspecting and adapting goals based on those results are implicit parts of an agile approach. Making this work explicit and transparent is what EBM adds to the organizational improvement process.” — EBM Guide

Mentioned in this Episode:

Evidence-Based Management Guide | Scrum.org

Agile Coaches’ Corner Ep. 101: “Are Scrum Masters Expendable?”

Agile Coaches’ Corner Ep. 78: “Exploring OKRs with Felipe Castro”

Three Horizons Framework

The Anarchy: The East India Company, Corporate Violence, and the Pillage of an Empire, by William Dalrymple

The Creative Habit: Learn It and Use It for Life, by Twyla Tharp

Hillbilly Elegy: A Memoir of a Family and Culture in Crisis, by J.D. Vance

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

Today marks an exciting day; the new Scrum Guide was released just this last Wednesday and marks some big, notable changes! The release of the new guide also marks Scrum turning 25 years old!

Join Dan Neumann and Sam Falco in this episode as they discuss all of the changes from the previous 2017 to the new 2020 guide; share their thoughts and key takeaways; and provide further insight on what some of these changes could mean for Scrum, Scrum teams, and Scrum Masters going forward.

Key Takeaways

Notable changes to the new 2020 Scrum Guide:

From 17 pages to 13 pages

Clarification on the daily Scrum; why you have it and what its purpose is

The statement about the immutability of Scrum went from being an endnote to being placed front and center

They’ve taken out all IT-specific language; the 2020 Scrum Guide is explicitly reaching out to an audience beyond IT and software development

“Developer” no longer means “coder”; it applies to anyone developing a solution (if you are developing a product, you are a developer)

The new language used in the guide will make it easier to teach and apply to a broader audience (such as marketing campaigns, artistic endeavors, etc.)

Doing away with two levels of teams (no more Scrum team which has a development team); it’s just a Scrum team now

All roles are within the Scrum team (i.e. the Scrum team is responsible for all product-related activities)

In the 2017 version, it spoke about potentially releasable increments but in the 2020 version, it says the increment must be useable

A greater emphasis on the fact that the Scrum Master is accountable for the Scrum team’s effectiveness by enabling the Scrum team to improve its practices within the Scrum framework

Clarification around one of the ways that the Scrum Master serves the team: “by causing the removal of impediments” (vs. “removing impediments” in the 2017 vers.)

From “self-organizing team” to “self-managing team”

Commitment has taken on a greater significance: each of the three artifacts now comes with an associated commitment 

Before, the commitment on the Scrum team was to the sprint goal; now, the product backlog has its own commitment (the product goal), the sprint backlog retains the sprint goal as a commitment, and the increments commitment is the definition of done

This change emphasizes the importance of a long-term vision and eliminates the previous criticism that Scrum is just about going sprint-to-sprint

Closing thoughts:

Scrum itself inspects and adapts

Jeff and Ken are hearing and listening to what people are saying about the Scrum Guide and are striving to help people understand it better

It continues to evolve at a good rate

Be sure to go read it through start-to-finish!

Mentioned in this Episode:

The 2020 Scrum Guide Launch Event

Ken Schwaber’s 2020 Scrum Guide Teaser Blog Post

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

Today marks an exciting day; the new Scrum Guide was released just this last Wednesday and marks some big, notable changes! The release of the new guide also marks Scrum turning 25 years old!

Join Dan Neumann and Sam Falco in this episode as they discuss all of the changes from the previous 2017 to the new 2020 guide; share their thoughts and key takeaways; and provide further insight on what some of these changes could mean for Scrum, Scrum teams, and Scrum Masters going forward.

Key Takeaways

Notable changes to the new 2020 Scrum Guide:

From 17 pages to 13 pages

Clarification on the daily Scrum; why you have it and what its purpose is

The statement about the immutability of Scrum went from being an endnote to being placed front and center

They’ve taken out all IT-specific language; the 2020 Scrum Guide is explicitly reaching out to an audience beyond IT and software development

“Developer” no longer means “coder”; it applies to anyone developing a solution (if you are developing a product, you are a developer)

The new language used in the guide will make it easier to teach and apply to a broader audience (such as marketing campaigns, artistic endeavors, etc.)

Doing away with two levels of teams (no more Scrum team which has a development team); it’s just a Scrum team now

All roles are within the Scrum team (i.e. the Scrum team is responsible for all product-related activities)

In the 2017 version, it spoke about potentially releasable increments but in the 2020 version, it says the increment must be useable

A greater emphasis on the fact that the Scrum Master is accountable for the Scrum team’s effectiveness by enabling the Scrum team to improve its practices within the Scrum framework

Clarification around one of the ways that the Scrum Master serves the team: “by causing the removal of impediments” (vs. “removing impediments” in the 2017 vers.)

From “self-organizing team” to “self-managing team”

Commitment has taken on a greater significance: each of the three artifacts now comes with an associated commitment 

Before, the commitment on the Scrum team was to the sprint goal; now, the product backlog has its own commitment (the product goal), the sprint backlog retains the sprint goal as a commitment, and the increments commitment is the definition of done

This change emphasizes the importance of a long-term vision and eliminates the previous criticism that Scrum is just about going sprint-to-sprint

Closing thoughts:

Scrum itself inspects and adapts

Jeff and Ken are hearing and listening to what people are saying about the Scrum Guide and are striving to help people understand it better

It continues to evolve at a good rate

Be sure to go read it through start-to-finish!

Mentioned in this Episode:

The 2020 Scrum Guide Launch Event

Ken Schwaber’s 2020 Scrum Guide Teaser Blog Post

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

Dan Neumann is joined once again by Quincy Jordan; Principal Transformation Consultant at AgileThought! Today, they’re exploring the concept of losing control to gain value.

Though the concept of “losing control” may sound a bit frightening, it is actually the most invaluable thing you can do as a leader of a team! Oftentimes, there are habits of control that can greatly impact a team’s ability to self-organize, mature, and deliver value. With less control, the team is able to produce better value.

In this episode, Quincy outlines the many interesting facets of losing control to gain value. He shares what this loss of control is, why losing control is key to gaining value, what you can do as a leader to let go of control and support your team in creating value, and much more!

Key Takeaways

Why is it important to lose control to gain value?

If you’re wanting to gain/produce value, you can run into roadblocks if you have a desire or habit of control

Oftentimes, leaders and senior leaders (especially managers, tech leads, etc.), primarily in the context of Scrum, struggle with a habit of control which can block them from achieving their desired result of more value

There are many habits of control that can impact the team’s ability to self-organize and deliver value

The leader can become accustomed to controlling the team’s narrative, leading the team to build mechanical habits (which doesn’t encourage self-organization, free-thinking, or experimentation)

Leaders are often inundated with fear that if they allow the team to self-organize they’ll make the wrong decisions or won’t produce as much (but this needs to happen in order for the team to mature properly)

When people want to direct and control what the team does (i.e. how they figure things out) they are hindering them from producing better results or better value (your team is full of smart people that can figure things out!)

If the team only knows the objective and they don’t understand the “why,” there is the potential that they’ll begin to do stuff mechanically (because it cripples them from making decisions in line with what the expectations are)

If you are directing your team’s day-to-day activities, you’re actually limiting/capping what they’re capable of

Exerting control of their activities makes you become the bottleneck

Why can a loss of control lead to more value?

Shifting the focus from trying to control what people are doing to instead trying to understand what they’re intending to do allows the team to mature

By removing yourself as the bottleneck of your team you’re allowing them to have room to grow and mature

Tips for leadership in letting go of control to support the team in creating value:

As a leader, it is important to not only understand the approach that’s being taken and where the parameters are/where the boundaries lie, but also that the team has the ability to self-organize and to figure out the best way to accomplish what is going to produce the most value

Your team just needs to know what the objective is that they’re trying to achieve (any more control is a hindrance)

It is critically important for teams to understand the “why” behind what the objective is (if they do, 9/10 times they’ll produce the best results and the best value that they’re capable of!)

Instead of controlling or directing the workflow, leaders should be focusing on improving the environment in which people work, closing skill gaps, and removing organizational impediments

As a supervisor or tech lead, you should serve as a mentor or be there as a  resource for the team (i.e. a go-to point for team members if they get stuck or need some direction on finding resources that will help them do their work)

It’s important to be there as a support but not a person to direct day-to-day activities as a leader

Leaders at a program, VP, or portfolio level need to make sure that they’re supportive of an agile ecosystem

In David Marquet’s Turn the Ship Around!, he talks about intent-based leadership (where the team comes to leaders, not with a request for direction, but instead with a: “I intend to do x, y or x,” which gives the leader a chance to inquire if appropriate. Eventually, this leads to less checking as the team demonstrates competency and consistency of delivery)

Pivoting to intent-based leadership is only possible if the leader makes it clear what the outcome is that they’re expecting

How to balance giving your team room to grow with safety measures:

In taking a Scrum approach, there are many benefits (because the framework gives solid boundaries that allow for a good balance of self-organization and accountability)

Accountability to one another (and themselves) is created by having daily Scrums

The sprint review adds balance because nobody is going months at a time without feedback

There is a regimen within the flexibility that the Scrum framework provides

Mentioned in this Episode:

Quincy Jordan

Agile Coaches’ Corner Ep. 101: “Are Scrum Masters Expendable?”

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

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

Dan Neumann is joined once again by Quincy Jordan; Principal Transformation Consultant at AgileThought! Today, they’re exploring the concept of losing control to gain value.

Though the concept of “losing control” may sound a bit frightening, it is actually the most invaluable thing you can do as a leader of a team! Oftentimes, there are habits of control that can greatly impact a team’s ability to self-organize, mature, and deliver value. With less control, the team is able to produce better value.

In this episode, Quincy outlines the many interesting facets of losing control to gain value. He shares what this loss of control is, why losing control is key to gaining value, what you can do as a leader to let go of control and support your team in creating value, and much more!

Key Takeaways

Why is it important to lose control to gain value?

If you’re wanting to gain/produce value, you can run into roadblocks if you have a desire or habit of control

Oftentimes, leaders and senior leaders (especially managers, tech leads, etc.), primarily in the context of Scrum, struggle with a habit of control which can block them from achieving their desired result of more value

There are many habits of control that can impact the team’s ability to self-organize and deliver value

The leader can become accustomed to controlling the team’s narrative, leading the team to build mechanical habits (which doesn’t encourage self-organization, free-thinking, or experimentation)

Leaders are often inundated with fear that if they allow the team to self-organize they’ll make the wrong decisions or won’t produce as much (but this needs to happen in order for the team to mature properly)

When people want to direct and control what the team does (i.e. how they figure things out) they are hindering them from producing better results or better value (your team is full of smart people that can figure things out!)

If the team only knows the objective and they don’t understand the “why,” there is the potential that they’ll begin to do stuff mechanically (because it cripples them from making decisions in line with what the expectations are)

If you are directing your team’s day-to-day activities, you’re actually limiting/capping what they’re capable of

Exerting control of their activities makes you become the bottleneck

Why can a loss of control lead to more value?

Shifting the focus from trying to control what people are doing to instead trying to understand what they’re intending to do allows the team to mature

By removing yourself as the bottleneck of your team you’re allowing them to have room to grow and mature

Tips for leadership in letting go of control to support the team in creating value:

As a leader, it is important to not only understand the approach that’s being taken and where the parameters are/where the boundaries lie, but also that the team has the ability to self-organize and to figure out the best way to accomplish what is going to produce the most value

Your team just needs to know what the objective is that they’re trying to achieve (any more control is a hindrance)

It is critically important for teams to understand the “why” behind what the objective is (if they do, 9/10 times they’ll produce the best results and the best value that they’re capable of!)

Instead of controlling or directing the workflow, leaders should be focusing on improving the environment in which people work, closing skill gaps, and removing organizational impediments

As a supervisor or tech lead, you should serve as a mentor or be there as a  resource for the team (i.e. a go-to point for team members if they get stuck or need some direction on finding resources that will help them do their work)

It’s important to be there as a support but not a person to direct day-to-day activities as a leader

Leaders at a program, VP, or portfolio level need to make sure that they’re supportive of an agile ecosystem

In David Marquet’s Turn the Ship Around!, he talks about intent-based leadership (where the team comes to leaders, not with a request for direction, but instead with a: “I intend to do x, y or x,” which gives the leader a chance to inquire if appropriate. Eventually, this leads to less checking as the team demonstrates competency and consistency of delivery)

Pivoting to intent-based leadership is only possible if the leader makes it clear what the outcome is that they’re expecting

How to balance giving your team room to grow with safety measures:

In taking a Scrum approach, there are many benefits (because the framework gives solid boundaries that allow for a good balance of self-organization and accountability)

Accountability to one another (and themselves) is created by having daily Scrums

The sprint review adds balance because nobody is going months at a time without feedback

There is a regimen within the flexibility that the Scrum framework provides

Mentioned in this Episode:

Quincy Jordan

Agile Coaches’ Corner Ep. 101: “Are Scrum Masters Expendable?”

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

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

In celebration of the two-year anniversary of the podcast, Dan Neumann is joined by Sam Falco, co-founder of the Agile Coaches’ Corner podcast. In the theme of continuous improvement, Dan and Sam take a look back on the last two years of the podcast and reflect on all that they’ve learned about podcasting and agility. They also invite on some of their favorite past guests and AgileThought colleagues to share their own biggest takeaways and lessons learned from the past two years on the theme of agility. Andrea Floyd, Agile Transformation Consultant; Adam Ulery, Senior Agile Coach; Quincy Jordan, Principal Transformation Consultant; Steven Granese, Managing Director of the Transform Practice; and Michael Guiler, Agile Consultant.

Key Takeaways

Andrea Floyd

Key lesson: the importance of the Agile mindset and an Agile culture coupled with any Agile journey

“What does it mean for us to be successful?” “What will that take from a mindset and culture perspective?” — Andrea Floyd

Tools and techniques: exercises around value stream mapping, understanding what value means to your customers and users, design-thinking techniques around customer journey mapping, good leadership, and commitment from the whole organization

Adam Ulery

Key lesson: the importance of having committed top-level leaders in an Agile transformation

The buy-in of leadership in a transformation is key (it makes the difference in creating real change or giving up)

Drawbacks that occur without leadership buy-in: change will only occur in small pockets at best, more than likely it will flounder and never transform the people and the way they work

Tools and techniques: in order for leaders to transform themselves they must be committed and willing, step out of their comfort zone, push through fears, and commit to change

In summary: it is important to have top-level leaders that are committed to the transformation and are committed to change

Quincy Jordan

Key lesson: Agile is Agile (it has transformed, evolved, and adapted over the years)

It used to be considered strictly for software development but has now been taken outside of IT; into HR, marketing, etc. The overall thinking has made a big splash in non-IT environments

A challenge with agility being adopted into non-IT environments: sometimes business and leadership have a misconception that agility is only IT so they believe it is not relevant to them

When agility ripples outside of IT, it can be really powerful

Michael Guiler

Key lesson: that the business side has really begun to take hold of agility

What has caused the shift from technology-driven agility to business-driven agility: the entire world has fundamentally begun to understand that agility is key (i.e. “We can’t just have really detail-oriented plans with a command and control structure and be able to compete in today’s world” — Michael Guiler)

Now, business wants to build an environment where they can really pivot on a dime and compete — and agility is the way to do that

Steven Granese

Key lesson: it is very difficult to define what agility is — especially with large organizations

There are a lot of different ideas and definitions about what agility is

It can be hard to define what problem the client is trying to solve and why agility would help them

How Steven has seen the problems that clients are trying to solve change over the years:

1) From a focus on speed (the speed with which they need to continuously adapt) to a focus on market changes (it’s the organizations that focus on market demands that are the ones having the most success)

2) There used to be more of a concern about leaning too much on tooling and automation but now it has become so good and there is so much more that is possible now due to the tools that are available

Sam Falco

Key lesson: Agility spreads beyond IT — even to a personal level 

“Even on a personal level, I have taken a lot of the principles and ideas — and even the practices of Scrum — into my own personal life. I use Scrum on a weekly basis; I do one-week sprints for myself.” — Sam Falco

Sam has lowered his personal work-in-progress limit from three to two and his throughput shot way up

He’s learned how to apply agility in all sorts of situations

Dan Neumann

Key lesson: the power of collaboration (specifically, the value of collaborating with people)

You can riff off each other if a client isn’t quite hearing what one of you is trying to say

Diversity of perspective is tremendously valuable (just like on any well-functioning team)

Mentioned in this Episode:

Steven Granese

Andrea Floyd

Adam Ulery

Quincy Jordan

Michael Guiler

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

Eric Landes

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

In celebration of the two-year anniversary of the podcast, Dan Neumann is joined by Sam Falco, co-founder of the Agile Coaches’ Corner podcast. In the theme of continuous improvement, Dan and Sam take a look back on the last two years of the podcast and reflect on all that they’ve learned about podcasting and agility. They also invite on some of their favorite past guests and AgileThought colleagues to share their own biggest takeaways and lessons learned from the past two years on the theme of agility. Andrea Floyd, Agile Transformation Consultant; Adam Ulery, Senior Agile Coach; Quincy Jordan, Principal Transformation Consultant; Steven Granese, Managing Director of the Transform Practice; and Michael Guiler, Agile Consultant.

Key Takeaways

Andrea Floyd

Key lesson: the importance of the Agile mindset and an Agile culture coupled with any Agile journey

“What does it mean for us to be successful?” “What will that take from a mindset and culture perspective?” — Andrea Floyd

Tools and techniques: exercises around value stream mapping, understanding what value means to your customers and users, design-thinking techniques around customer journey mapping, good leadership, and commitment from the whole organization

Adam Ulery

Key lesson: the importance of having committed top-level leaders in an Agile transformation

The buy-in of leadership in a transformation is key (it makes the difference in creating real change or giving up)

Drawbacks that occur without leadership buy-in: change will only occur in small pockets at best, more than likely it will flounder and never transform the people and the way they work

Tools and techniques: in order for leaders to transform themselves they must be committed and willing, step out of their comfort zone, push through fears, and commit to change

In summary: it is important to have top-level leaders that are committed to the transformation and are committed to change

Quincy Jordan

Key lesson: Agile is Agile (it has transformed, evolved, and adapted over the years)

It used to be considered strictly for software development but has now been taken outside of IT; into HR, marketing, etc. The overall thinking has made a big splash in non-IT environments

A challenge with agility being adopted into non-IT environments: sometimes business and leadership have a misconception that agility is only IT so they believe it is not relevant to them

When agility ripples outside of IT, it can be really powerful

Michael Guiler

Key lesson: that the business side has really begun to take hold of agility

What has caused the shift from technology-driven agility to business-driven agility: the entire world has fundamentally begun to understand that agility is key (i.e. “We can’t just have really detail-oriented plans with a command and control structure and be able to compete in today’s world” — Michael Guiler)

Now, business wants to build an environment where they can really pivot on a dime and compete — and agility is the way to do that

Steven Granese

Key lesson: it is very difficult to define what agility is — especially with large organizations

There are a lot of different ideas and definitions about what agility is

It can be hard to define what problem the client is trying to solve and why agility would help them

How Steven has seen the problems that clients are trying to solve change over the years:

1) From a focus on speed (the speed with which they need to continuously adapt) to a focus on market changes (it’s the organizations that focus on market demands that are the ones having the most success)

2) There used to be more of a concern about leaning too much on tooling and automation but now it has become so good and there is so much more that is possible now due to the tools that are available

Sam Falco

Key lesson: Agility spreads beyond IT — even to a personal level 

“Even on a personal level, I have taken a lot of the principles and ideas — and even the practices of Scrum — into my own personal life. I use Scrum on a weekly basis; I do one-week sprints for myself.” — Sam Falco

Sam has lowered his personal work-in-progress limit from three to two and his throughput shot way up

He’s learned how to apply agility in all sorts of situations

Dan Neumann

Key lesson: the power of collaboration (specifically, the value of collaborating with people)

You can riff off each other if a client isn’t quite hearing what one of you is trying to say

Diversity of perspective is tremendously valuable (just like on any well-functioning team)

Mentioned in this Episode:

Steven Granese

Andrea Floyd

Adam Ulery

Quincy Jordan

Michael Guiler

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

Eric Landes

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

In this episode, Dan Neumann is joined by a frequent guest of his and AgileThought colleague, Quincy Jordan! Quincy is a Principal Transformation Consultant and has been with AgileThought for almost three years.

Together, they will be exploring when things are going so well that you just don’t notice that there are problems bubbling beneath the surface. They address what kind of problems show up when teams become complacent due to things going so well, how to spot these problems (and address them) before they start, and how to differentiate between when things are going “so well that you don’t notice” and actually being on the right path.

Key Takeaways

The problems that arise when things are going so well that you don’t notice that they’re not:

When a Scrum Master is doing super well in their role, those outside the team or the leaders in the organization begin to question if they really need the role

However, if you remove that Scrum Master when the team is doing great and maturing well, things will continue in a downwards trajectory (the same way a car does when a tire goes flat)

It’s the classic scenario of “you’ve done your job too well” and others don’t realize how valuable and important that is

Sometimes the role of Scrum Master role is switched up or rotated in a way that doesn’t fully fill it and the wheels eventually fall off

When things are going well those who suffer from a hero complex lose the opportunity to be the hero anymore —  this can lead to situations such as:

When developers have an abnormal tolerance for tech debt (i.e. they are not paying as much attention to the quality of code or adhering to standards that are good for the team, which creates an abnormal amount of bugs that the team has to fix. Then, said developer jumps in as the hero)

I.e. Firefighters lighting fires to put them out

When things are going well there can be a tendency to start to question roles and processes (such as the Scrum Master role and the processes and organizational support that are in place to support the team/s)

When things are questioned, it can affect not only the team/s, but it also affects the organization as a whole

Both the team/s and the organization can become complacent if things are working so well

How to avoid getting trapped in this way of thinking:

Leadership should be constantly assessing whether or not they’re providing the right types of problems to solve

The team should be asking themselves if they’re looking at the right problems to solve

Is the team properly considering Horizons Two and Three if they are beginning to go down the path of the Three Horizons model?

Shift from “How much faster can the teams go?” and “How much more stuff can they deliver?” to “Are we delivering the right capabilities?”, “Are we delivering things customers want?”, and “Are we continuing to experiment and innovate?”

The wrong question is: “Can we get even more out of this team?” The right question is: “Can we make sure that we’re providing them with the right problems to solve?”; “Where can we, from a leadership standpoint, give more guidance to increase business value?”

How to differentiate between a mature and a complacent team:

Though they can sometimes look the same on the surface, a very complacent team will have far more carry-over stories than a mature team

Ask: ‘How well has this team challenged themselves in terms of their own velocity?’ and ‘Are they taking it upon themselves?’ A more mature team would exhibit these types of these behaviors as opposed to a complacent team

A more mature team makes time for continuous improvement and retrospectives whereas complacent teams make them cut them out or make them shorter

Mature teams dig deep and find opportunities to improve

Mature teams look below the surface and think more critically

Mentioned in this Episode:

Quincy Jordan

AgileThought Careers

Agile Coaches’ Corner Ep. 101: “Are Scrum Masters Expendable?”

Three Horizons by McKinsey & Company

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 AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!