Agile Coaches' Corner

Today, Dan Neumann and Sam Falco are exploring the topic of teams — and not just Scrum teams, but all teams.

 

As a leader, it can be difficult to manage many lines of communication — especially in larger teams. In Dan and Sam’s conversation, they discuss The Tuckman Model as a thinking framework on how to nurture high-performing teams. From forming to storming to norming and performing, The Tuckman Model lays out the manner in which a leader should engage with teams to become more effective than ever before.

 

Tune in for today’s episode to find out which strategies you can put into play right now to build, lead, and maintain better teams!

 

“A team has shared success or failure. One person can’t succeed [while] another person fails if you’re an actual team. You win or you lose together.” — Sam Falco

 

Key Takeaways

What is a team?

A handful of people who are all working toward a common goal/objective and are collaborating/working together

A team has shared success and failure; You win or you lose together

Challenges with larger teams:

They tend to get siloed; i.e., a bunch of people is working individually or smaller teams are formed within the larger team and communication is lost

With a large group, even with the best intentions, someone gets left out (i.e. someone forgets to tell someone something or is unaware that someone hasn’t heard certain information yet)

Increments can be missed if you’re not collaborating and communicating as a team

How to (and how not to) form a team:

The best teams self-select (people with a stake in the project are much more motivated) 

If you select random people and put them together in a team they may not function that well together

In “The Tuckman Model,” Bruce Tuckman suggests that you need four stages (form, storm, norm, and perform) to tackle tough problems and deliver results as a team

Leadership strategies for forming teams (Tuckman’s “forming” phase):

It’s important to create a shared vision once a team is formed and then actively move towards fostering connections through being vulnerable and demonstrating vulnerability through group formation activities

As a leader, it is your duty to pick the team with purpose; not availability

If you’re stuck in the “form” stage, it damages the ability of team members to form the connections that are necessary for teamwork

Make sure that the team develops a shared mental image of what their team is like (you could start with something as simple as picking a team name)

Leadership strategies for addressing conflict within teams (Tuckman’s “storming” phase):

Conflict is not inherently negative but many people have never experienced healthy conflict so it is important to look for ways to build trust

As a leader, you have to transition to a “coaching” role when your teams are in a storming phase by helping them develop mutual trust, navigate organizational impediments and conflict, and discussing team working agreements that you can refer to

Storming often happens when it is not clear how the team makes decisions (so it is important to find clarity on this early on)

Try out the “7 Levels in Delegation Poker Group” activity, linked below

Leadership strategies during a team’s “norming” phase:

In this phase, teams identify common goals and work toward these common goals with standards and commitment

The leader’s role shifts more to empowering their team and getting feedback

In this phase, a leader should allow for leadership to emerge within the team (and not being the leader all the time)

It’s important to find the balance in contributing and knowing when to allow the team to get somewhere on their own

In this stage, it is crucial to maintain the trust that you built during the “forming” and “storming” phases

Leadership strategies during a team’s “performing” phase:

Once there’s trust and the team can engage in healthy conflict, it is important to focus on goals and new areas that will benefit the team and business

Once team members can hold each other accountable in a healthy way then you can established shared goals, make a commitment to these shared goals, and achieve these shared goals as a team

After accountability is established, improvement can be built upon that

Characteristics of a good leader:

They help a team make their decisions

They help a team develop mutual trust

They identify what behaviors of The Tuckman Model the team is exhibiting and then appropriately engage with the team members

They consciously build their team and find techniques that work best with them

 

Mentioned in this Episode:

Lines of Communication (Image)

Esther DerbyBruce Tuckman — The Tuckman Model

7 Levels in Delegation Poker Group Activity

The Five Dysfunctions of a Team: A Leadership Fable, by Patrick Lencioni

Agile Coaches’ Corner Ep. 117: “Don’t Get Your Agile Shorts in a Knot”

Humanocracy: Creating Organizations as Amazing as the People Inside Them, by Gary Hamel and Michele Zanini

 

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!

This week, Dan Neumann is joined by two fellow AgileThought colleagues — Sam Falco, a Principal Trainer, and M.C. Moore, a Team Agile Coach.

Together, they explore the topic of Scrum mastery — specifically, being a Scrum Master new into an organization. There’s a lot of excitement — but also many potential pitfalls — that come with entering a new group as a Scrum Master. And as someone who joined AgileThought just six months ago, M.C. Moore, in particular, has a lot of experience in this area! He shares his top tips on what to do as you enter a new organization to build trust and vulnerability, how to break the ice with a new team, how to navigate the challenges that come along with entering a new organization that may be doing Scrum differently than you’re used to, and more.

 

Be sure to tune in as M.C., Sam, and Dan offer their insights on what to do when you enter a new company (that you won’t find in the Scrum guide!)

 

Key Takeaways

Tips for a Scrum Master that is entering a new organization:

Start by listening (we all have preconceived notions but it is key to first listen)

Be open to changes and be ready for a journey

Set expectations and prep for change

Have an openness to learn and hear from the team (especially with their “whys”)

It is important to get feedback from a team when you step into a new culture

