Agile Coaches' Corner

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!

 

 

In this episode, part two of a three part series on the new Scrum Guide, Professional Scrum Trainer Sam Falco helps you improve Sprint Planning by answering the question: "How has the Sprint Goal changed with the new Scrum Guide”?

The Sprint Goal and the Sprint Planning

In my last episode I talked about introduction of the Product Goal and how that changes the way we see the Product Backlog. The Product Goal is the commitment associated with the Product Backlog. In this episode, we’re talking about the commitment associated with the Sprint Backlog: The Sprint Goal.

The Sprint Goal isn’t new to Scrum. It has been part of the Scrum Guide for at least as long as I’ve been practicing Scrum. It’s what the teams commit to at Sprint Planning. Scrum Teams are not supposed to commit to a scope of work but a goal which guides us in selecting and adapting the scope.

The new Scrum Guide underscores that commitment and its purpose. I think it will help teams understand why they’re doing Sprint Planning in the first place. That Sprint Planning is not merely an exercise in selecting the top X number of items off the Product Backlog and doing that until we’ve made sure that everyone is fully utilized. That’s not the purpose of Sprint Planning. And that view is one of the reasons that Sprint Planning becomes such a tedious chore for so many teams.

Earlier Scrum Guides talked about the need to craft a Sprint Goal as part of determining what Product Backlog Items we will select. In the new Scrum Guide, Jeff and Ken make it clear how important this is by introducing a new topic for Sprint Planning: “Why is this Sprint valuable”? In other words, what do we hope to get out of it? What’s our objective here? What are we trying to achieve? If we want to be blunt, we’re asking: What value are we going to provide in return for the stakeholder funding we’re spending?

So, we start by asking the question, why is this Sprint valuable? Answering that question helps us craft our Sprint Goal.

The Sprint Goal and SMART Goals

I talked in the previous episode about the idea of SMART Goals – an acronym for specific, measurable, achievable, realistic, and time-bound. I said that a Product Goal fulfills the first two of those — and measurable — but it might not fulfill the other three. But with the Sprint Goal, I think we fulfill all five criteria.

Like the Product Goal, the Sprint Goal is specific and measurable. We’ll know whether we have achieved it. But here we have a much better idea of being able to be realistic and achievable. We want to achieve our Sprint Goal every Sprint, so we do need to select an achievable goal and of course, it’s also time bound by the length of Sprint itself.

When you Don’t Have a Sprint Goal

If you don’t have a Sprint Goal, as I said earlier, the Sprint Backlog becomes just a list of Product Backlog Items to fill up our capacity. There’s no coherence to it. And often that leads to other bad patterns like everyone having their own PBIs that they’re working on and the team doesn’t collaborate. It’s everybody working in their own individual silos. I’ll hear people say things like, “We need to stay in our lane”. And then of course the Daily Scrum becomes a dry recitation of what I did yesterday. It becomes a status report and it’s not a collaboration meeting.

These dysfunctions can stem from not having a strong Sprint Goal. If we have a Sprint Goal, then we can create that coherent Sprint Backlog that will help us meet it.

How to Order your Product and Sprint Backlog

Now ideally the Product Backlog is ordered so it’s easy to select items from the top and create a coherent Sprint Backlog, but there’s some finesse and negotiation in there, too. If the Product Owner comes to the team and says, “Listen, here’s what I’m thinking for this Sprint. We need to start generating revenue for our web application. We need to build a way to accept payments”. Just because something is at the top of the list, doesn’t mean we have to select it if it won’t help us achieve the Sprint Goal.

And there’s also some negotiation between the Product Owner and the Developers. The Developers might say, “Here’s how much we think we can do. We know you want all the credit cards and PayPal and Apple Pay, and so on, but we can’t do all of that. And we can further refine that Sprint Goal to make it really clear what it is we’re trying to accomplish. For example, we need to accept at least three methods of payment.

Sometimes, teams ask, “What about other stuff we have to do that isn’t directly tied to the product development”? We’re talking about things like technical debt, infrastructure that needs to be taken care of that maybe doesn’t contribute directly to the Sprint Goal but that needs to get done.

And that’s fine. There might be things in your Sprint Backlog that aren’t strongly correlated to the Sprint Goal. But doing what is necessary to achieve the Sprint Goal needs to be the priority. If you find that some of these other items keep getting pushed aside, maybe they should be the focus of a Sprint Goal themselves.

The Third Step of Sprint Planning

Once we have a Sprint Goal and it has helped us select a coherent group of Product Backlog Items for our Sprint Backlog, the Sprint Goal also helps us in the third topic in Sprint Planning. Namely, how are we going to do it? Teams that work in silos, once they’ve selected the individual items that they’re each going to work on, they go their separate ways. If everyone has their work to do and they don’t really coordinate or collaborate with each other, there’s often no point in sitting there, figuring out a plan. Each person is going to go off and do their own thing. When we are truly working toward a common Sprint Goal, when we are working toward a common plan that derives from that Sprint Goal, it behooves us to sit down together and figure out what our plan is.

But even teams that aren’t working in silos will often skip the third part of Sprint Planning so that – and I hear this phrase a lot – “So that we can start working.” Well this is part of the work. Good Sprint planning includes creating a plan for working together. Breaking things down into the tasks we need to achieve. We don’t need to forecast every single thing we might need to do. Just enough to get started, that we can show progress every day and that we can uncover what else we need to do as we go.

