Agile Coaches' Corner

In this bonus episode of the Agile Coaches’ Corner podcast, Christy Erbeck, Chief People Officer at AgileThought, is serving as your guest host for today’s conversation with Steven Granese and Quincy Jordan. Steven Granese is the Managing Director of AgileThought’s Transform Practice and Quincy Jordan serves as the Agile Competency Lead and Principal Transformation Consultant at AgileThought.

 

In their conversation today, they discuss scaling and transformations and how to effectively lead organizations towards business agility. They speak about the role of scaling in transformations, the challenges of scaling, opportunities that arise as an organization begins to scale, how to know when it is appropriate to help a client scale, and how to know when you’re on the right path with a transformation.

 

Key Takeaways

Transformation & scaling:

Part of a transformation is in transforming how people think

There are a number of ways to scale

Though it is called “scaling,” oftentimes it is about breaking down the problem into smaller pieces (especially in organizations that are already large)

A real transformation is an organizational transformation throughout all departments

The long term goal is to achieve business agility

Tips for getting clients started on their scaling or transformation journey:

Break down the problem into more manageable pieces in order to be able to take action on them and deliver faster (by delivering faster in these smaller increments you are setting expectations with stakeholders, which increases transparency and creates an outcome of more trust)

Buy-in is needed from leaders

Make sure to employ roadmaps with clients which can help with expectations

Clarity and guidance alleviate stress during the scaling process

Leaders need to address problems upfront when it comes to adopting agile

Asking the question “why” is critical for transformations; it has to be answered first (especially if you’re looking at a true transformation)

“Why are you doing this?”

“What is it that you’re trying to change?”

“Why are you trying to change?”

“Are you confronting real organizational challenges and problems that you have?”

Knowing what your client wants to focus on fundamentally changes how you work with them

Note: A true transformation will take time (sometimes years) and oftentimes, things will get worse before they get better

Differences between the two modes of adopting agile: Delivery and Transformation:

Ask: If you’re interested in adopting an agile way of working, are you focused on improving your delivery OR do you want a transformation (i.e. change the way your business fundamentally operates)?

Knowing which your client wants to do is critical

If your client just wants to improve their process and doesn’t believe anything is broken, they just want to improve their delivery

There is no right or wrong answer, but it is important to clarify what outcome they’re looking for as it will greatly impact how you help them

If a client wants 10–20% better output for their teams they’re looking at improving delivery

If a client wants to fundamentally look at the way their business operates, the types of customers they’re going after, the way their teams are structured, their financial incentives, etc. they are looking at a transformation

It’s important to determine when a client wants to achieve certain outcomes so you know whether to focus on improving delivery first vs. long-term transformation (that will lead to better delivery down the line)

Benefits of an agile transformation/achieving true business agility:

Being nimble, adaptable, and being able to react quickly to changes and demands from customers or the business

With the right culture and infrastructure in place, an organization is able to move very quickly when an unknown market shift happens (such as with COVID-19)

A true agile transformation allows an organization to be in a position that can weather any storm

Allows for better reactions to the unknown

True business agility helps the business be adaptable

Tips for leaders during a transformation:

Encourage the ability to learn, relearn, and unlearn — this is critical because companies may get stuck in their past successes, which limits their ability to learn new things and/or do things in a new way

Be courageous and vulnerable

Be a learner, not a knower

Continuously adapt and learn

Have a growth mindset in order to be able to help your people

Leaders need to ask themselves: “Am I clear as to where I’m going in the future?”, “Do I know why I’m trying to get there?”, and “Can I deliver in small increments and learn from the feedback?”

Have humility in understanding that everything can change in a second — so the ability to learn, unlearn, and relearn is critical (if you don’t, your business will become vulnerable to competitors)

 

Mentioned in this Episode:

Christy Erbeck’s LinkedIn

Quincy Jordan’s LinkedIn

Steven Granese’s LinkedIn

What Got You Here Won’t Get You There: How Successful People Become Even More Successful, by Marshall Goldsmith

Unlearn: Let Go of Past Success to Achieve Extraordinary Results, by Barry O’Reilly