It is also key to share (ideas: share a mind map about you, hold an AMA session, etc.)

Hold fun/game events (helps break the ice and brings teams together) — anything that brings the teams closer and have them see that you’re human too are great in helping you all work toward the same goal/s

“If you’re not having fun in the team, there’s a problem somewhere.” — Dan Neumann

Show vulnerability — vulnerability is a huge component of trust, and trust is the foundation of healthy conflict (if you don’t have healthy conflict, you just have conflict)

Reach out to get to know who they are; show a genuine interest and ask about themselves

Tips for a Scrum Master that is new into an organization that is doing Scrum differently than what they’re used to:

Pick and choose your “battles”

Ask “why” and counter with your “why” for those that have only learned Scrum halfway (“Is this working for you?”, “Are you getting value out of this?”, “Or what value do you expect to be getting out of this?”)

You need to crawl before you walk (oftentimes, people end up putting themselves in a bad spot because they see areas for opportunities and try to take on too much, too quickly, which creates resistance)

Start with (if possible) at least a couple of hours going over the Scrum framework and the “whys” of it so that the team/s understand

If you are not able to start with the above statement, teach as you go (it’s important to take pauses and go through the fundamentals rather than rush everyone through and overwhelm the team/s)

The most successful team start-ups start with the person who would eventually become the Product Owner saying, “We’re not delivering, would Scrum work? Can you come talk to my team?” Blocking off the entire afternoon, and inviting everyone (including stakeholders) so that everyone is on the same page

Tips for Scrum Masters around lifelong learning VS. learning Scrum once:

Lifelong/continuous learning is crucial, especially in a setting where you’re moving from one organization to another

Continuous learning provides you with that “reset” when you entire into a new organization because you’re always staying current with industry knowledge

It’s easy to become comfortable if you’ve worked with your current company for a while but it is part of your evolution to progress forward and stay current

Read books and stay inspired

Go outside your four walls (such as attending virtual meetups or joining a Scrum Masters Guild) — the infusion of external ideas into your organization is invaluable

Differences in being a Scrum Master new to an organization working in a scaled environment vs. a not-scaled environment:

Many differences are organizational in nature

Working with a standalone Scrum team you’ll have a bit more flexibility to do things differently

 

Mentioned in this Episode:

M.C. Moore’s LinkedIn

Sam Falco’s LinkedIn

Agile Coaches’ Corner Ep. 115: “Scrum Mastership: Patterns and Practices vs. Principles”

Tampa Bay Scrum Masters Guild

SAFe

Esther Derby

A Handful of Earth, A Handful of Sky: The World of Octavia Butler, by Lynell George

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, by Adkins Lyssa

Console Wars: Sega, Nintendo, and the Battle that Defined a Generation, by Blake J. Harris

 

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!

This week, Dan Neumann is joined by two fellow AgileThought colleagues — Sam Falco, a Principal Trainer, and M.C. Moore, a Team Agile Coach.

Together, they explore the topic of Scrum mastery — specifically, being a Scrum Master new into an organization. There’s a lot of excitement — but also many potential pitfalls — that come with entering a new group as a Scrum Master. And as someone who joined AgileThought just six months ago, M.C. Moore, in particular, has a lot of experience in this area! He shares his top tips on what to do as you enter a new organization to build trust and vulnerability, how to break the ice with a new team, how to navigate the challenges that come along with entering a new organization that may be doing Scrum differently than you’re used to, and more.

 

Be sure to tune in as M.C., Sam, and Dan offer their insights on what to do when you enter a new company (that you won’t find in the Scrum guide!)

 

Key Takeaways

Tips for a Scrum Master that is entering a new organization:

Start by listening (we all have preconceived notions but it is key to first listen)

Be open to changes and be ready for a journey

Set expectations and prep for change

Have an openness to learn and hear from the team (especially with their “whys”)

It is important to get feedback from a team when you step into a new culture

It is also key to share (ideas: share a mind map about you, hold an AMA session, etc.)

Hold fun/game events (helps break the ice and brings teams together) — anything that brings the teams closer and have them see that you’re human too are great in helping you all work toward the same goal/s

“If you’re not having fun in the team, there’s a problem somewhere.” — Dan Neumann

Show vulnerability — vulnerability is a huge component of trust, and trust is the foundation of healthy conflict (if you don’t have healthy conflict, you just have conflict)

Reach out to get to know who they are; show a genuine interest and ask about themselves

Tips for a Scrum Master that is new into an organization that is doing Scrum differently than what they’re used to:

Pick and choose your “battles”

Ask “why” and counter with your “why” for those that have only learned Scrum halfway (“Is this working for you?”, “Are you getting value out of this?”, “Or what value do you expect to be getting out of this?”)

You need to crawl before you walk (oftentimes, people end up putting themselves in a bad spot because they see areas for opportunities and try to take on too much, too quickly, which creates resistance)

Start with (if possible) at least a couple of hours going over the Scrum framework and the “whys” of it so that the team/s understand