Without that plan we have a lack of transparency. The Scrum Team can’t see every day at Daily Scrum whether it is making good progress toward the Sprint Goal. They don’t know if they need to adjust their scope. They don’t know if they need to renegotiate which Product Backlog Items belong in the Sprint or what the scope of each PBI is.

Lack of transparency also means that people outside the team can’t tell if the team’s being effective. And that probably means they’ll pester the team more, which has implications for self-management — which I’ll talk about in the next episode. So, having that plan means good transparency for everyone involved and it gives us a much better chance of achieving a positive outcome.

The Importance of the Sprint Goal

So, a Sprint goal flows from our Product Goal. The Sprint Goal should be a step toward achieving the Product Goal. The Sprint Goal creates transparency, and it creates the ability for a Scrum Team to deliver reliably, predictably, each and every Sprint and to do it without having to overwork themselves. It helps us establish a sustainable pace, which gives us better morale and a more fulfilling work environment.

I’m going to talk about how they do that in the next episode when I talk about the term self-managing. So, I hope you’ll join me here for that episode. Meanwhile, 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 two of a three part series on the new Scrum Guide, Professional Scrum Trainer Sam Falco helps you improve Sprint Planning by answering the question: "How has the Sprint Goal changed with the new Scrum Guide”?

The Sprint Goal and the Sprint Planning

In my last episode I talked about introduction of the Product Goal and how that changes the way we see the Product Backlog. The Product Goal is the commitment associated with the Product Backlog. In this episode, we’re talking about the commitment associated with the Sprint Backlog: The Sprint Goal.

The Sprint Goal isn’t new to Scrum. It has been part of the Scrum Guide for at least as long as I’ve been practicing Scrum. It’s what the teams commit to at Sprint Planning. Scrum Teams are not supposed to commit to a scope of work but a goal which guides us in selecting and adapting the scope.

The new Scrum Guide underscores that commitment and its purpose. I think it will help teams understand why they’re doing Sprint Planning in the first place. That Sprint Planning is not merely an exercise in selecting the top X number of items off the Product Backlog and doing that until we’ve made sure that everyone is fully utilized. That’s not the purpose of Sprint Planning. And that view is one of the reasons that Sprint Planning becomes such a tedious chore for so many teams.

Earlier Scrum Guides talked about the need to craft a Sprint Goal as part of determining what Product Backlog Items we will select. In the new Scrum Guide, Jeff and Ken make it clear how important this is by introducing a new topic for Sprint Planning: “Why is this Sprint valuable”? In other words, what do we hope to get out of it? What’s our objective here? What are we trying to achieve? If we want to be blunt, we’re asking: What value are we going to provide in return for the stakeholder funding we’re spending?

So, we start by asking the question, why is this Sprint valuable? Answering that question helps us craft our Sprint Goal.

The Sprint Goal and SMART Goals

I talked in the previous episode about the idea of SMART Goals – an acronym for specific, measurable, achievable, realistic, and time-bound. I said that a Product Goal fulfills the first two of those — and measurable — but it might not fulfill the other three. But with the Sprint Goal, I think we fulfill all five criteria.

Like the Product Goal, the Sprint Goal is specific and measurable. We’ll know whether we have achieved it. But here we have a much better idea of being able to be realistic and achievable. We want to achieve our Sprint Goal every Sprint, so we do need to select an achievable goal and of course, it’s also time bound by the length of Sprint itself.

When you Don’t Have a Sprint Goal

If you don’t have a Sprint Goal, as I said earlier, the Sprint Backlog becomes just a list of Product Backlog Items to fill up our capacity. There’s no coherence to it. And often that leads to other bad patterns like everyone having their own PBIs that they’re working on and the team doesn’t collaborate. It’s everybody working in their own individual silos. I’ll hear people say things like, “We need to stay in our lane”. And then of course the Daily Scrum becomes a dry recitation of what I did yesterday. It becomes a status report and it’s not a collaboration meeting.

These dysfunctions can stem from not having a strong Sprint Goal. If we have a Sprint Goal, then we can create that coherent Sprint Backlog that will help us meet it.

How to Order your Product and Sprint Backlog

Now ideally the Product Backlog is ordered so it’s easy to select items from the top and create a coherent Sprint Backlog, but there’s some finesse and negotiation in there, too. If the Product Owner comes to the team and says, “Listen, here’s what I’m thinking for this Sprint. We need to start generating revenue for our web application. We need to build a way to accept payments”. Just because something is at the top of the list, doesn’t mean we have to select it if it won’t help us achieve the Sprint Goal.

And there’s also some negotiation between the Product Owner and the Developers. The Developers might say, “Here’s how much we think we can do. We know you want all the credit cards and PayPal and Apple Pay, and so on, but we can’t do all of that. And we can further refine that Sprint Goal to make it really clear what it is we’re trying to accomplish. For example, we need to accept at least three methods of payment.

Sometimes, teams ask, “What about other stuff we have to do that isn’t directly tied to the product development”? We’re talking about things like technical debt, infrastructure that needs to be taken care of that maybe doesn’t contribute directly to the Sprint Goal but that needs to get done.

And that’s fine. There might be things in your Sprint Backlog that aren’t strongly correlated to the Sprint Goal. But doing what is necessary to achieve the Sprint Goal needs to be the priority. If you find that some of these other items keep getting pushed aside, maybe they should be the focus of a Sprint Goal themselves.

The Third Step of Sprint Planning