Start with Why: How Great Leaders Inspire Everyone to Take Action, by Simon Sinek

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

 

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 AgileThought colleague and frequent guest of the show, Quincy Jordan. Quincy has been with AgileThought for just over two years as a principal transformation consultant and agile competency lead. Prior to AgileThought, Quincy was the transformation lead for Pivotal’s Atlanta office, where he consulted with clients to help them reach enterprise scale. He has also served as a principal consultant and agile coach at SCRUMstudy.com for over six years.

 

In their discussion today, Dan and Quincy explore the topic of culture as related to agile transformations. They define what culture is, why it is important, how it factors into agile transformations, and how to begin addressing it as an organization. Quincy also shares how to become more intentional about addressing culture early on as the company is moving toward a more agile way of working, the outcomes of being unintentional about addressing culture challenges, and additional tips and takeaways that are critical to keeping in mind when addressing culture.

 

Key Takeaways

What does ‘culture’ refer to?

A combination of the values, habits, and norms within a group or organization

The values that are present in everything that your organization does

It applies to any organization (whether it’s a religious institution, your family unit, company, etc.)

Can be characterized as “The way things happen around here” or “How we do things around here”

Quincy’s advice regarding how culture factors into agile transformations:

Culture cannot come last; if you want the ‘machine to run well’ and address the culture after, you have created a culture that says, “The machine is more important than the culture”

If a specific habit, such as courage, is not encouraged, you are building cultural debt; i.e., it will become more and more difficult for courage to be expressed

It is important to be intentional about culture upfront and incorporate it into your transformation as part of your strategy

If you don’t want certain habits to be a part of the culture, you have to intentionally set a new structure for everyone to transition to (otherwise it will continue to be pervasive)

Outcomes of being unintentional about addressing culture challenges:

If you’re not intentional about the culture and you develop a culture by default, it is likely to be riddled with cultural debt

If you don’t address having the proper culture that you want up front, you are going to have a mismatch of what you currently have and what it is that you really want

If the team/s are checklist-driven then they won’t have the opportunity to help the culture be values-driven

How to be more intentional about addressing culture early on as the company is moving toward a more agile way of working:

Ask: “Are we involving the teams in the actual planning or are they being given plans and milestones that they’re expected to hit without participating in the creation of those plans?”

Ask: “Is our culture checklist-driven rather than values-driven?”

The team/s should be involved in understanding what’s drawing value so they can better help accomplish the work that needs to be done for the values to be there

Set the culture upfront

Figure out the things that you are and are not aligned to as an organization

Decide on where the values lie and what they would be (ask individuals and teams: “What are the things that we value?”)

Have teams and individuals fill in the blank: “It really agitates me when _________.” It helps make clear what things affect their value system

Do a team working agreement where you establish what the values are

Once you establish what the values are, ask: “How can we act on these values?” and “What are the things that we can do, day-in and day-out, to express that those are our values?”

For example, if the value is: “Everyone has a voice,” then you need to provide opportunities for individuals to have their voice heard

Additional culture tips and takeaways:

You need to be intentional and know what your values are so that you can drive towards them (and be intentional about not allowing those values to be encroached upon)

If you address culture upfront, then you’re putting the organization in a position where you’re helping to impact the decision-making

Addressing the culture upfront helps the organization work towards their overall vision

It is important to have people within the organization that are carrying the culture forward so that when others are unsure/confused, they can look to those people

 

Mentioned in this Episode:

The Reengineering Alternative, by William E. Schneider

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

Science of Running: Analyze your Technique, Prevent Injury, Revolutionize your Training, by Chris Napier

 

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 AgileThought colleague and frequent guest of the show, Quincy Jordan. Quincy has been with AgileThought for just over two years as a principal transformation consultant and agile competency lead. Prior to AgileThought, Quincy was the transformation lead for Pivotal’s Atlanta office, where he consulted with clients to help them reach enterprise scale. He has also served as a principal consultant and agile coach at SCRUMstudy.com for over six years.

 

In their discussion today, Dan and Quincy explore the topic of culture as related to agile transformations. They define what culture is, why it is important, how it factors into agile transformations, and how to begin addressing it as an organization. Quincy also shares how to become more intentional about addressing culture early on as the company is moving toward a more agile way of working, the outcomes of being unintentional about addressing culture challenges, and additional tips and takeaways that are critical to keeping in mind when addressing culture.

 