If you are not able to start with the above statement, teach as you go (it’s important to take pauses and go through the fundamentals rather than rush everyone through and overwhelm the team/s)

The most successful team start-ups start with the person who would eventually become the Product Owner saying, “We’re not delivering, would Scrum work? Can you come talk to my team?” Blocking off the entire afternoon, and inviting everyone (including stakeholders) so that everyone is on the same page

Tips for Scrum Masters around lifelong learning VS. learning Scrum once:

Lifelong/continuous learning is crucial, especially in a setting where you’re moving from one organization to another

Continuous learning provides you with that “reset” when you entire into a new organization because you’re always staying current with industry knowledge

It’s easy to become comfortable if you’ve worked with your current company for a while but it is part of your evolution to progress forward and stay current

Read books and stay inspired

Go outside your four walls (such as attending virtual meetups or joining a Scrum Masters Guild) — the infusion of external ideas into your organization is invaluable

Differences in being a Scrum Master new to an organization working in a scaled environment vs. a not-scaled environment:

Many differences are organizational in nature

Working with a standalone Scrum team you’ll have a bit more flexibility to do things differently

 

Mentioned in this Episode:

M.C. Moore’s LinkedIn

Sam Falco’s LinkedIn

Agile Coaches’ Corner Ep. 115: “Scrum Mastership: Patterns and Practices vs. Principles”

Tampa Bay Scrum Masters Guild

SAFe

Esther Derby

A Handful of Earth, A Handful of Sky: The World of Octavia Butler, by Lynell George

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, by Adkins Lyssa

Console Wars: Sega, Nintendo, and the Battle that Defined a Generation, by Blake J. Harris

 

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 Dan Neumann is joined by fellow AgileThought colleague and return guest, Andrea Floyd! Andrea is an enterprise agile transformation consultant at AgileThought with over 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).

 

In this conversation, Dan and Andrea explore the topic of “Big Room Planning” — what it is, when you would use it, and how to do it. Andrea also shares the benefits of it as well as some advice on how to do it most effectively in your organization.

 

Key Takeaways

What is Big Room Planning?

The “what”: Big Room Planning is for when you have a need to bring together multiple teams to collaborate and get alignment on how they’re going to work together to achieve a set of objectives and/or goals for a certain time increment

It is an event where you bring teams together to have a collaborative conversation and create a forecast on what you hope to achieve in a given amount of time

In this conversation, you identify measures and/or time frames where you can have check-ins in order to see how you’re progressing or where you need to make some shifts

It is called Big Room Planning because it implies you would use this technique when you are trying to coordinate across interdependent teams or teams that have a level of impact on one another

It’s all about coming together and being able to see potential points of intersection

Big Room Planning gives the opportunity for different teams to see the different challenges they are encountering and reach their destination together

What Big Room Planning might look like:

It can be as “big” or “small” as necessary

Though it is more beneficial to do it in person, you can use Zoom or Microsoft Meets to hold this event

It is a big commitment and can run from two to three days, depending on where the organization is at in your product lifecycle and your path forward 

Other great collaboration tools: MURAL and Miro

The benefits of Big Room Planning:

The “why”: it is essential to help in achieving alignment and a shared understanding so all teams can move together in the same direction

It’s important to plan as a collaborative enterprise so that you can sequence work, have the necessary conversations about timing and dependencies, and make everything visible

This forecasted plan arms the business decision-makers with the right information, transparency, and openness to converse with anyone in the organization

How do you adapt Big Room Planning to “Small Room Planning”?

Even if you’re an individual team, it doesn’t mean that there is not a need to forecast when features are going to be understood

You can do this for a single team and use feature points to give an understanding of the complexity and plot them on a roadmap

What can make Big Room Planning more effective:

Roadmaps

Milestones

Program boards

Feature points (which can help you understand the relative effort and complexity of those features [just like when you do sprint planning and you have story points, feature points help you understand your capacity and your availability for your team/s])

A true commitment and investment of everyone involved is key for a positive outcome

It is important to understand the “what” and the “why”

Making everything visible so all teams can see how things are progressing

Establishing a working agreement is very helpful in coming up with your operating guidelines, what the outcomes you’re seeking are, and structuring out meeting times

 

Mentioned in this Episode:

AgileThought.com/Events — Visit for AgileThought’s upcoming virtual events & RSVP!

Agile Coaches Corner Ep: “Agility: Not Just an ‘IT Thing’ with Andrea Floyd”

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

Agile Coaches Corner Ep: “Reasons Why Agile Transformations Don’t Stick with Andrea Floyd”

SAFe

Zoom

Microsoft Teams

Agile Coaches Corner Ep: “Setting Up Working Agreements with Christy Erbeck”

MURAL

Miro

Turn the Ship Around!: A True Story of Turning Followers into Leaders, by David L. 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!

Today Dan Neumann is joined by fellow AgileThought colleague and return guest, Andrea Floyd! Andrea is an enterprise agile transformation consultant at AgileThought with over 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).

 

In this conversation, Dan and Andrea explore the topic of “Big Room Planning” — what it is, when you would use it, and how to do it. Andrea also shares the benefits of it as well as some advice on how to do it most effectively in your organization.

 

