Agile Coaches' Corner

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!

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!

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!

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!

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!

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!

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!

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!

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!

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!