Once we have a Sprint Goal and it has helped us select a coherent group of Product Backlog Items for our Sprint Backlog, the Sprint Goal also helps us in the third topic in Sprint Planning. Namely, how are we going to do it? Teams that work in silos, once they’ve selected the individual items that they’re each going to work on, they go their separate ways. If everyone has their work to do and they don’t really coordinate or collaborate with each other, there’s often no point in sitting there, figuring out a plan. Each person is going to go off and do their own thing. When we are truly working toward a common Sprint Goal, when we are working toward a common plan that derives from that Sprint Goal, it behooves us to sit down together and figure out what our plan is.

But even teams that aren’t working in silos will often skip the third part of Sprint Planning so that – and I hear this phrase a lot – “So that we can start working.” Well this is part of the work. Good Sprint planning includes creating a plan for working together. Breaking things down into the tasks we need to achieve. We don’t need to forecast every single thing we might need to do. Just enough to get started, that we can show progress every day and that we can uncover what else we need to do as we go.

Without that plan we have a lack of transparency. The Scrum Team can’t see every day at Daily Scrum whether it is making good progress toward the Sprint Goal. They don’t know if they need to adjust their scope. They don’t know if they need to renegotiate which Product Backlog Items belong in the Sprint or what the scope of each PBI is.

Lack of transparency also means that people outside the team can’t tell if the team’s being effective. And that probably means they’ll pester the team more, which has implications for self-management — which I’ll talk about in the next episode. So, having that plan means good transparency for everyone involved and it gives us a much better chance of achieving a positive outcome.

The Importance of the Sprint Goal

So, a Sprint goal flows from our Product Goal. The Sprint Goal should be a step toward achieving the Product Goal. The Sprint Goal creates transparency, and it creates the ability for a Scrum Team to deliver reliably, predictably, each and every Sprint and to do it without having to overwork themselves. It helps us establish a sustainable pace, which gives us better morale and a more fulfilling work environment.

I’m going to talk about how they do that in the next episode when I talk about the term self-managing. So, I hope you’ll join me here for that episode. Meanwhile, 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, co-hosts Dan Neumann and Sam Falco discuss the topic of filling the role of a Scrum Master. In particular, whether you should follow Scrum practices and patterns as opposed to using the Scrum principles, or vice-versa. They talk about what they see most Scrum Masters doing, some of the common mistakes they may make, how to take an effective approach as Scrum Master, and share some of the lessons they have learned throughout their careers as Scrum Masters themselves.

 

Key Takeaways

Advice for new Scrum Masters/What Scrum Masters should be aware of:

Get feedback and act on it — especially when it’s interpersonal feedback

Ask: “How can I be serving my team better?”

Build support for your team around Scrum (which may be new and uncomfortable to them)

The impulse may be to say, “I’m doing this because that is what it says to do in the book,” but that’s not a satisfying answer for anybody

If somebody asks, “Why do we have to have a daily Scrum?” Don’t just say it is because “daily” is in the title — instead, ask, “What value are you not getting out of the daily Scrum?”

Whenever your team is unsure about why they are doing a particular practice, ask, “Why wasn’t this valuable?” and “How can we get more value out of it?”

Getting a Scrum certification from 2006 or 2008 isn’t sufficient; you have to continuously learn and improve as a Scrum Master — new practices are constantly emerging and you have to adapt

“Let them fail” can be misconstrued as not giving someone enough support in their role and letting them fail (what it actually means is putting someone in the place to win and giving them the chance to fail)

The new Scrum Guide is an amazing resource because it strips away all of the prescriptive practices and is easier for new Scrum Masters to follow

Ask: “Is your daily scrum effective at helping you plan so that this won’t happen again?”

The Scrum Master has to guide the team in a way that’s not telling them what to do

Sometimes as a Scrum Master the best thing you can do is say nothing (which doesn’t mean sitting back and doing nothing; but actively observing, considering, and when your team asks a question, follow it up with another question [i.e. “What do you think you can do?” or “What are some options?” and allow them to figure things out])

Don’t give your team answers, this disempowers them; instead, allow them to try something on their own (they may solve the problem in a better way)

Even if a team member fails when you allow them to try something their own way, remember: you’re only one sprint away from recovering in Scrum

As a Scrum Master, there are times where you may need to step in (i.e. when you know something is going to result in something bad that will cause strife)

Upholding Scrum is a part of the Scrum Master’s accountability

The one situation in which a Scrum Master absolutely needs to step in is if there is abuse

If you feel things have gotten stale as a Scrum Master it is time to broaden your horizons and think about the different ways you can serve your team

Continue to learn and explore different options for how to build some excitement and make Agile principles and Scrum values more present

Patterns and Practices vs. Principles

Doing the practices in an inappropriate way can be harmful and the principles can really illuminate effective ways to do that

Patterns and practices are important (but equally as important is building the principles so that you’re doing them effectively at the right times)

The pattern is important but you need to understand the principle behind it and why you’re doing it so you can then adapt it

As a beginning Scrum Master, it is helpful to follow the practices but if you’re only following the rule because “it says so” or “I say so” it is not a good strategy to push forward with

As a Scrum Master, it is your job to help people become effective and figure out what patterns and practices work for them

 

Mentioned in this Episode:

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

Agile Coaches’ Corner Ep. 1: “Do Scrum Well Before Scaling!”

Agile Project Management with Scrum (Developer Best Practices), by Ken Schwaber

Agile Coaches’ Corner Ep. 54: “The Concept of Shu Ha Ri and Why It’s Important to Agile Adoption with Che Ho”