Key Takeaways

What is Big Room Planning?

The “what”: Big Room Planning is for when you have a need to bring together multiple teams to collaborate and get alignment on how they’re going to work together to achieve a set of objectives and/or goals for a certain time increment

It is an event where you bring teams together to have a collaborative conversation and create a forecast on what you hope to achieve in a given amount of time

In this conversation, you identify measures and/or time frames where you can have check-ins in order to see how you’re progressing or where you need to make some shifts

It is called Big Room Planning because it implies you would use this technique when you are trying to coordinate across interdependent teams or teams that have a level of impact on one another

It’s all about coming together and being able to see potential points of intersection

Big Room Planning gives the opportunity for different teams to see the different challenges they are encountering and reach their destination together

What Big Room Planning might look like:

It can be as “big” or “small” as necessary

Though it is more beneficial to do it in person, you can use Zoom or Microsoft Meets to hold this event

It is a big commitment and can run from two to three days, depending on where the organization is at in your product lifecycle and your path forward 

Other great collaboration tools: MURAL and Miro

The benefits of Big Room Planning:

The “why”: it is essential to help in achieving alignment and a shared understanding so all teams can move together in the same direction

It’s important to plan as a collaborative enterprise so that you can sequence work, have the necessary conversations about timing and dependencies, and make everything visible

This forecasted plan arms the business decision-makers with the right information, transparency, and openness to converse with anyone in the organization

How do you adapt Big Room Planning to “Small Room Planning”?

Even if you’re an individual team, it doesn’t mean that there is not a need to forecast when features are going to be understood

You can do this for a single team and use feature points to give an understanding of the complexity and plot them on a roadmap

What can make Big Room Planning more effective:

Roadmaps

Milestones

Program boards

Feature points (which can help you understand the relative effort and complexity of those features [just like when you do sprint planning and you have story points, feature points help you understand your capacity and your availability for your team/s])

A true commitment and investment of everyone involved is key for a positive outcome

It is important to understand the “what” and the “why”

Making everything visible so all teams can see how things are progressing

Establishing a working agreement is very helpful in coming up with your operating guidelines, what the outcomes you’re seeking are, and structuring out meeting times

 

Mentioned in this Episode:

AgileThought.com/Events — Visit for AgileThought’s upcoming virtual events & RSVP!

Agile Coaches Corner Ep: “Agility: Not Just an ‘IT Thing’ with Andrea Floyd”

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

Agile Coaches Corner Ep: “Reasons Why Agile Transformations Don’t Stick with Andrea Floyd”

SAFe

Zoom

Microsoft Teams

Agile Coaches Corner Ep: “Setting Up Working Agreements with Christy Erbeck”

MURAL

Miro

Turn the Ship Around!: A True Story of Turning Followers into Leaders, by David L. 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!

Oftentimes, those who practice agility will turn their nose up at teams or companies that are not doing agile perfectly. And though the agile practices are important and are great pathways to success, many teams and companies often find ways that work for them that are not perfect agile. In this conversation, Dan and Sam highlight some of the ways in which companies and teams find what works for them, why perfect practicing agility isn’t the end-all-be-all, share the key characteristics for succeeding in agile, and, most importantly: why you shouldn’t be getting your agile shorts in a knot!

 

Key Takeaways

Should a team or company be doing agility perfectly?

If a team finds a helpful practice for them, then that’s what they should do 

“That’s not agile,” or “That’s not the way story points work,” is not very helpful to somebody

It’s important to remember that everyone is on their own agile journey and you shouldn’t judge where they are right now in it

An agility mindset is what really matters; they will improve their practice over time

As long as it works for them, they’re delivering, and their customers are happy then they’re good

Just because a team isn’t doing something by the book doesn’t mean they are wrong in doing it

Advice in entering a new role within a company that’s getting started with agility:

Enter the company/role with curiosity

Just because the role states you will be doing certain things doesn’t mean you will always be doing those things/won’t be doing other things

Start with what the company already knows/is doing; you can adapt as you go along

If you’re interviewing for a position of any kind, it’s not just about, “Do they want you?” but, “Do you want them?”

When selecting a company you want to work for it is important to make sure that they breed a culture of innovation (regardless of where they are in their agile journey) and have a culture of constantly wanting to inspect, adapt, and innovate

Strategies for failure in agility:

There are degrees of planning that can be unhelpful when trying to forecast things out — but zero planning is also a strategy for failure

There is this idea that agility is a binary state (I.e. “You either are or you are not agile”) — agility is more of a continuum (it never truly ends)

Key characteristics for succeeding in agile:

Curiosity is a key characteristic of anybody who wants to succeed in agile

Low tolerance for impedance and that we cannot change things; we have to do it this way

Question how things could be done/how things could be done differently

Asking: “What would happen if ______?”

Having an experimental mindset

Don’t make assumptions about what you think are bad practices/what isn’t agile — you could learn a lot from these experiences

 

Mentioned in this Episode:

AgileThought.com/Events — Visit for AgileThought’s upcoming virtual events & RSVP!