Key Takeaways

What does ‘culture’ refer to?

A combination of the values, habits, and norms within a group or organization

The values that are present in everything that your organization does

It applies to any organization (whether it’s a religious institution, your family unit, company, etc.)

Can be characterized as “The way things happen around here” or “How we do things around here”

Quincy’s advice regarding how culture factors into agile transformations:

Culture cannot come last; if you want the ‘machine to run well’ and address the culture after, you have created a culture that says, “The machine is more important than the culture”

If a specific habit, such as courage, is not encouraged, you are building cultural debt; i.e., it will become more and more difficult for courage to be expressed

It is important to be intentional about culture upfront and incorporate it into your transformation as part of your strategy

If you don’t want certain habits to be a part of the culture, you have to intentionally set a new structure for everyone to transition to (otherwise it will continue to be pervasive)

Outcomes of being unintentional about addressing culture challenges:

If you’re not intentional about the culture and you develop a culture by default, it is likely to be riddled with cultural debt

If you don’t address having the proper culture that you want up front, you are going to have a mismatch of what you currently have and what it is that you really want

If the team/s are checklist-driven then they won’t have the opportunity to help the culture be values-driven

How to be more intentional about addressing culture early on as the company is moving toward a more agile way of working:

Ask: “Are we involving the teams in the actual planning or are they being given plans and milestones that they’re expected to hit without participating in the creation of those plans?”

Ask: “Is our culture checklist-driven rather than values-driven?”

The team/s should be involved in understanding what’s drawing value so they can better help accomplish the work that needs to be done for the values to be there

Set the culture upfront

Figure out the things that you are and are not aligned to as an organization

Decide on where the values lie and what they would be (ask individuals and teams: “What are the things that we value?”)

Have teams and individuals fill in the blank: “It really agitates me when _________.” It helps make clear what things affect their value system

Do a team working agreement where you establish what the values are

Once you establish what the values are, ask: “How can we act on these values?” and “What are the things that we can do, day-in and day-out, to express that those are our values?”

For example, if the value is: “Everyone has a voice,” then you need to provide opportunities for individuals to have their voice heard

Additional culture tips and takeaways:

You need to be intentional and know what your values are so that you can drive towards them (and be intentional about not allowing those values to be encroached upon)

If you address culture upfront, then you’re putting the organization in a position where you’re helping to impact the decision-making

Addressing the culture upfront helps the organization work towards their overall vision

It is important to have people within the organization that are carrying the culture forward so that when others are unsure/confused, they can look to those people

 

Mentioned in this Episode:

The Reengineering Alternative, by William E. Schneider

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

Science of Running: Analyze your Technique, Prevent Injury, Revolutionize your Training,
by Chris Napier

 

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 bonus episode of the Agile Coaches’ Corner podcast, Christy Erbeck, the Chief People Officer at AgileThought, is serving as your guest host for today’s conversation with Dr. Jerry Smith.

In their conversation today, they discuss how to make AI work for your enterprise. Dr. Jerry Smith explains why understanding causality is critical for AI-driven business transformation and how data science and analytics can help enterprise clients transform and become the digital winners that they desire to be.

Key Takeaways

• How AgileThought aids enterprises in understanding AI-driven business transformation:
  • Come up with a working set of definitions for AI, machine learning, and data science
• How AgileThought helps their enterprise clients solve their problems:
  •  The question: “What is data?” should be asked (Dr. Jerry Smith’s answer: “Data is the debris of human activity; it’s because of us, not in spite of us”)
    • Note: Data is not just spontaneously created in your data systems; it’s created from an application which captures an interaction between a human being (you, your customers, or your admins/salespeople) and that system
    • Note: The data we see is because of human actions
  • When we look at our capabilities, we should be asking the fundamental question: “What data in our enterprise is causal to our business outcomes?”
    •  For example, ask: “What data that you have spent time collecting is directly causing your revenue to perform the way it does?”
  • The very first thing to ask is: “What is causal?”
    • Once you know the causal data, you can go back to the application and the human and say, “How do I change the human behavior so that the application picks up the new behavior and changes the data?” This result is causal-based data engineering for AI, and is the only way to change your organization