The Scrum Field Guide: Practical Advice for Your First Year (Agile Software Development Series), by Mitch Lacey

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

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

 

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, co-hosts Dan Neumann and Sam Falco discuss the topic of filling the role of a Scrum Master. In particular, whether you should follow Scrum practices and patterns as opposed to using the Scrum principles, or vice-versa. They talk about what they see most Scrum Masters doing, some of the common mistakes they may make, how to take an effective approach as Scrum Master, and share some of the lessons they have learned throughout their careers as Scrum Masters themselves.

 

Key Takeaways

Advice for new Scrum Masters/What Scrum Masters should be aware of:

Get feedback and act on it — especially when it’s interpersonal feedback

Ask: “How can I be serving my team better?”

Build support for your team around Scrum (which may be new and uncomfortable to them)

The impulse may be to say, “I’m doing this because that is what it says to do in the book,” but that’s not a satisfying answer for anybody

If somebody asks, “Why do we have to have a daily Scrum?” Don’t just say it is because “daily” is in the title — instead, ask, “What value are you not getting out of the daily Scrum?”

Whenever your team is unsure about why they are doing a particular practice, ask, “Why wasn’t this valuable?” and “How can we get more value out of it?”

Getting a Scrum certification from 2006 or 2008 isn’t sufficient; you have to continuously learn and improve as a Scrum Master — new practices are constantly emerging and you have to adapt

“Let them fail” can be misconstrued as not giving someone enough support in their role and letting them fail (what it actually means is putting someone in the place to win and giving them the chance to fail)

The new Scrum Guide is an amazing resource because it strips away all of the prescriptive practices and is easier for new Scrum Masters to follow

Ask: “Is your daily scrum effective at helping you plan so that this won’t happen again?”

The Scrum Master has to guide the team in a way that’s not telling them what to do

Sometimes as a Scrum Master the best thing you can do is say nothing (which doesn’t mean sitting back and doing nothing; but actively observing, considering, and when your team asks a question, follow it up with another question [i.e. “What do you think you can do?” or “What are some options?” and allow them to figure things out])

Don’t give your team answers, this disempowers them; instead, allow them to try something on their own (they may solve the problem in a better way)

Even if a team member fails when you allow them to try something their own way, remember: you’re only one sprint away from recovering in Scrum

As a Scrum Master, there are times where you may need to step in (i.e. when you know something is going to result in something bad that will cause strife)

Upholding Scrum is a part of the Scrum Master’s accountability

The one situation in which a Scrum Master absolutely needs to step in is if there is abuse

If you feel things have gotten stale as a Scrum Master it is time to broaden your horizons and think about the different ways you can serve your team

Continue to learn and explore different options for how to build some excitement and make Agile principles and Scrum values more present

Patterns and Practices vs. Principles

Doing the practices in an inappropriate way can be harmful and the principles can really illuminate effective ways to do that

Patterns and practices are important (but equally as important is building the principles so that you’re doing them effectively at the right times)

The pattern is important but you need to understand the principle behind it and why you’re doing it so you can then adapt it

As a beginning Scrum Master, it is helpful to follow the practices but if you’re only following the rule because “it says so” or “I say so” it is not a good strategy to push forward with

As a Scrum Master, it is your job to help people become effective and figure out what patterns and practices work for them

 

Mentioned in this Episode:

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

Agile Coaches’ Corner Ep. 1: “Do Scrum Well Before Scaling!”

Agile Project Management with Scrum (Developer Best Practices), by Ken Schwaber

Agile Coaches’ Corner Ep. 54: “The Concept of Shu Ha Ri and Why It’s Important to Agile Adoption with Che Ho”

The Scrum Field Guide: Practical Advice for Your First Year (Agile Software Development Series), by Mitch Lacey

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

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

 

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 one of a three part series on the new Scrum Guide, Professional Scrum Trainer Sam Falco answers the question: "How Has the Product Goal Changed with the New Scrum Guide?"

What’s New in the Scrum Guide?

The more I think about the new edition of the Scrum Guide, the more excited I am about the changes. Scrum is still Scrum of course. Nothing changed about how Scrum works or the value it brings.

But by stripping out prescriptive elements, Ken and Jeff have given us a Scrum Guide that makes its purpose and value clearer. Organizations that truly embrace this iteration of Scrum are going to supercharge their product development efforts.

Dan Neumann and I talked about the changes to the Scrum Guide in episode 106 of The Agile Coaches’ Corner podcast, titled “What’s new with Scrum?” That was a few days after the Scrum Guide came out. Now that we’ve had time to absorb the changes, I wanted to revisit them. In this three-part series, I’ll examine three changes that I think organizations using Scrum need to pay close attention to. And the one I’m going to talk about in this episode is the introduction of the Product Goal as the commitment associated with the Product Backlog.

The Product Goal and the Product Backlog

As I mentioned in episode 106, a criticism that I’ve seen levied at Scrum is that it doesn’t provide a unified vision for the team to work toward. Without that vision, the team lurches from short-term goal to short-term goal and Developers struggle to understand what they’re building and why they’re building it.

It’s true that Scrum didn’t tell you to create that goal. Of course, nothing prevented a Product Owner from doing that, either, and the best Product Owners I’ve worked with did just that. With the Scrum Guide making that Product Goal an explicit part of Scrum, it’s going to make a big difference in the way people look at how they’re practicing Scrum. Here’s what the Scrum Guide has to say about the Product Goal:

“The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define ‘what’ will fulfill the Product Goal”.

So, the Product Goal is the why and the rest of the Product Backlog is the what.

I like that statement because it describes a future state of the product to plan against. I think this shows us what the difference is between a Product Goal and a Product Vision.

How Does the Product Goal Create a Broader Vision?

You’ve probably heard of SMART goals. SMART being an acronym for specific, measurable, achievable, relevant, and time-bound.