Agile Coaches Corner Ep. 116: “Modern Management Made Easy with Johanna Rothman”

Jira

Ralph Stacey Chart

Wikispeed.org

Discover to Deliver: Agile Product Planning and Analysis, by Ellen Gottesdiener and Mary Gorman

Johanna Rothman’s Modern Management Made Easy Book Series

 

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!

Oftentimes, those who practice agility will turn their nose up at teams or companies that are not doing agile perfectly. And though the agile practices are important and are great pathways to success, many teams and companies often find ways that work for them that are not perfect agile. In this conversation, Dan and Sam highlight some of the ways in which companies and teams find what works for them, why perfect practicing agility isn’t the end-all-be-all, share the key characteristics for succeeding in agile, and, most importantly: why you shouldn’t be getting your agile shorts in a knot!

 

Key Takeaways

Should a team or company be doing agility perfectly?

If a team finds a helpful practice for them, then that’s what they should do 

“That’s not agile,” or “That’s not the way story points work,” is not very helpful to somebody

It’s important to remember that everyone is on their own agile journey and you shouldn’t judge where they are right now in it

An agility mindset is what really matters; they will improve their practice over time

As long as it works for them, they’re delivering, and their customers are happy then they’re good

Just because a team isn’t doing something by the book doesn’t mean they are wrong in doing it

Advice in entering a new role within a company that’s getting started with agility:

Enter the company/role with curiosity

Just because the role states you will be doing certain things doesn’t mean you will always be doing those things/won’t be doing other things

Start with what the company already knows/is doing; you can adapt as you go along

If you’re interviewing for a position of any kind, it’s not just about, “Do they want you?” but, “Do you want them?”

When selecting a company you want to work for it is important to make sure that they breed a culture of innovation (regardless of where they are in their agile journey) and have a culture of constantly wanting to inspect, adapt, and innovate

Strategies for failure in agility:

There are degrees of planning that can be unhelpful when trying to forecast things out — but zero planning is also a strategy for failure

There is this idea that agility is a binary state (I.e. “You either are or you are not agile”) — agility is more of a continuum (it never truly ends)

Key characteristics for succeeding in agile:

Curiosity is a key characteristic of anybody who wants to succeed in agile

Low tolerance for impedance and that we cannot change things; we have to do it this way

Question how things could be done/how things could be done differently

Asking: “What would happen if ______?”

Having an experimental mindset

Don’t make assumptions about what you think are bad practices/what isn’t agile — you could learn a lot from these experiences

 

Mentioned in this Episode:

AgileThought.com/Events — Visit for AgileThought’s upcoming virtual events & RSVP!

Agile Coaches Corner Ep. 116: “Modern Management Made Easy with Johanna Rothman”

Jira

Ralph Stacey Chart

Wikispeed.org

Discover to Deliver: Agile Product Planning and Analysis, by Ellen Gottesdiener and Mary Gorman

Johanna Rothman’s Modern Management Made Easy Book Series

 

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, part three of a three part series on the new Scrum Guide, Professional Scrum Trainer Sam Falco answers the question: "Why has self-organizing changed to self-managing in the new Scrum Guide”?

From Self-Organizing to Self-Managing

In this final episode about the major changes in the new Scrum Guide, I’m going to talk about what may be the most significant change in the Scrum Guide update. And that is the change from saying that teams must be “self-organizing” to saying that they must be “self-managing.”

At first, I didn’t think much of it. I thought it was sort of a search-and-replace type of thing. To me self-organizing and self-managing seemed like the same thing. I’d often thought that self-organizing was chosen to keep managers from freaking out: “What do you mean the team is self-managing? Then what am I going to do”? That might be a cynical take on my part.

But even if the change is merely semantic, the significance is that organizations will look at Scrum in a new light. That phrase, “self-managing” is going to be a big shock to organizations that haven’t allowed teams to be self-organizing or self-managing at all.

A lot of organizations sort of gloss over this concept. Teams aren’t really selecting what they’ll work on except in the very shallowest sense of selecting the items that are at the top of the Product Backlog. Product Owners aren’t really Product Owners except in the shallowest sense of they’re allowed to decide what gets worked on first, but they’re still just taking orders from stakeholders. Teams don’t contribute to their goals; goals are handed to them. Teams are allowed to decide how to do what they’re told to do. Maybe we let them decide who sits where, what their core hours are, and that sort of thing. But there’s a lot more to self-managing than just allowing people to decide where they’ll sit and what they’re going to work on, specifically today.

When Teams Aren’t Allowed to Self-Manage

What happens when we’re using Scrum but we’re not allowing teams to be self-managing?

One frequent complaint about Scrum is that, “There are too many meetings”. I talked about this in a Trainer Talk episode last year. This complaint is common when an organization imposes Scrum from the top down. Here, you’re going to do this. They don’t change anything about the way they work. So, all those other meetings that are on your calendar don’t go away, and here’s four more you need to do. Often, organizations that dictate Scrum as a veneer atop their existing processes don’t see any better delivery than they were before. Sometimes things get worse. Because now they have the added overhead of the events of Scrum and all the things that go with that.

