Created with Sketch.
Agile Coaches' Corner
32 minutes | 7 days ago
Can a Scrum Master Handle Multiple Teams?
In this episode, Sam and Dan take a deep dive into a fantastic listener question, “What happens in a scaling environment with the Scrum Master?” What happens when you have one Scrum Master with many teams or many teams and multiple Scrum Masters? With the Scrum Guide not explicitly providing guidance on this topic, Dan and Sam explore the realities of focusing on multiple teams as a Scrum Master, whether or not a Scrum Master can or should handle multiple teams, and real-world examples of scenarios they have seen play out with both. They also discuss the risks and challenges that come along with multiple Scrum Masters coordinating across many teams and share their advice on increasing communication and helping your teams (and organization) understand Scrum. Key Takeaways Can a Scrum Master handle multiple teams? With so much on your plate as a Scrum Master, it is ideal to only handle one team at a time (especially if they’re very early on in their Scrum journey; they’re going to need a lot of your attention and focus) It is possible to handle multiple teams but it is dependant on how far they are into their Scrum journey (if one of them is far along and another is newer, it is far easier to manage multiple) It doesn’t make sense to split a Scrum Master’s attention between multiple teams if they are all start-ups As a Scrum Master, you are already splitting your attention between your team and the organization (in helping them use Scrum effectively) — dividing your attention even further between teams can spread you too thin If you are acting as more of an Agile Coach with less focus on the organization, it may be possible to handle multiple teams An ideal scenario would be to have a Scrum Master master per team in the organization and have them coordinate and communicate across these teams Note: In order to be a great Scrum Master, you need to look beyond limiting your role to organizing meetings, enforcing timeboxes, and responding to the impediments people explicitly report (reference Michael James’ Scrum Master Checklist to see the full breadth of what you could be doing in your role as a Scrum Master [if you have the time and capacity]) Advice for multiple Scrum Masters coordinating across multiple teams: Have a Scrum Master Community of Practice — make sure that the Scrum Masters are meeting regularly to discuss what’s going on in their teams When a Community of Practice is successfully implemented, you can exchange new ideas which can really help the agility of the teams and the entire organization You can work together on the common challenges you are all facing and rally together to figure out solutions Your understanding of Scrum and your ability to help teams will grow exponentially A cautionary word about establishing a Community of Practice: you may not get outside ideas as easily which can develop a sense of “groupthink” Be sure to seek outside ideas — always ask: “What are we not doing? And what can we learn from the broader community?” (Try attending conferences, events, or webinars) Get outside of your organization’s four walls whether that be through podcasts, books, or other resources — always be open to grow The risks of Scrum Masters coordinating across too many teams: The teams may struggle to understand the need for Scrum itself (the “why” behind Scrum becomes lost when Scrum Masters cannot spend enough time with a single team) which leads to dysfunctional behavior Being commanded to do things for the sake of doing them rather than “We need to do Scrum to deliver well” leads teams to become disengaged Simply finding the time to do sprint planning together and coordinate the teams Closing thoughts and key takeaways: The Scrum Master is an invaluable part of the Scrum team — do not try to short change your teams in order to save a little money (i.e. by spreading them thin in managing multiple teams) The Scrum Master will help your team be effective and stay effective By having a Scrum Master focus on one team they can better help them integrate with the larger organization If you need to have multiple teams per Scrum Master, try to have some balance (in that not all of their teams are new or old) Mentioned in this Episode: Michael James’ Scrum Master Checklist The Scrum Guide Tampa Bay Scrum Masters Guild The Nexus Integration Team Agile Coaches’ Corner Ep. 126: “What is Agile?” Agile Coaches’ Corner Ep. 3: “Communities of Practice with Quincy Jordan” Frederick W. Taylor “Managing the Development of Large Software Systems,” by Dr. Winston W. Royce The Legacy of Conquest: The Unbroken Past of the American West, by Patricia Nelson Limerick Ph.D. The Dead March: A History of the Mexican-American War, by Peter Guardino 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!
36 minutes | 14 days ago
Excursions Along the Agile Journey with Quincy Jordan
Oftentimes, when organizations bring on Agile Coaches, they want to be (or expect to be) taken on a linear path with Agility (AKA point A to point B). However, there is a lot that happens along an Agile transformation journey that interrupts this path of “point A to point B.” Today’s guest, Quincy — a Director in AgileThought’s Innovate Line of Service — refers to these as “excursions.” In an Agile transformation journey, it is crucial to explore these excursions and understand all of the pieces that you should put into place to ensure their success. In this conversation, Quincy explains what excursions are, why they are important; the different types of excursions that can occur during an Agile journey; the key areas of sustainability, consistency, competency, and maintenance in an excursion; and the important pieces that leadership support and communication play in an excursion’s success. Key Takeaways What are “excursions?” Excursions are detours that happen along an Agile transformation journey These excursions often involve many different facets An excursion could be taking a business outcome (such as “better speed to market”) and getting more specific and nuanced on it An excursion is still part of the transformation journey (so you can’t isolate it from the work that the teams are doing) Several excursions can occur at the same time What are some of the types of excursions that can occur during an Agile journey? Clarity of desired business outcomes Better speed to market Introducing a new product Introducing a product that you already have into a new market Quincy’s advice about excursions: Sometimes you may have to bring on a new expert during an excursion that specializes in that specific area and bring them into the journey (in cases like these, it is important to acknowledge your and your team’s knowledge barriers) Really consider who should be a part of each particular excursion There are many aspects to the Agile transformation and many different types of excursions — it is important to not box things in and know that it is a multifaceted journey Advice around the Agile approach to excursions: Sometimes Scrum might not always be the best fit for your organizations so it is important to have an excursion that serves as an evaluation to figure out which Agile approach is best for the team/s (and which approach is best where — because there may be more than one approach [alternatively, agility might not even be the right approach at all]) Excursions should also be taken to discover which methodologies and frameworks should be used Some organizations, when they’re new in their transformation journey, tend to make assumptions rather than take excursions (but it’s crucial as an organization to take excursions because no two companies are alike and one company’s approach may not work for yours) Experimentation in and of itself can become an excursion Areas of sustainability, consistency, competency, and maintenance in an excursion: In aiming towards sustainability, it is important to ask whether or not you have put the pieces of the puzzle in place so that the system can run on its own You can’t reach sustainability without consistency It’s important to have a consistent definition of “done” (if every team has a different definition, it will be hard to consistently deliver quality) Leverage the strengths that are already within the teams and company Though the maintenance is part of the journey, it’s more so post-journey and is becoming more and more critical for companies to do Maintenance is really critical — Ask yourself: How do you maintain what has now been transformed? How do you maintain the culture that you’ve now built, the consistency that you have put in place, and keep a freshness to the cadences of the workflow? If you don’t have a maintenance piece in place, many of your efforts will be derailed Your excursions need to have sustainability, consistency, and an understanding of what maintenance is going to look like from the get-go The important pieces of leadership support and communication in an excursion: Consistency and sustainability need to be supported by leadership Leadership has to let everyone know periodically that everything is okay or “Everything will be okay, but these are the things we’re dealing with right now” (Communication is key) Active leadership is key in a transformation journey As a leader, you can’t negate sharing the bigger picture so that the teams can consistently correlate what they’re doing on a daily basis to the bigger business outcomes Quantity does not always equal value (as a leader it is important for you to consistently support your team/s on a regular cadence in an active way) Mentioned in this Episode: Quincy Jordan McKinsey’s Three Horizons Model The Cynefin Framework Agile Coaches’ Corner Ep: “Spotify, Schmotify: Do Your Own Agile Thinking” Agile Coaches’ Corner Ep: “Exploring an Experimental Mindset with Adam Ulery” The Reengineering Alternative, by William Schneider 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!
37 minutes | 21 days ago
The Three Key Changes to the Scrum Guide That Organizations Need to Pay Attention to
This week on the Agile Coaches’ Corner Dan and Sam are switching things up with a new episode format. In this episode, they’re looking back on Sam’s three-part Trainer Talk series on the key changes that were made in the new Scrum Guide that was released in November 2020. This episode compiles all three of Sam’s Trainer Talks that focus on the three key changes that were made to the Scrum Guide around the product goal, the sprint goal, and self-organizing teams. Sam shares his thoughts on why these changes are important to recognize; what these changes mean for organizations, Scrum Teams, and Product Owners; and the specific benefits that come with these changes. Tune in to learn all about the three key changes that organizations using Scrum need to pay close attention to! Key Takeaways How has the Product Goal Changed with the New Scrum Guide? Why is it important and what are the benefits? 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” The Scrum Guide is now making the Product Goal an explicit part of Scrum (which is crucial in creating a unified vision for the team to work toward) This change highlights the difference between a Product Goal and a Product Vision which is important because a product vision is lacking the characteristics of SMART goals (“specific, measurable, achievable, relevant, and time-bound” goals) With the Product Goal in the Product Backlog, the rest of the Product Backlog emerges to define WHAT will fulfill the Product Goal (this has specific benefits such as creating transparency, understanding what the value is that is expected to be created so that the team can validate if their efforts are creating the desired outcome, and in helping the team understand what should be in the Product Backlog vs. what should be out of it) With a Product Goal being in the Product Backlog and the rest of the Product Backlog emerging around that, it is possible to validate PBIs against the Product Goal 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” (which is hugely beneficial as it will help teams focus) 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, it is possible to make much more meaningful Sprint Goals The Product Goal helps the Product Owner move beyond being a mere order taker and, instead, create a stance where they are initiating requirements How has the Sprint Goal Changed with the New Scrum Guide? Why is it important and what are the benefits? The new Scrum Guide underscores the commitment and purpose of a Sprint Goal Jeff and Ken introduce a new topic for Sprint Planning in this update, which is: “Why is this Sprint valuable?” (In other words, “What do we hope to get out of it?”) — Asking this question helps craft the Sprint Goal Establishing a Sprint Goal allows the team to create a well-rounded SMART (“specific, measurable, achievable, relevant, and time-bound”) goal If you don’t have a Sprint Goal, the Sprint Backlog becomes just a list of Product Backlog Items to fill up a team’s capacity with no coherence to it With a Sprint Goal, the team is able to create a coherent Sprint backlog that will help them meet their goals and objectives Though there might be things in your Sprint Backlog that are not strongly correlated to the Sprint Goal, 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) Once a Sprint Goal is established and it has helped the team select a coherent group of Product Backlog Items for their Sprint Backlog, the Sprint Goal then helps address the topic of: “How are we going to do it?” Good Sprint planning includes creating a plan for working together and breaking things down into the tasks that the team needs to achieve Without a Sprint Plan, there is a lack of transparency and the Scrum Team cannot see at their Daily Scrums whether or not they are making good progress towards the Sprint Goal The Sprint Goal creates transparency and the ability for a Scrum Team to deliver reliably and predictably each and every Sprint (additionally, it helps establish a sustainable pace, which creates better morale and a more fulfilling work environment) How has Self-Organizing Changed to Self-Managing in the New Scrum Guide? Why is it important and what are the benefits? Even though the change may seem merely semantic, it has a massive impact on how organizations will see Scrum in a new light and will be a shock to those organizations that have not allowed their teams to be self-organizing or self-managing at all When organizations use Scrum but do not allow their teams to be self-managing this leads to a lack of engagement and a lack of ownership; it destroys morale and causes turnover In Daniel H. Pink’s book, Drive, he discovered the three factors that truly motivate knowledge workers are autonomy, mastery, and purpose (and self-managing teams leverage all three of these things [and Scrum done well has all three built-in!]) Scrum gives team autonomy by allowing them to decide what to work on and in setting their own Sprint Goal “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.” — Sam Falco Self-managing teams create less overhead for managers as they don’t have to spend time directing people and telling them what to do “Self-managing is serendipity in development” (when you hand someone a problem, get out of their way, and they will solve it in ways that you never could have imagined [and maybe even better than if you had solved it yourself!]) In complex product development, something new is always going to come up and there is an enormous amount of uncertainty — Scrum allows self-managing teams to adapt to this uncertainty as it arises and every Sprint offers an opportunity to change direction You can work towards self-managing teams by empowering your Product Owners to make decisions and shepherd their products; feeding your teams with objectives, not tasks; setting the boundaries within which your teams can make their own decisions and steer their own course; encouraging the Scrum team as a whole to be accountable toward each other and toward achieving positive outcomes Mentioned in this Episode: The Scrum Guide Agile Coaches’ Corner: Trainer Talk: “How Has the Product Goal Changed with the New Scrum Guide?” Agile Coaches’ Corner: Trainer Talk: “How Has the Sprint Goal Changed with the New Scrum Guide?” Agile Coaches’ Corner: Trainer Talk: “How Has Self-Organizing Changed to Self-Managing in the New Scrum Guide?” Agile Coaches’ Corner Ep. 106: “What’s New with Scrum?” Drive: The Surprising Truth About What Motivates Us, by Daniel H. Pink 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!
28 minutes | a month ago
Are Scrum Masters the CEOs of the Future? with Vasco Duarte
This week, Dan Neumann is joined by a very special guest, Vasco Duarte, the host of the Scrum Master Toolbox Podcast — a daily podcast for Scrum Masters and Agile Coaches. Vasco interviews guests from all over the world to give his listeners actionable advice and daily doses of inspiring conversations to help improve their craft! Vasco himself is a Certified Scrum Master, an Agile Coach, and a Business Consultant. He was also one of the leaders and catalysts of Agile methods and Agile culture adoption at Avira, Nolia, and F-Secure. Together, they’re exploring the concept of Scrum Masters as the CEOs of the future. As Rob highlights in this episode, there are a number of facets that well position Scrum Masters to be the CEOs of our future. He speaks about why this is, his vision for Scrum Masters in general, how you can position yourself as a Scrum Master to take on leadership positions, and some of the challenges you might face as a Scrum Master in a leadership position and how to overcome them. Key Takeaways Why might Scrum Masters be the next CEOS? As a Scrum Master, you learn to lead without pushing people or being a command-and-control leader The traits that are necessary of a Scrum Master would make for a well-rounded CEO (such as servant leadership) Vasco’s vision for Scrum Masters: Servant leadership (or, the leader that serves) Transforming the world of work rather than making sure that events are on the calendar Coaching the organization to actually transform to better use the scrum framework as opposed to simply surviving in the organization they are a part of As a Scrum Master, you define your role in practice every single day “A Scrum Master that can make a leadership team work cohesively and harmoniously toward the good of the company, the good of the customers, and the workers, is a Scrum Master that is at the top of their career.” — Vasco Duarte “I’m asking all … Scrum Masters to take ownership of the role, continue to develop the role, and maybe even develop a full-fledged career path, first starting as a team member … mov[ing] on toward helping teams, helping other Scrum members, and even helping leadership teams to grow.” — Vasco Duarte What makes Scrum Masters better aligned to be successful CEOs: Scrum Masters are already suited to work in domains where they are not specialists in, to help the team succeed The core of the Scrum Master’s role is collaboration (AKA trying to get the team to work better together for the success of the company, the customers, and the workers themselves) which embodies one of the key aspects of the CEO The lack of technical knowledge in a particular area of the organization that a CEO needs to lead will never be an impediment to become a CEO (there is no CEO that knows everything) Scrum Masters should excel in helping the team deliver value A challenge that Scrum Masters should be aware of as their companies move forward in their agile journey: Very often, companies tend to do “big bang agile transformations” by bringing in a bunch of agile coaches that do great work but are then let go (leaving Scrum Masters to pick up the pieces) Solution: Rob encourages that, as a Scrum Master, you should collaborate with these agile coaches that are temporarily brought on and get involved with the transformation early on Solution: Make sure that the teams are not left hanging by preparing the teams from a supported place Mentioned in this Episode: Scrum Master Toolbox Podcast Software Development Today — Vasco Duarte’s Blog Vasco Duarte’s Twitter: @duarte_vasco Vasco Duarte’s LinkedIn Lean Enterprise Institute’s Podcast (WLEI) WLEI Ep: “Boeing Ex-Executive Alan Mulally Discusses a ‘Working Together Management System’” Scrum Master Summit (Week of May 17th, 2021) 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!
31 minutes | a month ago
Why You Should Try Lean Inception with Gabriela Corrêa
This week, Dan is joined by Gabriela Corrêa! For the last three years, Gabriela Corrêa has served as an Agile Coach and Project Manager at BRQ Digital Solutions. Most recently, she has transitioned into the new role of Digital Solutions Specialist within BRQ. Together, they’re talking all about Lean inception. Gabriela shares about the challenges that teams traditionally face when they’re kicking off a project, how to address these early challenges, the activities that are involved in a Lean inception, how to facilitate a successful Lean inception, and where you can get started with you and your team’s own Lean inception! Key Takeaways Challenges that teams traditionally face when they’re starting off a project or are early in the Lean inception: Creating alignment between the whole team and the stakeholders Expectations — it can be hard to guarantee that the product will meet the expectations set in this early stage You may experience issues with the agenda if you do not give yourself and your teams enough time to prepare How to address these early challenges: Have all of the teams focus on the same problems together As laid out in Paulo Caroli’s book, Lean Inception, he suggests that you take five days (an agenda) to align everyone before you begin the project Activities involved in Lean inception: An agenda involving the development team, the active team, and the stakeholders (the goal of which is to provide context to the problems they are facing, the problems the users are facing, and the solution they are going to create) Creating a product vision (which should be able to be summarized in one sentence) “The Product Is — Is Not — Does — Does Not” “Describe the Personas” to understand the final offer of users (their problems, expectations, etc.) “Discover the Features” which include all of the features you’re going to create “Show User Journeys” “Technical, UX, and Business Review” “Sequence the Features” “Build the MVP Canvas” Common challenges around Lean inceptions and how to address them: Sometimes people are closed off because they believe they already know everything there is to know about the problem Solution: Be open, don’t write off different solutions, and be receptive to suggestions and ideas Solution: Don’t throw out your own ideas if they are not used, create a new idea/solution together with your collaborators A lack of understanding around the goal the team is seeking Solution: Have everyone on board with the lean inception workshop (alignment and a clear understanding of the goal can be achieved through this) Sometimes a team of people with very different profiles can seem to “clash” on the surface — but having a diverse team is incredibly powerful and invaluable! You all have very different perspectives and backgrounds and can come together to create a new, innovative solution Additional advice and details about the workshop and its activities: The activities are all highly visual In this remote age of working, Gabriela recommends the tools Miro and Mural for digital collaboration Where and how to get started: Check out the book, Lean Inception: How to Align People and Build the Right Product Join like-minded communities online Visit Caroli.org Mentioned in this Episode: Gabriela Corrêa’s LinkedIn BRQ Digital Solutions Lean Inception: How to Align People and Build the Right Product, by Paulo Caroli Miro Mural Caroli.org Nonviolent Communication, by Marshall B. Rosenberg Lead With Respect: A Novel of Lean Practice, by Michael Balle and Freddy Balle 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!
28 minutes | a month ago
What Is Agile?
Dan and Sam have covered a lot of ground in previous episodes about agility but never the full scope of what exactly is considered agility. Many people have their own unique definitions of what agile is and what it looks like…but when you really dig in, these are often ways that do not seem to be in alignment with the Agile Manifesto or principles. So, in this week’s episode, Dan and Sam are diving into another fantastic listener question to address this topic! Chris on Twitter asked, “What is agile?” They take a deep dive into the history of why the Agile Manifesto was declared, the need that the principles and values were born out of, and ultimately: what is agile. Key Takeaways Why was it important for the Agile Manifesto to be declared? What is the history behind it? It was created in reaction to what was happening in the software industry in 2001 (predominantly waterfall and other predictive methods with bad track records for delivering on time) In response to “scope creep” (AKA changes or uncontrolled growth in a project’s scope at any point after a project begins) Because it is very difficult to predict what you need to do when you’re trying to solve a new problem every time Out of necessity (as any work that requires creativity and a high degree of uncertainty about the outcome you’re trying to achieve [such as software development] is difficult without a set of principles and values) Because every problem is unique with software development In the Harvard Business Review in 1986, an article was published titled, “The New New Development Game” that outlined the need for a new way of working where teams could be given objectives instead of tasks and they work together as a unit to accomplish their work The “relay race” method was clearly not working and agility offered a better model, better compared to playing rugby “Agile wasn’t: ‘Let’s get together and think about a new way of doing things.’ It was: … ‘Hey, we’re doing some things. It seems to be getting better results than the industry as a whole. What are we doing that’s common across the different methods?’” — Dan Neumann Those that came up with the Agile Manifesto didn’t put it together to justify their existence; they put it together because they recognized the success they were having through its methodology and wanted to figure out the commonalities What is the Agile Manifesto? It’s the thing we point to when someone says, “What is agile?” If you’re asking if something is agile, you can reference the manifesto’s values and principles What is agile? It’s creating competitive advantage and being the disruptive force Delivering working software as your primary measure of success A collection of values and principles as laid out in the Agile Manifesto It is the ability to deliberately respond to change and demand; not just react Controlling risk Building stuff that people actually want and will use Solve the problem that the customer has called for and not gold plating everything Agile practices are simply that; practices — they’re good in some circumstances and not good in others Are you changing just to change or are you harnessing change for competitive advantage? Is change happening to you or are you creating the change? Change is not just about keeping up with your competition but making your competition keep up with you Mentioned in this Episode: “The New New Product Development Game,” by Hirotaka Takeuchi and Ikujiro Nonaka | Harvard Business Review (January 1986) Agile Software Development Ecosystems: Problems, Practices, and Principles, by James A. Highsmith The Surprising Power of Liberating Structures: Simple Rules to Unleash A Culture of Innovation, by Henri Lipmanowicz and Keith McCandless LiberatingStructures.com 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!
26 minutes | 2 months ago
Spotify, Schmotify: Do Your Own Agile Thinking
This week, Dan Neumann is joined by his co-host, Sam Falco, principal trainer and professional scrum trainer at AgileThought. Together, they’re exploring a question that was sent in by a listener. They asked Dan and Sam to share their take on “the Spotify Model.” The popularized model was first introduced in 2012 by the whitepaper, “Scaling Agile @ Spotify” and described a “people-driven, autonomous approach for scaling agile that emphasizes the importance of culture and network.” Often, organizations will look at a successful company and say, “How can we emulate what they do?” rather than, “How can we emulate how they think?” There is a desire to mimic a pattern that another organization created because it fits their context, environment, people, and processes. However, installing the Spotify model can be fraught with danger because you’re not Spotify in 2012. If you have your own question for the Agile Coaches’ Corner that you want Dan and Sam to answer in a future episode, you can send it in at AgileThought.com! Key Takeaways Why wouldn’t the Spotify Model work for your organization? Just because you see somebody do something someplace else, doesn’t mean it’s going to work for you — because you’re not them You shouldn’t look at a successful company and say, “How can we emulate what they do?” but rather, “How can we emulate how they think?” (i.e. “the Spotify Model” worked for Spotify, but will not work for your company — emulating is not likely to bring you success) The model may not be applicable — and even if it is, there is going to be resistance and additional challenges will be exposed that will need to be addressed Parallels between how organizations bring in the Spotify Model vs. how they bring in the Scrum framework: With both, if you don’t do all of the elements, success is less likely The Scrum framework, however, is a lot easier to adopt (preferably, adopt the Scrum framework and use it to find out what processes work for your organization) Installing the Spotify Model can be fraught with danger because you’re not Spotify in 2012 You could try implementing some of the Spotify Model’s approaches (but most importantly, make sure it works for your organization) When it comes to implementing any type of framework or model, the early questions should be: “What do you hope to accomplish? Why do you want to install this model or adopt this framework? What’s not working for you now and how do you think this will fix it?” This way, you can evaluate and measure Regardless of what model you’re proposing, think about: What does success look like? Why are you doing it? What is the problem you’re trying to solve? Tips for adopting any model or framework: Look at what’s working (and not working) within your own organization and have discussions on what to do next based on this Adopt an experimental mindset Be clear about the problem(s) you’re trying to solve as an organization Be clear about how you’re measuring success Look at all of the components of whatever you’re trying to adopt and ask, “How will this work here?”, “What will prevent this from happening?”, and “What exists in our current system that is antithetical to these components?” Approach the question of “Should we adopt _______ model or framework,” with empathy and humility — whatever is being suggested (by whoever it may be) is trying to help the organization; not hurt it How to ensure that implementation of a model or framework is successful: Facilitate and make sure that you have all levels of the organization involved Ask: “How is it that we can maintain our current system and adopt a new system and still be successful?” Remember: The current system is not going to change overnight Note: Your journey will not be a straight shot from point A to point B No matter the model or framework, the organization’s DNA is going to respond in unexpected ways — be prepared for the unexpected Bureaucracy kills innovation — if you want to be innovative, you need to kill bureaucracy It can be extremely beneficial to get an outside perspective and bring someone in outside of your organization Mentioned in this Episode: The Spotify Model “Scaling Agile @ Spotify,” by Henrik Kniberg & Anders Ivarsson Humanocracy: Creating Organizations as Amazing as the People Inside Them, by Gary Hamel and Michele Zanini Agile Coaches’ Corner Ep. 5: “Exploring an Experimental Mindset with Adam Ulery” Agile Coaches’ Corner Ep. 120: “Build Better Teams with Sam Falco” The Tuckman Model Jira LiberatingStructures.com Wicked Questions | LiberatingStructures.com Agile Coaches’ Corner Ep. 122: “The Journey of an Agile Transformation with Quincy Jordan” “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” — Norman KerthProject Retrospectives: A Handbook for Team Review, by Norman L. Kerth Buyology: Truth and Lies About Why We Buy, by Martin Lindstrom 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!
36 minutes | 2 months ago
Remote Facilitation 101 with Kristen Belcher
Today, Dan Neumann is joined by Kristen Belcher, an Agile Coach who is saving the world, one retrospective at a time! Kristen’s focus is all around developing genuine human connections and relentlessly pursuing improvement. She enjoys working with technical people to solve business problems and thrives on helping people find ways to make their jobs — and lives — easier and more fulfilling via better communication and technology. And more than anyone else, Kristen knows that facilitation can be fun, challenging, and incredibly rewarding — which is the topic of today’s episode! In this conversation, Kristen shares her insights on how to effectively facilitate remotely. As someone incredibly knowledgeable on all things facilitation, Kristen shares how to make facilitation impactful and memorable, techniques for effective remote facilitation, what not to do when facilitating, and all of the other things you need to consider with remote facilitation! Key Takeaways The importance of good facilitation: It can make exercises incredibly impactful and memorable It can help a group’s ability to collaborate effectively Challenges of doing good facilitation: Reading the room (especially virtually in this COVID-19 era) can be difficult (you can’t tell when people are getting tired or losing focus, getting confused, etc.) Solution: A virtual indicator that is available to your audience that they may need to take a break which can help revamp the energy Collaboration can be difficult virtually Solution: Implement virtual collaboration tools (such as Whiteboard or Miro) Solution: Create different opportunities to interact with the space (whether that’s through audio, video, text, or an online whiteboard) — this makes for a rich environment and can simulate similar engagement that you would get in a physical space Solution: With larger groups, have a shared visual to help keep the focus Tip: Consider exercises — they can be super helpful for engagement and collaboration Techniques that are effective for remote facilitation: Check-in at the beginning Create a comfortable, safe space Ensure that the meeting will run smoothly by making sure people have access to the online session beforehand For engagement, you can send participants physical materials (handouts, sticky notes, sharpies, etc.) that you would have in a physical space Nurture human connection (this is important in a physical space but it is even more crucial in a virtual space) Utilize breakout rooms Create a safe environment by giving people the ability to be autonomous, have mobility, and leave when/if they need to (AKA the “law of two clicks”) After you are done facilitating (or participating in facilitation) it is important to signal to your brain that work is done (i.e. by changing out of your “work” clothes, closing your blinds, shutting your computer down, etc.) Finishing your meeting and closing the space is really important not only for you but for everyone in attendance as well How not to facilitate: If the space is virtual, do not force people to get on video (instead, extend the invite to get on video) Don’t assign a heavy amount of “pre-work” or homework to do before the session (i.e. read an entire paper, fill out a large form, etc.) Don’t surprise someone by asking them to facilitate on the spot (i.e. don’t invite a coach to a retrospective and ask them to facilitate when they arrive) — be sure to ask them in advance! What to consider with remote facilitation: Be prepared and make sure it’s accessible Have security with your company in place Master your remote facilitation tools Remote facilitation takes more preparation than physical facilitation so make sure to set it up beforehand so it all goes smoothly Does everything need to be facilitated? Not every conversation needs to be facilitated If you’re already familiar and comfortable with the group you’re speaking with, you don’t always need to Mentioned in this Episode: Kristen Belcher’s LinkedIn Rock Central VertaforeWhiteboard Miro Enabling breakout rooms on Zoom Use breakout rooms in Google Meet Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen Microsoft Teams The Remote Facilitator’s Pocket Guide, by Jay-Allen Morris and Kirsten Clacey The Facilitator’s Guide to Participatory Decision-Making, by Sam Kaner 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!
36 minutes | 2 months ago
The Journey of an Agile Transformation with Quincy Jordan
This week on the podcast, Dan Neumann is exploring the journey of an agile transformation with Quincy Jordan, a Director in AgileThought’s Innovate Line of Service. Agile is no longer the new kid on the block. However, when a new organization decides that they want to benefit from adopting an agile practice, they are sometimes not aware that agility is a journey — not something where you install agile and walk away. This sometimes leads them to run into problems early on. In this conversation, Quincy highlights some of these areas and challenges that organizations run into as they go through their agile journey and how to overcome them. Key Takeaways Why is it important to understand that agile is a journey? When it comes to an agile transformation, it is important to understand that you can’t just install agile and walk away — it’s a journey “What other journey takes a linear path? There is no journey that takes a linear path. … So, really why [do] we think agile will be any different?” — Quincy Jordan How to start your agile transformation journey on the right foot: Lead with: ‘Why do we want to take this journey, to begin with?”, “Why do we want to go down this agile path?” Set out to solve a specific set of problems Identify opportunities you’re looking to create The benefits of business agility in an organization: Business agility will allow organizations to move quicker with the market Those who can learn, and unlearn, and relearn the fastest are going to be the ones to excel the most You can respond to changes in the marketplace and pivot much faster Important notes on cultural debt: Does your current culture allow for a change in culture to take place? When it comes to an agile transformation, a shift in culture cannot come last because everything else is part of it (and if it does come last, you’re building massive cultural debt) Deciding is a big indicator of culture How communication happens can be an indicator of cultural debt The culture should not be one of ‘burning the midnight oil’ or unsustainable heroics — you get more productivity out of healthy, satisfied employees What an organization needs to know as they move through their agile journey: The organization has to become comfortable with being able to move forward with uncertainty (“We’re not going to know everything, every time.” — Quincy Jordan) When you have an organization that is on the path of an agile transformation, they can adapt a lot better to unforeseen things Don’t reward what you don’t want to encourage (i.e. rewarding someone pulling off heroics in a pinch — a single star player won’t outdo even a mediocre team that plays well as a team) A shift in mindset around budgeting, performance reviewers, ‘human resources,’ etc. It’s important for leadership to regard their teams as their fellow teammates in the organization Mentioned in this Episode: Quincy Jordan Jeremy Bearimy Timeline 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!
34 minutes | 2 months ago
Self-Managing vs. Self-Organizing with Michael Guiler
In the new Scrum guide update, one of the key but subtle changes has been on the phrasing that teams must be “self-organizing” to now saying that they must be “self-managing.” So what might leaders do to help teams move forward in a direction of becoming more self-managing? Joining Dan to discuss this topic and share his insights is return guest and AgileThought colleague, Michael Guiler. Mike is an agile consultant at AgileThought. He has been an agile coach for over 13 years and has experience helping geographically dispersed organizations (in both the business and technology fields) to transform and better achieve their goals. Having done a fair amount with leaders himself, Mike has a ton of great insights on what leaders need to do to move their organization and teams in the direction of self-management, how to shift from a leader-follower to a leader-leader, why an organization would want to become self-managing in the first place, and the techniques and tactics leaders can use to enable self-managing teams. Don’t miss out! Key Takeaways What does self-managing mean? Why would you want a self-managing team as an organization and a leader? Ultimately, you’re trying to build an environment where the organization and the people are really your focus If you can make your people happy, your organizations will take off and you will no longer have to be the “puppet master” that is pulling all of the strings Value the people and the interactions over the processes and tools “When we can get an organization to focus on the people and realize that they’re not resources … they really unleash the power of the organization.” — Michael Guiler A self-managing team can make really good decisions and have a great impact on its customers How to begin to move towards self-management and transition from a leader-follower to a leader-leader: Through an intention-based leadership model Nurture an environment that creates safety for your team Have open conversations with your team on self-management You should have a good idea of where the organization is going as a leader in order to get to a place where it can self-manage It is important to be completely transparent and make sure that everyone is on the same page about the organization’s vision and “why” The vision should be matched with feedback from the bottom (and left to right, etc.) so that it’s not a power dynamic Enable the team’s communication and ability to deliver based on the vision Get clear about how decision-making happens based on the type of decision Make sure that the proper authority for making decisions aligns with the vision and is clear Techniques and tactics leaders can use to enable self-managing teams: Story mapping is an incredibly valuable tool for software development teams to get everyone on the same page and aligned with where the organization is trying to go Sometimes a team member doesn’t have the competency or skills to become self-managing, it is your duty as a leader to fill those gaps, give them the information they need, and help them grow Give your team water-wings before you throw them in the pool! (i.e. Give your team safety so that when a mistake is made it gets caught and is not catastrophic) Challenges for leaders new to the servant leadership mindset: It takes time to change a “command and control” environment (i.e. the leader is used to “pulling the strings” and the team is used to having to wait for the strings to be pulled before they take action) If your team doesn’t understand the big picture they can’t self-manage effectively A lack of vision and understanding at all of the levels prevents self-management of the organization If you punish/reprimand team members for making the wrong decisions, they will eventually stop making decisions on their own (halting theirs and the team’s ability to become self-managing) Resources for leaders on unleashing your organization’s self-managing potential: Leaders Eat Last: Why Some Teams Pull Together and Others Don't, by Simon Sinek Turn the Ship Around!: A True Story of Turning Followers into Leaders, by David L. Marquet User Story Mapping: Discover the Whole Story, Build the Right Product, by Jeff Patton Mentioned in this Episode: Michael Guiler Agile Coaches’ Corner Ep. 87: “Intent-Based Leadership with Michael Guiler” Agile Coaches’ Corner — Trainer Talk Ep: “Why Has Self-Organizing Changed to Self-Managing in the New Scrum Guide?” Leaders Eat Last: Why Some Teams Pull Together and Others Don't, by Simon Sinek Turn the Ship Around!: A True Story of Turning Followers into Leaders, by David L. Marquet Esther Derby User Story Mapping: Discover the Whole Story, Build the Right Product, by Jeff Patton Thinking in Systems: A Primer, by Donella H. Meadows 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!
34 minutes | 3 months ago
Build Better Teams with Sam Falco
Today, Dan Neumann and Sam Falco are exploring the topic of teams — and not just Scrum teams, but all teams. As a leader, it can be difficult to manage many lines of communication — especially in larger teams. In Dan and Sam’s conversation, they discuss The Tuckman Model as a thinking framework on how to nurture high-performing teams. From forming to storming to norming and performing, The Tuckman Model lays out the manner in which a leader should engage with teams to become more effective than ever before. Tune in for today’s episode to find out which strategies you can put into play right now to build, lead, and maintain better teams! “A team has shared success or failure. One person can’t succeed [while] another person fails if you’re an actual team. You win or you lose together.” — Sam Falco Key Takeaways What is a team? A handful of people who are all working toward a common goal/objective and are collaborating/working together A team has shared success and failure; You win or you lose together Challenges with larger teams: They tend to get siloed; i.e., a bunch of people is working individually or smaller teams are formed within the larger team and communication is lost With a large group, even with the best intentions, someone gets left out (i.e. someone forgets to tell someone something or is unaware that someone hasn’t heard certain information yet) Increments can be missed if you’re not collaborating and communicating as a team How to (and how not to) form a team: The best teams self-select (people with a stake in the project are much more motivated) If you select random people and put them together in a team they may not function that well together In “The Tuckman Model,” Bruce Tuckman suggests that you need four stages (form, storm, norm, and perform) to tackle tough problems and deliver results as a team Leadership strategies for forming teams (Tuckman’s “forming” phase): It’s important to create a shared vision once a team is formed and then actively move towards fostering connections through being vulnerable and demonstrating vulnerability through group formation activities As a leader, it is your duty to pick the team with purpose; not availability If you’re stuck in the “form” stage, it damages the ability of team members to form the connections that are necessary for teamwork Make sure that the team develops a shared mental image of what their team is like (you could start with something as simple as picking a team name) Leadership strategies for addressing conflict within teams (Tuckman’s “storming” phase): Conflict is not inherently negative but many people have never experienced healthy conflict so it is important to look for ways to build trust As a leader, you have to transition to a “coaching” role when your teams are in a storming phase by helping them develop mutual trust, navigate organizational impediments and conflict, and discussing team working agreements that you can refer to Storming often happens when it is not clear how the team makes decisions (so it is important to find clarity on this early on) Try out the “7 Levels in Delegation Poker Group” activity, linked below Leadership strategies during a team’s “norming” phase: In this phase, teams identify common goals and work toward these common goals with standards and commitment The leader’s role shifts more to empowering their team and getting feedback In this phase, a leader should allow for leadership to emerge within the team (and not being the leader all the time) It’s important to find the balance in contributing and knowing when to allow the team to get somewhere on their own In this stage, it is crucial to maintain the trust that you built during the “forming” and “storming” phases Leadership strategies during a team’s “performing” phase: Once there’s trust and the team can engage in healthy conflict, it is important to focus on goals and new areas that will benefit the team and business Once team members can hold each other accountable in a healthy way then you can established shared goals, make a commitment to these shared goals, and achieve these shared goals as a team After accountability is established, improvement can be built upon that Characteristics of a good leader: They help a team make their decisions They help a team develop mutual trust They identify what behaviors of The Tuckman Model the team is exhibiting and then appropriately engage with the team members They consciously build their team and find techniques that work best with them Mentioned in this Episode: Lines of Communication (Image) Esther DerbyBruce Tuckman — The Tuckman Model 7 Levels in Delegation Poker Group Activity The Five Dysfunctions of a Team: A Leadership Fable, by Patrick Lencioni Agile Coaches’ Corner Ep. 117: “Don’t Get Your Agile Shorts in a Knot” Humanocracy: Creating Organizations as Amazing as the People Inside Them, by Gary Hamel and Michele Zanini Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!
34 minutes | 3 months ago
Entering a New Organization as a Scrum Master with Sam Falco & MC Moore
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!
33 minutes | 3 months ago
Big Room Planning 101 with Andrea Floyd
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!
32 minutes | 3 months ago
Don’t Get Your Agile Shorts in a Knot
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!
11 minutes | 3 months ago
Why Has Self-Organizing Changed to Self-Managing in the New Scrum Guide?
In this episode, part three of a three part series on the new Scrum Guide, Professional Scrum Trainer Sam Falco answers the question: "Why has self-organizing changed to self-managing in the new Scrum Guide”? From Self-Organizing to Self-Managing In this final episode about the major changes in the new Scrum Guide, I’m going to talk about what may be the most significant change in the Scrum Guide update. And that is the change from saying that teams must be “self-organizing” to saying that they must be “self-managing.” At first, I didn’t think much of it. I thought it was sort of a search-and-replace type of thing. To me self-organizing and self-managing seemed like the same thing. I’d often thought that self-organizing was chosen to keep managers from freaking out: “What do you mean the team is self-managing? Then what am I going to do”? That might be a cynical take on my part. But even if the change is merely semantic, the significance is that organizations will look at Scrum in a new light. That phrase, “self-managing” is going to be a big shock to organizations that haven’t allowed teams to be self-organizing or self-managing at all. A lot of organizations sort of gloss over this concept. Teams aren’t really selecting what they’ll work on except in the very shallowest sense of selecting the items that are at the top of the Product Backlog. Product Owners aren’t really Product Owners except in the shallowest sense of they’re allowed to decide what gets worked on first, but they’re still just taking orders from stakeholders. Teams don’t contribute to their goals; goals are handed to them. Teams are allowed to decide how to do what they’re told to do. Maybe we let them decide who sits where, what their core hours are, and that sort of thing. But there’s a lot more to self-managing than just allowing people to decide where they’ll sit and what they’re going to work on, specifically today. When Teams Aren’t Allowed to Self-Manage What happens when we’re using Scrum but we’re not allowing teams to be self-managing? One frequent complaint about Scrum is that, “There are too many meetings”. I talked about this in a Trainer Talk episode last year. This complaint is common when an organization imposes Scrum from the top down. Here, you’re going to do this. They don’t change anything about the way they work. So, all those other meetings that are on your calendar don’t go away, and here’s four more you need to do. Often, organizations that dictate Scrum as a veneer atop their existing processes don’t see any better delivery than they were before. Sometimes things get worse. Because now they have the added overhead of the events of Scrum and all the things that go with that. And this leads to a lack of engagement, lack of ownership, it destroys morale, it causes turnover. You not only can’t retain talent, but you can’t attract talent. Because word gets out and people hear that yeah, you don’t want to work there because that’s a horrible place to work. Self-managing teams create a healthier workplace that people want to join and stay in. Scrum and Autonomy In his book, Drive, Daniel Pink examined what really motivates people in complex knowledge work domains, which includes product development. What he found was that what motivated people wasn’t being rewarded with money. The three factors that motivate knowledge workers are autonomy, mastery, and purpose. Autonomy is the ability to decide what I am going to work on and how I am going to work on it. Mastery is the ability to continually improve your skills. And purpose means doing something that’s meaningful. Self-managing teams leverage all three of those things. And Scrum done well has all three built-in. A Scrum Team decides what it’s going to work on. A Product Goal is more than just a statement handed out. The Product Owner who creates it also collaborates with the Scrum Team on it and on what the Scrum Team needs to do to get there. The entire team gets involved in that emergent product backlog management. That’s autonomy. Another way that Scrum gives teams autonomy is that they set their own Sprint Goal. No one says, “This is what you’re going to be doing this Sprint.” Instead, the Scrum Team talks about what would be valuable to do based on the feedback they’ve gotten so far and creates its own goal and plan. And then of course, every day in the daily Scrum, the Developers meet and figure out how they are going to move a little closer to the Sprint Goal that day. They’re responsible for coming up with that plan, nobody else. Scrum and Mastery Scrum encourages mastery. The Scrum team is accountable as a whole for delivery, so there’s no idea that, “This is my area and I don’t have to do anything else”. We all expand our knowledge together and work together. And then of course, purpose is built into Scrum. We have that important Product Goal that tells us what we’re building and why. And it should be exciting for us. A benefit of self-managing teams is that there’s less overhead for managers. They don’t have to spend time directing people and telling them what to do. The manager who introduced Scrum to our team and asked me to be the Scrum Master was so relieved that he didn’t have to chase us down for status reports, that he didn’t have to be telling people what to do. He could just say, “Here’s what we need to accomplish.” And we figured it out on our own. His management activities became about helping us grow in our careers. He would ask, “What do you need to know? What do you need to learn? How can I help with that?” Both for technical skills and for navigating our organization. That was a much more fulfilling experience for him and for us. Another benefit of self-managing is serendipity in development. Hand people a problem to solve and then get out of their way. They will solve it in ways that you never imagined. Maybe solve it better than you would have if you had told them what to do. Using Scrum to manage a project instead of driving product development misses out on creating valuable products and valuable outcomes — especially in the face of uncertainty. We can pretend that we can predict the future, but we can’t. And in complex product development, something new is always going to come up. There’s an enormous amount of uncertainty. Scrum allows us to adapt to that uncertainty as it arises. Every Sprint we have a chance to change direction. Getting to Self-Managing Teams So how do you get there? First, I would say abandon the illusion of control. I had a manager once who really struggled with that. He had a deliverable that he had been told must be completed by a certain date. He’d been told the scope, an immovable target date, a fixed budget. And he was obsessed with making sure that everyone knew what he wanted them to do. And I said, let’s try to leverage Scrum for this, and he said, “As long as everyone does what I say, we’ll succeed.” As a result, people didn’t take initiative when they needed to, for fear of getting slapped down. The project ran late, and there was hell to pay as a result. This is a bad pattern. We need to let go of the idea that we can control everything, that we can predict everything up front. Feed your teams with objectives, not tasks. Set the boundaries within which they can make their own decisions and steer their own course. Empower your Product Owners to make decisions and shepherd their products. Certainly, they’ll need to take into consideration what stakeholders need and want, but allow Product Owners the latitude to make decision about what is most valuable to do and give them the resources they need to make those decisions. Things like access to market data, access to customers, etc. Encourage the Scrum team as a whole to be accountable toward each other and toward achieving positive outcomes. Encourage teams to do small experiments until the goal is achieved or the goal becomes obsolete. And then create a new goal or a new objective. We can manage risk with small Sprints where we constantly inspect and adapt not only the product and our progress toward the product goal but also the team’s effectiveness, the processes they work with, and the objectives they’re being asked to work on. As one of the principles behind the agile manifesto states, “Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. And they will. That’s the promise Scrum offers. I hope you benefited from this exploration of the changes in the new Scrum Guide. I’d love to hear your feedback. If you have a question or a comment, please email us at email@example.com. Want to Learn More or Get in Touch? Register for our upcoming web meetings See available training courses
41 minutes | 3 months ago
Modern Management Made Easy with Johanna Rothman
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!
10 minutes | 4 months ago
How Has the Sprint Goal Changed with the New Scrum Guide?
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 firstname.lastname@example.org. Want to Learn More or Get in Touch? Register for our upcoming web meetings See available training courses
33 minutes | 4 months ago
Scrum Mastership: Patterns and Practices vs. Principles
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!
13 minutes | 4 months ago
How Has the Product Goal Changed with the New Scrum Guide?
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@example.com. Want to Learn More or Get in Touch? Register for our upcoming web meetings See available training courses
34 minutes | 4 months ago
Agility: Difficulties vs. Opportunities in Organizational Decision-Making
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!
Terms of Service
Do Not Sell My Personal Information
© Stitcher 2021