• AgileThought helps companies institutionalize data science, machine learning, and AI at the enterprise level by breaking down the process (as shown below), so that each and every process resides in infrastructure and a set of capabilities
  • There are three kinds of data: Your enterprise, your IT, and your opensource – the goal is to get this data into a single machine learning record
  • This single machine learning record is critical in showing all of the variables in columns and observations in rows – from there, you can do basic analytics, and then, data science
  • Data scientists make sense of the data and create models out of the data, so the data no longer has to be used
  • In the machine learning phase, data scientists try to predict what these models are trying to do and how they’re going to change under certain variables
    • Note: AI is about prescriptions; making decisions
    • Note: The biggest value is not in generating or reading reports; it is in making an appropriate decision based on these reports

About Dr. Jerry Smith: Dr. Jerry Smith is AgileThought’s Managing Director of Analytics and Data Science. As a practicing AI & Data Scientist, thought leader, innovator, speaker, author, and philanthropist, Dr. Jerry Smith is dedicated to advancing and transforming businesses through evolutionary computing, enterprise AI and data sciences, machine learning, and causality.

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 bonus episode of the Agile Coaches’ Corner podcast, Christy Erbeck, the Chief People Officer at AgileThought, is serving as your guest host for today’s conversation with Dr. Jerry Smith.

In their conversation today, they discuss how to make AI work for your enterprise. Dr. Jerry Smith explains why understanding causality is critical for AI-driven business transformation and
how data science and analytics can help enterprise clients transform and become the digital winners that they desire to be.

Key Takeaways

• How AgileThought aids enterprises in understanding AI-driven business transformation:
  • Come up with a working set of definitions for AI, machine learning, and data science
• How AgileThought helps their enterprise clients solve their problems:
  •  The question: “What is data?” should be asked (Dr. Jerry Smith’s answer: “Data is the debris of human activity; it’s because of us, not in spite of us”)
    • Note: Data is not just spontaneously created in your data systems; it’s created from an application which captures an interaction between a human being (you, your customers, or your admins/salespeople) and that system
    • Note: The data we see is because of human actions
  • When we look at our capabilities, we should be asking the fundamental question: “What data in our enterprise is causal to our business outcomes?”
    •  For example, ask: “What data that you have spent time collecting is directly causing your revenue to perform the way it does?”
  • The very first thing to ask is: “What is causal?”
    • Once you know the causal data, you can go back to the application and the human and say, “How do I change the human behavior so that the application picks up the new behavior and changes the data?” This result is causal-based data engineering for AI, and is the only way to change your organization
• AgileThought helps companies institutionalize data science, machine learning, and AI at the enterprise level by breaking down the process (as shown below), so that each and every process resides in infrastructure and a set of capabilities
  • There are three kinds of data: Your enterprise, your IT, and your opensource – the goal is to get this data into a single machine learning record
  • This single machine learning record is critical in showing all of the variables in columns and observations in rows – from there, you can do basic analytics, and then, data science
  • Data scientists make sense of the data and create models out of the data, so the data no longer has to be used
  • In the machine learning phase, data scientists try to predict what these models are trying to do and how they’re going to change under certain variables
    • Note: AI is about prescriptions; making decisions
    • Note: The biggest value is not in generating or reading reports; it is in making an appropriate decision based on these reports

About Dr. Jerry Smith: Dr. Jerry Smith is AgileThought’s Managing Director of Analytics and Data Science. As a practicing AI & Data Scientist, thought leader, innovator, speaker, author, and philanthropist, Dr. Jerry Smith is dedicated to advancing and transforming businesses through evolutionary computing, enterprise AI and data sciences, machine learning, and causality.

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, Professional Scrum Trainer Eric Landes addresses the questions: "How do you measure a Scrum Team's Performance?"

What Does the Scrum Guide say About Measuring Performance?

In many of our Scrum classes, the issue of measuring performance is asked about how can we measure a Scrum team's performance. It is a good question that the Scrum guide does give some information on the guide states that one of the inputs of Sprint planning is past performance of the development team. It also States that the daily Scrum optimizes team collaboration and performance by inspecting work. In these two statements, we learn that Scrum does want to help optimize team's performance. So how do we measure that though? When we go back to our question, let's talk about why we should measure a Scrum team's performance as the Scrum Guide mentions, we do need that as an input to Sprint planning.