And this leads to a lack of engagement, lack of ownership, it destroys morale, it causes turnover. You not only can’t retain talent, but you can’t attract talent. Because word gets out and people hear that yeah, you don’t want to work there because that’s a horrible place to work. Self-managing teams create a healthier workplace that people want to join and stay in.

Scrum and Autonomy

In his book, Drive, Daniel Pink examined what really motivates people in complex knowledge work domains, which includes product development. What he found was that what motivated people wasn’t being rewarded with money. The three factors that motivate knowledge workers are autonomy, mastery, and purpose.  

Autonomy is the ability to decide what I am going to work on and how I am going to work on it. Mastery is the ability to continually improve your skills. And purpose means doing something that’s meaningful. Self-managing teams leverage all three of those things. And Scrum done well has all three built-in.

A Scrum Team decides what it’s going to work on. A Product Goal is more than just a statement handed out. The Product Owner who creates it also collaborates with the Scrum Team on it and on what the Scrum Team needs to do to get there. The entire team gets involved in that emergent product backlog management. That’s autonomy.

Another way that Scrum gives teams autonomy is that they set their own Sprint Goal. No one says, “This is what you’re going to be doing this Sprint.” Instead, the Scrum Team talks about what would be valuable to do based on the feedback they’ve gotten so far and creates its own goal and plan. And then of course, every day in the daily Scrum, the Developers meet and figure out how they are going to move a little closer to the Sprint Goal that day. They’re responsible for coming up with that plan, nobody else.

Scrum and Mastery

Scrum encourages mastery. The Scrum team is accountable as a whole for delivery, so there’s no idea that, “This is my area and I don’t have to do anything else”. We all expand our knowledge together and work together.

And then of course, purpose is built into Scrum. We have that important Product Goal that tells us what we’re building and why. And it should be exciting for us. 

A benefit of self-managing teams is that there’s less overhead for managers. They don’t have to spend time directing people and telling them what to do. The manager who introduced Scrum to our team and asked me to be the Scrum Master was so relieved that he didn’t have to chase us down for status reports, that he didn’t have to be telling people what to do. He could just say, “Here’s what we need to accomplish.” And we figured it out on our own. His management activities became about helping us grow in our careers. He would ask, “What do you need to know? What do you need to learn? How can I help with that?” Both for technical skills and for navigating our organization. That was a much more fulfilling experience for him and for us.

Another benefit of self-managing is serendipity in development. Hand people a problem to solve and then get out of their way. They will solve it in ways that you never imagined. Maybe solve it better than you would have if you had told them what to do.

Using Scrum to manage a project instead of driving product development misses out on creating valuable products and valuable outcomes — especially in the face of uncertainty. We can pretend that we can predict the future, but we can’t. And in complex product development, something new is always going to come up. There’s an enormous amount of uncertainty. Scrum allows us to adapt to that uncertainty as it arises. Every Sprint we have a chance to change direction.

Getting to Self-Managing Teams

So how do you get there? First, I would say abandon the illusion of control. I had a manager once who really struggled with that. He had a deliverable that he had been told must be completed by a certain date. He’d been told the scope, an immovable target date, a fixed budget. And he was obsessed with making sure that everyone knew what he wanted them to do. And I said, let’s try to leverage Scrum for this, and he said, “As long as everyone does what I say, we’ll succeed.” As a result, people didn’t take initiative when they needed to, for fear of getting slapped down. The project ran late, and there was hell to pay as a result.

This is a bad pattern. We need to let go of the idea that we can control everything, that we can predict everything up front. 

Feed your teams with objectives, not tasks. Set the boundaries within which they can make their own decisions and steer their own course.

Empower your Product Owners to make decisions and shepherd their products. Certainly, they’ll need to take into consideration what stakeholders need and want, but allow Product Owners the latitude to make decision about what is most valuable to do and give them the resources they need to make those decisions. Things like access to market data, access to customers, etc.

Encourage the Scrum team as a whole to be accountable toward each other and toward achieving positive outcomes. Encourage teams to do small experiments until the goal is achieved or the goal becomes obsolete. And then create a new goal or a new objective. We can manage risk with small Sprints where we constantly inspect and adapt not only the product and our progress toward the product goal but also the team’s effectiveness, the processes they work with, and the objectives they’re being asked to work on.

As one of the principles behind the agile manifesto states, “Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. And they will. That’s the promise Scrum offers.

I hope you benefited from this exploration of the changes in the new Scrum Guide. I’d love to hear your feedback. If you have a question or a comment, please email us at [email protected].

Want to Learn More or Get in Touch?

• Register for our upcoming web meetings
• See available training courses

 

In this episode, part three of a three part series on the new Scrum Guide, Professional Scrum Trainer Sam Falco answers the question: "Why has self-organizing changed to self-managing in the new Scrum Guide”?

From Self-Organizing to Self-Managing

In this final episode about the major changes in the new Scrum Guide, I’m going to talk about what may be the most significant change in the Scrum Guide update. And that is the change from saying that teams must be “self-organizing” to saying that they must be “self-managing.”