A product vision may lack some of those characteristics.

Let’s imagine we are running a vacation resort and our vision is to become the destination of choice for travelers to our region. That is pretty broad, rather than being specific. It’s not measurable — or at least it’s not easily measurable. We don’t know if it’s achievable until we try. It is relevant to our business, but there’s no time statement in there. So it’s not a SMART goal. It’s inspiring, but by itself, that vision is not enough to give a Scrum Team what they need to know and how to move forward.

A Product Goal is a concrete step toward realizing that broader vision. It’s at the very least specific and measurable. We might not know if it’s achievable or realistic until we try. It might be time boxed, but it isn’t always. Sometimes, instead of setting a release date, the release boundary is the features the product must have. The release date is flexible. Often, of course, we have a time constraint. For our imaginary resort, we might want to make a new product available around the time people start planning their vacations for our tourist season.

So, our imaginary resort’s vision is to be the destination of choice for travelers to their region. What does a Product Goal look like?

It might be something like, “Create a rainforest hike package that will appeal to young couples”. That is specific and measurable: We know what it is we’re trying to achieve; we know who we’re targeting, and we will know when we’ve achieved it.

Looking back again at that definition of Product Goal: The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define WHAT will fulfill the Product Goal. That has some specific benefits.

The Product Goal creates transparency. We know why we’re building the product, and we know whether it makes sense to keep building this product. Is the “why” still a concern? If not, we can end the product development effort. Our imaginary resort can look at whether young couples are responding to our offerings, or whether they even travel to our region at a rate high enough to justify the cost of developing the new product.

The Product Goal helps us understand what value we expect to create so we can validate if our efforts are creating the desired outcome. As our resort creates initial increments of the product, it can monitor how often young couples purchase the rainforest hike package, how much they’re willing to pay, and what they say would make it better.

The Product Goal helps us understand what should be in the Product Backlog and what should be out of it. Our resort’s goal is targeting young couples, so the team can weed out child-friendly options for the product.

How Does the Product Goal Help the Product Owner?

I’ve seen a lot of Product Backlogs that are huge lists of unrelated requests. We just shove it in the junk-drawer and don’t think about whether or not we really need it. With a Product Goal being in the Product Backlog and the rest of the Product Backlog emerging around that, we can always validate our PBIs against the Product Goal. Should this be in here? Would this contribute to the Product Goal? When someone wants to ask the team to do something, it gives Scrum Teams a way to avoid non-value-added work or at least work that doesn’t contribute to the Product Goal.

Because remember, the Product Owner can delegate Product Backlog Management activities to others. With a Product Goal that provides guidance to those delegates as to what they should be doing, activities like Product Backlog refinement become easier.

The Scrum Guide also says that “The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next”.

I love this statement because it will help teams focus. A lot of teams face the problem of being asked to do too much. They are asked to work on multiple products or work on multiple goals within one product. Sometimes there’s not a specific product at all that they have in mind, they’re just working through that requirements junk drawer.

That damages morale, it damages performance. It damages the ability to deliver value for the organization.

With a Product Goal, and the expectation that the Product Backlog by and large contains items that emerge as a result of that Product Goal, we can make much more meaningful Sprint Goals. Remember that initial criticism that I talked about that teams lurch from Sprint to Sprint without any overall vision. This really helps that Sprint become a step toward the Product Goal which is a step towards a product vision. I’ll talk about the Sprint Goal and Sprint Planning in the next episode.

Having a Product Goal means that when the Product Owner isn’t available during a Sprint, Developers can make decisions about Product Backlog Items they’re working on to align what they’re building with the Product Goal. Because sometimes the Product Owner isn’t available.

People take vacations, for one thing. But beyond that, a Product Owner isn’t going to be with the Developers 100% of the time. Not if they’re going to be doing the rest of the job well, which is to be talking to stakeholders, understanding what they need. Talking to customers, understanding what they need. Doing market research. What is the competition doing? That all takes away from the Product Owner’s availability to Developers. With a solid Product Goal, Developers can move forward in the absence of the Product Owner, and then they can coordinate with their Product Owner when the Product Owner becomes available again.

The Product Goal helps the Product Owner move beyond being a mere order taker. Often, new Product Owners are just receivers of requirements. They’re told, “You just write down what stakeholders tell you. Your contribution is ordering the list, but we’re going to get all the stuff stakeholders ask for”. Those Product Owners are just proxies or scribes.

What’s better is when Product Owners can move away from that receiver of requirements stance and instead create a stance where they are initiating requirements. Where they are a true representative of what’s good for the business and what’s good for the product. Here’s how this product will help the business. When someone asks for a new feature, the Product Goal helps a Product Owner take a stand: That aligns with the Product Goal or it doesn’t, and here’s why. This helps Product Owners move toward an entrepreneurial stance which helps in creating good, valuable products.

Getting More out of Using Scrum

So, if you want to get more value out of using Scrum, make sure you have a strong Product Goal. Empower Product Owners and the Scrum Teams of which they are a critical part, to focus on realizing that goal.

Next up, we’ll talk about how the new emphasis on the Sprint Goal as a commitment in the Sprint Backlog changes our approach to Sprint Planning. Meanwhile, I’d love to hear what you think. 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 one of a three part series on the new Scrum Guide, Professional Scrum Trainer Sam Falco answers the question: "How Has the Product Goal Changed with the New Scrum Guide?"

What’s New in the Scrum Guide?

The more I think about the new edition of the Scrum Guide, the more excited I am about the changes. Scrum is still Scrum of course. Nothing changed about how Scrum works or the value it brings.