Velocity is not the Best Measure

For this input, many teams use a velocity chart. A team's velocity chart to understand past performance. And this is a complimentary practice to Scrum. It's not actually asked for in the Scrum Guide or prescribed. But it is one well-established way to measure performance along with Sprint burndown charts and release burndown charts. I find that velocity may not be the best measure.

Use Kanban Metrics to Measure and Forecast

If this question is more about helping the team understand and communicate delivery performance, there are tools like cumulative flow charts and throughput that could be used. These metrics come from a Kanban perspective and these tools help teams understand their flow and can be used to communicate forecasts.

For instance, your team may have a throughput of one PBI done each day. Just as an example, as a for instance, while using the past metrics are never one hundred percent accurate. It can help teams as they go into Sprint planning and Kanban even gives you a forecasting method called Monte Carlo simulations that can help with this. Now this is a complex topic for sure, but the main purpose of this Trainer Talk is to introduce you to concepts beyond team velocity charts, and burndown charts.

Many Kanban metrics can be used to help teams understand their delivery capabilities better and achieve a flow that many mature teams are hallmarks of many mature teams. Scrum.org even has a class called Professional Scrum with Kanban that teaches participants to get to that flow and to help measure that flow.

Find What Works for Your Team

If you are interested in different ways to measure a Scrum team's performance, I urge you to check out some of these other metrics. There is no one size fits all. So, make sure it works for your team and self-organize around the way your team measures performance.

Want to Learn More or Get in Touch?

Register for our upcoming web meetings by visiting agilethought.com/events

See available training courses at agilethought.com/training.

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

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

In this episode, Professional Scrum Trainer Eric Landes addresses the questions: "How do you measure a Scrum Team's Performance?"

What Does the Scrum Guide say About Measuring Performance?

In many of our Scrum classes, the issue of measuring performance is asked about how can we measure a Scrum team's performance. It is a good question that the Scrum guide does give some information on the guide states that one of the inputs of Sprint planning is past performance of the development team. It also States that the daily Scrum optimizes team collaboration and performance by inspecting work. In these two statements, we learn that Scrum does want to help optimize team's performance. So how do we measure that though? When we go back to our question, let's talk about why we should measure a Scrum team's performance as the Scrum Guide mentions, we do need that as an input to Sprint planning.

Velocity is not the Best Measure

For this input, many teams use a velocity chart. A team's velocity chart to understand past performance. And this is a complimentary practice to Scrum. It's not actually asked for in the Scrum Guide or prescribed. But it is one well-established way to measure performance along with Sprint burndown charts and release burndown charts. I find that velocity may not be the best measure.

Use Kanban Metrics to Measure and Forecast

If this question is more about helping the team understand and communicate delivery performance, there are tools like cumulative flow charts and throughput that could be used. These metrics come from a Kanban perspective and these tools help teams understand their flow and can be used to communicate forecasts.

For instance, your team may have a throughput of one PBI done each day. Just as an example, as a for instance, while using the past metrics are never one hundred percent accurate. It can help teams as they go into Sprint planning and Kanban even gives you a forecasting method called Monte Carlo simulations that can help with this. Now this is a complex topic for sure, but the main purpose of this Trainer Talk is to introduce you to concepts beyond team velocity charts, and burndown charts.

Many Kanban metrics can be used to help teams understand their delivery capabilities better and achieve a flow that many mature teams are hallmarks of many mature teams. Scrum.org even has a class called Professional Scrum with Kanban that teaches participants to get to that flow and to help measure that flow.

Find What Works for Your Team

If you are interested in different ways to measure a Scrum team's performance, I urge you to check out some of these other metrics. There is no one size fits all. So, make sure it works for your team and self-organize around the way your team measures performance.

Want to Learn More or Get in Touch?

Register for our upcoming web meetings by visiting agilethought.com/events

See available training courses at agilethought.com/training.

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

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

In today’s ‘solocast’ of the Agile Coaches’ Corner, Dan Neumann is exploring the art of metaphors. Metaphors can be a powerful tool to illustrate important ideas and concepts of agility — if used well.

 