At first, I didn’t think much of it. I thought it was sort of a search-and-replace type of thing. To me self-organizing and self-managing seemed like the same thing. I’d often thought that self-organizing was chosen to keep managers from freaking out: “What do you mean the team is self-managing? Then what am I going to do”? That might be a cynical take on my part.

But even if the change is merely semantic, the significance is that organizations will look at Scrum in a new light. That phrase, “self-managing” is going to be a big shock to organizations that haven’t allowed teams to be self-organizing or self-managing at all.

A lot of organizations sort of gloss over this concept. Teams aren’t really selecting what they’ll work on except in the very shallowest sense of selecting the items that are at the top of the Product Backlog. Product Owners aren’t really Product Owners except in the shallowest sense of they’re allowed to decide what gets worked on first, but they’re still just taking orders from stakeholders. Teams don’t contribute to their goals; goals are handed to them. Teams are allowed to decide how to do what they’re told to do. Maybe we let them decide who sits where, what their core hours are, and that sort of thing. But there’s a lot more to self-managing than just allowing people to decide where they’ll sit and what they’re going to work on, specifically today.

When Teams Aren’t Allowed to Self-Manage

What happens when we’re using Scrum but we’re not allowing teams to be self-managing?

One frequent complaint about Scrum is that, “There are too many meetings”. I talked about this in a Trainer Talk episode last year. This complaint is common when an organization imposes Scrum from the top down. Here, you’re going to do this. They don’t change anything about the way they work. So, all those other meetings that are on your calendar don’t go away, and here’s four more you need to do. Often, organizations that dictate Scrum as a veneer atop their existing processes don’t see any better delivery than they were before. Sometimes things get worse. Because now they have the added overhead of the events of Scrum and all the things that go with that.

And this leads to a lack of engagement, lack of ownership, it destroys morale, it causes turnover. You not only can’t retain talent, but you can’t attract talent. Because word gets out and people hear that yeah, you don’t want to work there because that’s a horrible place to work. Self-managing teams create a healthier workplace that people want to join and stay in.

Scrum and Autonomy

In his book, Drive, Daniel Pink examined what really motivates people in complex knowledge work domains, which includes product development. What he found was that what motivated people wasn’t being rewarded with money. The three factors that motivate knowledge workers are autonomy, mastery, and purpose.  

Autonomy is the ability to decide what I am going to work on and how I am going to work on it. Mastery is the ability to continually improve your skills. And purpose means doing something that’s meaningful. Self-managing teams leverage all three of those things. And Scrum done well has all three built-in.

A Scrum Team decides what it’s going to work on. A Product Goal is more than just a statement handed out. The Product Owner who creates it also collaborates with the Scrum Team on it and on what the Scrum Team needs to do to get there. The entire team gets involved in that emergent product backlog management. That’s autonomy.

Another way that Scrum gives teams autonomy is that they set their own Sprint Goal. No one says, “This is what you’re going to be doing this Sprint.” Instead, the Scrum Team talks about what would be valuable to do based on the feedback they’ve gotten so far and creates its own goal and plan. And then of course, every day in the daily Scrum, the Developers meet and figure out how they are going to move a little closer to the Sprint Goal that day. They’re responsible for coming up with that plan, nobody else.

Scrum and Mastery

Scrum encourages mastery. The Scrum team is accountable as a whole for delivery, so there’s no idea that, “This is my area and I don’t have to do anything else”. We all expand our knowledge together and work together.

And then of course, purpose is built into Scrum. We have that important Product Goal that tells us what we’re building and why. And it should be exciting for us. 

A benefit of self-managing teams is that there’s less overhead for managers. They don’t have to spend time directing people and telling them what to do. The manager who introduced Scrum to our team and asked me to be the Scrum Master was so relieved that he didn’t have to chase us down for status reports, that he didn’t have to be telling people what to do. He could just say, “Here’s what we need to accomplish.” And we figured it out on our own. His management activities became about helping us grow in our careers. He would ask, “What do you need to know? What do you need to learn? How can I help with that?” Both for technical skills and for navigating our organization. That was a much more fulfilling experience for him and for us.

Another benefit of self-managing is serendipity in development. Hand people a problem to solve and then get out of their way. They will solve it in ways that you never imagined. Maybe solve it better than you would have if you had told them what to do.

Using Scrum to manage a project instead of driving product development misses out on creating valuable products and valuable outcomes — especially in the face of uncertainty. We can pretend that we can predict the future, but we can’t. And in complex product development, something new is always going to come up. There’s an enormous amount of uncertainty. Scrum allows us to adapt to that uncertainty as it arises. Every Sprint we have a chance to change direction.

Getting to Self-Managing Teams

So how do you get there? First, I would say abandon the illusion of control. I had a manager once who really struggled with that. He had a deliverable that he had been told must be completed by a certain date. He’d been told the scope, an immovable target date, a fixed budget. And he was obsessed with making sure that everyone knew what he wanted them to do. And I said, let’s try to leverage Scrum for this, and he said, “As long as everyone does what I say, we’ll succeed.” As a result, people didn’t take initiative when they needed to, for fear of getting slapped down. The project ran late, and there was hell to pay as a result.