But by stripping out prescriptive elements, Ken and Jeff have given us a Scrum Guide that makes its purpose and value clearer. Organizations that truly embrace this iteration of Scrum are going to supercharge their product development efforts.

Dan Neumann and I talked about the changes to the Scrum Guide in episode 106 of The Agile Coaches’ Corner podcast, titled “What’s new with Scrum?” That was a few days after the Scrum Guide came out. Now that we’ve had time to absorb the changes, I wanted to revisit them. In this three-part series, I’ll examine three changes that I think organizations using Scrum need to pay close attention to. And the one I’m going to talk about in this episode is the introduction of the Product Goal as the commitment associated with the Product Backlog.

The Product Goal and the Product Backlog

As I mentioned in episode 106, a criticism that I’ve seen levied at Scrum is that it doesn’t provide a unified vision for the team to work toward. Without that vision, the team lurches from short-term goal to short-term goal and Developers struggle to understand what they’re building and why they’re building it.

It’s true that Scrum didn’t tell you to create that goal. Of course, nothing prevented a Product Owner from doing that, either, and the best Product Owners I’ve worked with did just that. With the Scrum Guide making that Product Goal an explicit part of Scrum, it’s going to make a big difference in the way people look at how they’re practicing Scrum. Here’s what the Scrum Guide has to say about the Product Goal:

“The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define ‘what’ will fulfill the Product Goal”.

So, the Product Goal is the why and the rest of the Product Backlog is the what.

I like that statement because it describes a future state of the product to plan against. I think this shows us what the difference is between a Product Goal and a Product Vision.

How Does the Product Goal Create a Broader Vision?

You’ve probably heard of SMART goals. SMART being an acronym for specific, measurable, achievable, relevant, and time-bound.

A product vision may lack some of those characteristics.

Let’s imagine we are running a vacation resort and our vision is to become the destination of choice for travelers to our region. That is pretty broad, rather than being specific. It’s not measurable — or at least it’s not easily measurable. We don’t know if it’s achievable until we try. It is relevant to our business, but there’s no time statement in there. So it’s not a SMART goal. It’s inspiring, but by itself, that vision is not enough to give a Scrum Team what they need to know and how to move forward.

A Product Goal is a concrete step toward realizing that broader vision. It’s at the very least specific and measurable. We might not know if it’s achievable or realistic until we try. It might be time boxed, but it isn’t always. Sometimes, instead of setting a release date, the release boundary is the features the product must have. The release date is flexible. Often, of course, we have a time constraint. For our imaginary resort, we might want to make a new product available around the time people start planning their vacations for our tourist season.

So, our imaginary resort’s vision is to be the destination of choice for travelers to their region. What does a Product Goal look like?

It might be something like, “Create a rainforest hike package that will appeal to young couples”. That is specific and measurable: We know what it is we’re trying to achieve; we know who we’re targeting, and we will know when we’ve achieved it.

Looking back again at that definition of Product Goal: The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define WHAT will fulfill the Product Goal. That has some specific benefits.

The Product Goal creates transparency. We know why we’re building the product, and we know whether it makes sense to keep building this product. Is the “why” still a concern? If not, we can end the product development effort. Our imaginary resort can look at whether young couples are responding to our offerings, or whether they even travel to our region at a rate high enough to justify the cost of developing the new product.

The Product Goal helps us understand what value we expect to create so we can validate if our efforts are creating the desired outcome. As our resort creates initial increments of the product, it can monitor how often young couples purchase the rainforest hike package, how much they’re willing to pay, and what they say would make it better.

The Product Goal helps us understand what should be in the Product Backlog and what should be out of it. Our resort’s goal is targeting young couples, so the team can weed out child-friendly options for the product.

How Does the Product Goal Help the Product Owner?

I’ve seen a lot of Product Backlogs that are huge lists of unrelated requests. We just shove it in the junk-drawer and don’t think about whether or not we really need it. With a Product Goal being in the Product Backlog and the rest of the Product Backlog emerging around that, we can always validate our PBIs against the Product Goal. Should this be in here? Would this contribute to the Product Goal? When someone wants to ask the team to do something, it gives Scrum Teams a way to avoid non-value-added work or at least work that doesn’t contribute to the Product Goal.

Because remember, the Product Owner can delegate Product Backlog Management activities to others. With a Product Goal that provides guidance to those delegates as to what they should be doing, activities like Product Backlog refinement become easier.

The Scrum Guide also says that “The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next”.

I love this statement because it will help teams focus. A lot of teams face the problem of being asked to do too much. They are asked to work on multiple products or work on multiple goals within one product. Sometimes there’s not a specific product at all that they have in mind, they’re just working through that requirements junk drawer.

That damages morale, it damages performance. It damages the ability to deliver value for the organization.

With a Product Goal, and the expectation that the Product Backlog by and large contains items that emerge as a result of that Product Goal, we can make much more meaningful Sprint Goals. Remember that initial criticism that I talked about that teams lurch from Sprint to Sprint without any overall vision. This really helps that Sprint become a step toward the Product Goal which is a step towards a product vision. I’ll talk about the Sprint Goal and Sprint Planning in the next episode.

Having a Product Goal means that when the Product Owner isn’t available during a Sprint, Developers can make decisions about Product Backlog Items they’re working on to align what they’re building with the Product Goal. Because sometimes the Product Owner isn’t available.