Dan shares the pros and cons of using metaphors in an agile setting, how to use them effectively whatever your role may be, and how metaphors can be a really powerful tool to add to your arsenal, regardless of what level you’re at in the organization and who you’re trying to communicate with.

 

Key Takeaways

What is a metaphor?

A metaphor is a way of using a concrete image/example to help connect to an abstract thought

Taking an abstract idea like agility and then comparing it to something that is very concrete

Metaphors help us connect abstract things to familiar ideas

Examples: “All the world is a stage.” — Shakespeare, “Life is like a box of chocolates.” — Forrest Gump

What to keep in mind when using metaphors:

Be aware that we can sometimes bring in biases and/or unintended constraints that are not helpful

Using a metaphor may impact the way a person is looking to solve a problem

The way in which a metaphor is used is going to affect the way that someone is going to think about different problems

Common (and not-so-common) agility metaphors:

An 8-hour endurance race (where the goal is to see how many miles you can go in a set amount of time) can be compared to an agile software development project

Building a car as compared to product development (the metaphor of construction helps to connect the thought of agility with regard to transportation)

Agile gardening vs. Agile farming (illustrates the contextual differences when you’re doing small-scale agility [the gardening] vs. commercial, industrial-scale agility [farming])

Sailboat (a metaphor technique used in retrospectives): i.e. “What are the fair winds that are blowing your boat across the water?” and “What are the anchors?” (i.e. what is keeping your boat moving forward to its destination)

Metaphors can also be used to show where agility does not make sense (i.e. you don’t exactly want a McDonald’s lineworker being agile when they’re making your burger; you want the same burger every time you go there)

House metaphors: “If you’re building a house you have to build a solid foundation” and “You wouldn’t build a house one room at a time” (these can be good for user stories as well as illustrating the desire for pre-planning)

Pros

Metaphors are powerful in that they cause the brain to react differently

Metaphors can help teams move away from a really concrete way of thinking about a problem to a much more abstract way, unlocking some new potential

There are lots of different ways of using metaphors to help connect people to this abstract concept of agility

Cons

An issue with metaphors is that they can sometimes be militaristic (i.e. using military metaphors, such as those seen in Team of Teams)

Some metaphors bring in gender biases (i.e. “don’t get your panties in a twist”) — this baggage is not appropriate and brings in stereotypes

Metaphors about games and sports (because agility isn’t a win/lose scenario)

Art metaphors — not everyone will be able to relate to the message (it’s important to be aware of your audience)

Imagining your team as a machine in a metaphor can bring in some constraints you don’t necessarily want

 

Mentioned in this Episode:

“How the brain finds meaning in metaphor,” ScienceDaily

“Through Their Own Words: Towards a New Understanding of Leadership Through Metaphors”

“Why Metaphors Are Important: Metaphors are not just a literary technique; they are a psychological technique”

“The Power of Metaphors in Communication”

Team of Teams: New Rules of Engagement for a Complex World, by Stanley McChrystal with Chris Fussell, Tantum Collins, and David Silverman

 

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 today’s ‘solocast’ of the Agile Coaches’ Corner, Dan Neumann is exploring the art of metaphors. Metaphors can be a powerful tool to illustrate important ideas and concepts of agility — if used well.

 

Dan shares the pros and cons of using metaphors in an agile setting, how to use them effectively whatever your role may be, and how metaphors can be a really powerful tool to add to your arsenal, regardless of what level you’re at in the organization and who you’re trying to communicate with.

 

Key Takeaways

What is a metaphor?

A metaphor is a way of using a concrete image/example to help connect to an abstract thought

Taking an abstract idea like agility and then comparing it to something that is very concrete

Metaphors help us connect abstract things to familiar ideas

Examples: “All the world is a stage.” — Shakespeare, “Life is like a box of chocolates.” — Forrest Gump

What to keep in mind when using metaphors:

Be aware that we can sometimes bring in biases and/or unintended constraints that are not helpful

Using a metaphor may impact the way a person is looking to solve a problem

The way in which a metaphor is used is going to affect the way that someone is going to think about different problems

Common (and not-so-common) agility metaphors:

An 8-hour endurance race (where the goal is to see how many miles you can go in a set amount of time) can be compared to an agile software development project