This is a bad pattern. We need to let go of the idea that we can control everything, that we can predict everything up front. 

Feed your teams with objectives, not tasks. Set the boundaries within which they can make their own decisions and steer their own course.

Empower your Product Owners to make decisions and shepherd their products. Certainly, they’ll need to take into consideration what stakeholders need and want, but allow Product Owners the latitude to make decision about what is most valuable to do and give them the resources they need to make those decisions. Things like access to market data, access to customers, etc.

Encourage the Scrum team as a whole to be accountable toward each other and toward achieving positive outcomes. Encourage teams to do small experiments until the goal is achieved or the goal becomes obsolete. And then create a new goal or a new objective. We can manage risk with small Sprints where we constantly inspect and adapt not only the product and our progress toward the product goal but also the team’s effectiveness, the processes they work with, and the objectives they’re being asked to work on.

As one of the principles behind the agile manifesto states, “Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. And they will. That’s the promise Scrum offers.

I hope you benefited from this exploration of the changes in the new Scrum Guide. I’d love to hear your feedback. If you have a question or a comment, please email us at [email protected].

Want to Learn More or Get in Touch?

• Register for our upcoming web meetings
• See available training courses

 

This week, Dan Neumann is excited to be joined by Johanna Rothman — also known as the Pragmatic Manager. Johanna is a management consultant for managers and leaders. She helps leaders identify their problems and seize the opportunities that they know exist — but just can’t find yet. She also provides assessments, workshops and training, coaching, speaking, and facilitation. Additionally, Johanna is also an author of some incredible books on the topics of amplifying your effectiveness, hiring, management, agility, scaling collaboration, and more.

 

Most recently, Johanna released a triad of management books called, Modern Management Made Easy. These three books are Practical Ways to Manage Yourself, Practical Ways to Lead and Serve — Manage — Others, and Practical Ways to Lead an Innovative Organization.

 

In their conversation today, Johanna unpacks these three books and shares some of the key pieces of information you will want to know as a manager or leader in managing and leading yourself, others, and an innovative organization.

 

Key Takeaways

Johanna’s Modern Management Made Easy Book Series:

Practical Ways to Manage Yourself

Practical Ways to Lead and Serve — Manage — Others

Practical Ways to Lead an Innovative Organization

Key lessons from Practical Ways to Manage Yourself:

“Managing oneself” myth: “I must solve the team’s problems for the team”

As a manager, you can’t solve your team’s problems or “inflict help”; instead, you should ask, “Do you need any information from me?” or, “Do you need my help to solve the problem?”

The manager stance of: “Don’t bring me problems, bring me solutions,” is not effective; you should be providing suggestions on where the team member can go next and engage in the problem-solving

Key lessons from Practical Ways to Lead and Serve — Manage — Others:

Myth: “Performance reviews are motivating” — in truth, they can be incredibly demotivating

As a manager giving a performance review, you should be providing feedback that the team member can take action on and improve from

You shouldn’t be asking more from those that are doing incredibly well and expecting them to deliver even more than what you expect from other people

Don’t make the performance review all about money — this can be very demotivating

People do need feedback, just not often not in the form of performance reviews (“There is a difference between feedback and evaluation” — Johanna Rothman)

Conduct one-on-ones with everybody that you lead and serve on a regular basis (at least every two weeks), and you will come to understand what everyone wants and needs, and how they’re working within the organization

Key lessons from Practical Ways to Lead an Innovative Organization:

Offer feedback and coaching labs within the organization

“If we can focus more on what’s working in the organization and what’s working with people, we are more likely to achieve the results that we want.” — Johanna Rothman

Use change-focused feedback and ask for the change that you want

Peer-to-peer feedback works for almost anything (and the key is to do it as soon as you notice a challenge)

Congruence is key (balance yourself, the needs of others, as well as the context you are in)

Ask yourself: “How do we make it so the team can succeed?”

Resilience as a team is key and it’s important to make sure to balance the needs of everybody (i.e. sometimes we need flexibility and sometimes we can extend flexibility to others)

Intentionally practice management

You don’t have to be a manager all by yourself; you can talk to your peers and work together

 

Mentioned in this Episode:

AgileThought.com/Events — Visit for AgileThought’s upcoming virtual events & RSVP!

Johanna Rothman

Johanna’s Twitter @JohannaRothman

Johanna’s Books

Modern Management Made Easy Book Series

Kurt Lewin

Punished by Rewards: The Trouble with Gold Stars, Incentive Plans, A's, Praise, and Other Bribes, by Alfie Kohn

Pfeffer and Sutton

Behind Closed Doors: Secrets of Great Management, by Johanna Rothman and Esther Derby

Lean In: Women, Work, and the Will to Lead, by Sheryl Sandberg

“Why A Career Jungle Gym Is Better Than A Career Ladder”

Johanna Rothman’s Blogs

 

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!