Agile Coaches' Corner

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 Podcast@AgileThought.com 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 Podcast@AgileThought.com 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 Podcast@AgileThought.com 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 podcast@agilethought.com. 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 Podcast@AgileThought.com 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 podcast@agilethought.com. 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 Podcast@AgileThought.com 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 podcast@agilethought.com. 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 Podcast@AgileThought.com 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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!