Building a car as compared to product development (the metaphor of construction helps to connect the thought of agility with regard to transportation)

Agile gardening vs. Agile farming (illustrates the contextual differences when you’re doing small-scale agility [the gardening] vs. commercial, industrial-scale agility [farming])

Sailboat (a metaphor technique used in retrospectives): i.e. “What are the fair winds that are blowing your boat across the water?” and “What are the anchors?” (i.e. what is keeping your boat moving forward to its destination)

Metaphors can also be used to show where agility does not make sense (i.e. you don’t exactly want a McDonald’s lineworker being agile when they’re making your burger; you want the same burger every time you go there)

House metaphors: “If you’re building a house you have to build a solid foundation” and “You wouldn’t build a house one room at a time” (these can be good for user stories as well as illustrating the desire for pre-planning)

Pros

Metaphors are powerful in that they cause the brain to react differently

Metaphors can help teams move away from a really concrete way of thinking about a problem to a much more abstract way, unlocking some new potential

There are lots of different ways of using metaphors to help connect people to this abstract concept of agility

Cons

An issue with metaphors is that they can sometimes be militaristic (i.e. using military metaphors, such as those seen in Team of Teams)

Some metaphors bring in gender biases (i.e. “don’t get your panties in a twist”) — this baggage is not appropriate and brings in stereotypes

Metaphors about games and sports (because agility isn’t a win/lose scenario)

Art metaphors — not everyone will be able to relate to the message (it’s important to be aware of your audience)

Imagining your team as a machine in a metaphor can bring in some constraints you don’t necessarily want

 

Mentioned in this Episode:

“How the brain finds meaning in metaphor,” ScienceDaily

“Through Their Own Words: Towards a New Understanding of Leadership Through Metaphors”

“Why Metaphors Are Important: Metaphors are not just a literary technique; they are a psychological technique”

“The Power of Metaphors in Communication”

Team of Teams: New Rules of Engagement for a Complex World, by Stanley McChrystal with Chris Fussell, Tantum Collins, and David Silverman

 

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 not one — but two! — AgileThought Colleagues; Quincy Jordan and Christy Erbeck!

 

In their conversation today, Dan, Quincy, and Christy discuss the key qualities to look for when bringing a new Scrum Master into your organization. They discuss the important characteristics you should be on the lookout for, the key skillsets, important soft skills, and some of the qualifiers (and disqualifiers!). They also share what to pay attention to when hiring, red flags to watch out for, and insightful questions you can ask during the interview process to make sure they’re a good fit.

 

Key Takeaways

What to consider when beginning to look for a Scrum Master:

Key characteristics

Skillsets

Soft skills

Qualifiers and disqualifiers

Good qualities:

Humbleness — they focus on the betterment of the team rather than shining the limelight on themselves

They are a servant leader

A capacity to focus on the strengths of others

A good balance of leadership and humility

Open to feedback

They have a growth mindset

They are a learner; not a knower

They come from a place of curiosity vs. judgment

What to pay attention to when hiring:

They understand the five Scrum values

Mastery of the Scrum guide

They are staying up-to-date on the Scrum framework

They purposefully model the behaviors and values of Scrum

Listen to how they use their words; i.e. are they phrasing from a competitive standpoint or a collaborative standpoint? Are they phrasing from a comparative standpoint or an inclusion standpoint?

They should have stories and anecdotes of how they have applied the Scrum guide in real life

They should take on the role of a Maestro rather than a ‘Master’

In the interview process, identify how they apply values, think through problems, and how they recover and ‘rise strong’ from a failure

If they don’t have any certifications, inquire why that is and how they have self-taught

If they do have certifications, ask when they received them and what they have done with them since

Ask how they are participating in the agile community in their area

Disqualifiers:

Humility to the point where they are not actually leading anything

Having too much knowledge and have a hard time pulling their weight from their own experience/knowledge and not allow the team to determine the ‘how’ for themselves

They are not open to self-evaluation or evaluation from others

They have a fixed mindset

They are a knower; not a learner

Misconceptions:

Do not assume that you can take all of your project managers and turn them into Scrum Masters

“We need a very technical person to be a Scrum Master” — untrue; in many cases, a less technical person makes a better Scrum Master

 

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!