People take vacations, for one thing. But beyond that, a Product Owner isn’t going to be with the Developers 100% of the time. Not if they’re going to be doing the rest of the job well, which is to be talking to stakeholders, understanding what they need. Talking to customers, understanding what they need. Doing market research. What is the competition doing? That all takes away from the Product Owner’s availability to Developers. With a solid Product Goal, Developers can move forward in the absence of the Product Owner, and then they can coordinate with their Product Owner when the Product Owner becomes available again.

The Product Goal helps the Product Owner move beyond being a mere order taker. Often, new Product Owners are just receivers of requirements. They’re told, “You just write down what stakeholders tell you. Your contribution is ordering the list, but we’re going to get all the stuff stakeholders ask for”. Those Product Owners are just proxies or scribes.

What’s better is when Product Owners can move away from that receiver of requirements stance and instead create a stance where they are initiating requirements. Where they are a true representative of what’s good for the business and what’s good for the product. Here’s how this product will help the business. When someone asks for a new feature, the Product Goal helps a Product Owner take a stand: That aligns with the Product Goal or it doesn’t, and here’s why. This helps Product Owners move toward an entrepreneurial stance which helps in creating good, valuable products.

Getting More out of Using Scrum

So, if you want to get more value out of using Scrum, make sure you have a strong Product Goal. Empower Product Owners and the Scrum Teams of which they are a critical part, to focus on realizing that goal.

Next up, we’ll talk about how the new emphasis on the Sprint Goal as a commitment in the Sprint Backlog changes our approach to Sprint Planning. Meanwhile, I’d love to hear what you think. 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 joined by his regular guest/co-host, Sam Falco! Together, they’re exploring the topic of agility and some of the early decisions that either create difficulties or opportunities as organizations are moving towards agility.

 

The decisions that you make early on with your organization can strain you in ways that are unforeseen. It’s one of the reasons why agile coaches and leaders often say: “Don’t make a lot of decisions about your product up-front until you get some data back.” In this conversation, Dan and Sam highlight the key differences between the decisions that are made up-front that can impede a team in the long term vs. the decisions that can help move an organization forward in the right direction.

 

Key Takeaways

Why you shouldn’t make major decisions up-front:

Making a lot of decisions (or major decisions) up-front can often strain you in ways that are unforeseen

You shouldn’t make many decisions about your product up-front until you get some data back

I.e. If you build your entire architecture platform before you deliver any business features, you’re constraining yourself because you’ve built a lot of things that may never get used

The same goes for organizational design (if you make too many decisions about how you’re going to ‘do agile,’ you’ll experience constraints later on

Agility is suited for conditions of high uncertainty, so when you try to apply predictive thinking to an evolutionary approach you’ll run into many challenges

Decisions that are made up-front that can impede a team in the long term:

Avoiding rework (it is sometimes needed/important to revisit decisions you’ve made in the past and fix them)

I.e. If the bone that you broke when you were 10 healed wrong, you’re going to have to break it again to fix it — the same goes for some of the decisions you make in your organization (i.e. re-platforming)

Solution: Take on an experimental mindset and ask, “What would it look like to intentionally take on some rework?”

The key thing to say to clients that are resisting rework would be: “Rework for the sake of rework is bad. But, look at the value you can get and make a good decision based on that.”

Dedicated individuals on a team vs. shared resources across many teams

“We have to have people on multiple teams because we’ve got so much going on.” That’s a problem in itself — limit your work in progress; you’ve got too much going on

Solution: Stop saying, “We can’t do that,” and instead start asking, “How can we?”

Another team-oriented decision that can cause problems later is component teams vs. feature teams

It is better to all work together on the same thing and get it done rather than handing it off from team-to-team

Having one person do two roles (i.e. they’re the Scrum Master and the Product Owner)

If someone is trying to balance two roles they won’t do either well

Solution: Take a look at the roles and make sure that they’re being filled in a way that gives a person a chance to be effective

“Scrum has too many meetings”

Solution: Have everyone attend the same meetings which will eliminate additional meetings for separate teams — transparency and communication are key

New Scrum teams using the thinking of, “Let’s just put all of the items into the backlog, and then we will work the backlog until it is empty.”

This comes from a place of not trusting or understanding incremental delivery

Key takeaways and final tips:

Apply a systems-thinking pattern and an experimental mindset

Abandon the illusion that we can predict the future and that we can control the outcome

Having a forecast of where you’re going is valuable but it is important to realize that it is not certain

 

Mentioned in this Episode:

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

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

26 Marathons: What I Learned About Faith, Identity, Running, and Life from My Marathon Career, by Meb Keflezighi with Scott Douglas

 

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 his regular guest/co-host, Sam Falco! Together, they’re exploring the topic of agility and some of the early decisions that either create difficulties or opportunities as organizations are moving towards agility.

 

The decisions that you make early on with your organization can strain you in ways that are unforeseen. It’s one of the reasons why agile coaches and leaders often say: “Don’t make a lot of decisions about your product up-front until you get some data back.” In this conversation, Dan and Sam highlight the key differences between the decisions that are made up-front that can impede a team in the long term vs. the decisions that can help move an organization forward in the right direction.

 

Key Takeaways

Why you shouldn’t make major decisions up-front:

Making a lot of decisions (or major decisions) up-front can often strain you in ways that are unforeseen

You shouldn’t make many decisions about your product up-front until you get some data back

I.e. If you build your entire architecture platform before you deliver any business features, you’re constraining yourself because you’ve built a lot of things that may never get used

The same goes for organizational design (if you make too many decisions about how you’re going to ‘do agile,’ you’ll experience constraints later on

Agility is suited for conditions of high uncertainty, so when you try to apply predictive thinking to an evolutionary approach you’ll run into many challenges

Decisions that are made up-front that can impede a team in the long term:

Avoiding rework (it is sometimes needed/important to revisit decisions you’ve made in the past and fix them)

I.e. If the bone that you broke when you were 10 healed wrong, you’re going to have to break it again to fix it — the same goes for some of the decisions you make in your organization (i.e. re-platforming)

Solution: Take on an experimental mindset and ask, “What would it look like to intentionally take on some rework?”

The key thing to say to clients that are resisting rework would be: “Rework for the sake of rework is bad. But, look at the value you can get and make a good decision based on that.”

Dedicated individuals on a team vs. shared resources across many teams

“We have to have people on multiple teams because we’ve got so much going on.” That’s a problem in itself — limit your work in progress; you’ve got too much going on

Solution: Stop saying, “We can’t do that,” and instead start asking, “How can we?”

Another team-oriented decision that can cause problems later is component teams vs. feature teams

It is better to all work together on the same thing and get it done rather than handing it off from team-to-team

Having one person do two roles (i.e. they’re the Scrum Master and the Product Owner)

If someone is trying to balance two roles they won’t do either well

Solution: Take a look at the roles and make sure that they’re being filled in a way that gives a person a chance to be effective

“Scrum has too many meetings”

Solution: Have everyone attend the same meetings which will eliminate additional meetings for separate teams — transparency and communication are key

New Scrum teams using the thinking of, “Let’s just put all of the items into the backlog, and then we will work the backlog until it is empty.”

This comes from a place of not trusting or understanding incremental delivery

Key takeaways and final tips:

Apply a systems-thinking pattern and an experimental mindset

Abandon the illusion that we can predict the future and that we can control the outcome

Having a forecast of where you’re going is valuable but it is important to realize that it is not certain

 

Mentioned in this Episode:

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

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

26 Marathons: What I Learned About Faith, Identity, Running, and Life from My Marathon Career, by Meb Keflezighi with Scott Douglas

 

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, Sam Falco is joined by Andrea Chiou to discuss the topic of clean language!

In their conversation, they discuss clean language; what it is, what it is not, where it originated from, its applications, and the barriers or challenges to using clean language (and how to address them). Andrea also outlines key clean language questions, how to know when and where to use them, and what you can do to further improve your clean language!

Andrea Chiou’s past work includes many roles within IT, from developer to business and process analyst, technical lead, and PM. Her main focuses include Scrum, Kanban, strategy, facilitation, remote working, product visioning, conflict management, leadership, user experience, clean language, organizational learning, and coaching. Andrea’s mission is to help people at work connect to one another so that the best possible outcomes are available not only in the moment but over a sustained period.

Key Takeaways

• What is clean language?
  • A label that describes a set of questions that are used in a process to help people think through their intentions and better understand one another
  • Non-leading questions that elevate and amplify the inherent diversity of skills, knowledge, and styles of working in a team
  • A powerful way of getting everyone to pay attention to one another and create a system of learning, listening, inquiry, and mutual support
  • It is a set of 12 core questions that are non-leading and assumption-free
  • The use of these short “clean questions” puts the emphasis on the keywords that demonstrate to the person that you’re asking that you are hearing them and you empathize with them (i.e. you’re using their words, not your interpretation of their words)
• Where clean language originated from:
  • There are four main branches of how clean language has evolved: 1) symbolic modeling 2) systemic modeling 3) clean space 4) clean interviewing
• Clean language applications:
  • When interviewing others to gather information (ask questions that are not leading, so as not to influence the answers)
  • It is often used in person-change work (coaches, counselors, psychologists, etc.)
  • It can be used as an information-gathering tool by market researchers, journalists, business and systems analysts, developers, etc.
  • Using clean language in a team setting improves communication, empathy, and understanding
• Barriers or challenges to using clean language:
  • Even though you’re using someone else’s words it may go unnoticed or be done in a way that can make someone feel uncomfortable
  • It’s easy to learn, but, much like Scrum, takes a lot of practice and support to become good at it
  • It can be challenging to know when to use it
  • Especially in IT, the pace and the need for quickness often hampers people’s ability to actually listen well
• How to use clean language questions:
  • Two of the most common questions are 1) “What kind of…?” and 2) “Is there anything else about...” These get at the “nitty-gritty” details
  • You put your attention on the person you’re asking the questions to and hearing them fully
  • Repeating their words when asking follow-up questions, inviting them to continue
• List of clean language questions:
  • Developing Questions
    • What kind of X?
    • Is there anything else about X?
    • Where is X? or Whereabouts is X?
    • Is there a relationship between X and Y?
    • When X, what happens to Y?
    • That’s X like what?
  • Sequence and Source Questions
    • Then what happens? or What happens next?
    • What happens just before X?
    • Where could X come from?
  • Intention Questions
    • What would X like to have happen?
    • What needs to happen for X?
    • Can X (happen)?

Mentioned in this Episode:

• Agile Coaches’ Corner 101: “Are Scrum Masters Expendable?”
• Clean Language: Revealing Metaphors and Opening Minds, by Wendy Sullivan and Judy Rees
• The Work and Life of David Grove: Clean Language and Emergent Knowledge, by Carol Wilson
Tenable
• Agendashift
• Agendashift: Outcome-oriented change and continuous transformation, by Mike Burrows
• Right to Left: The digital leader's guide to Lean and Agile, by Mike Burrows
• Deep Listening — Impact Beyond Words Podcast by Oscar Trimboli

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on http://agilethought.com/podcast!

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