Agile Coaches' Corner

This week’s Trainer Talk is with Olatunde, SAFe Program Consultant (SPC). A student asked about the importance of psychological safety in a scaled agile environment. If you are interested in attending a training class, please view a list of our public SAFe training classes. Key Takeaways So, someone asked me recently, “why do you believe in psychological safety? Why is it important when you're working in an enterprise and have teams of teams?” My answer is a simple one. Anytime you cannot bring yourself to work and be part of the team, you don't belong in that organization. Anytime your words are not valued, or your feedback is devalued, you have outgrown the organization. The organization might be operating in its winter season while you are operating in your summer season. Or, you might be in the winter season, and the organization is operating in the summer season. Did you get my gist? Psychological safety means the ability for me to bring myself to work and add value to the organization as the organization adds value to my life. Without psychological safety, there's no trust. Without sociological safety, there's no passion. When you lose passion for what you do, when you lose passion for where you are, it means the organization does not have safety dealing with you. And, you as well don't have the safety to deal with the organization. However, when you have psychological safety, the passion it brings with it brings innovation. Innovation brings new ideas. Where there are new ideas, it brings growth. Where there is growth, you bring multiple clients. Psychological safety is important when you're working in an enterprise. When you come to any of my SAFe training, I always take half a day, maybe three hours, to talk about the importance of psychological safety, respect for people, and respect for cultures. Related to this Episode: A complete list of the current Agile Training by AgileThought.  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 colleague Mike Guiler In this episode, they answer a listener's question about how they might approach joining a new company. Times of change are exciting and create new possibilities. The next question is: "how might I approach it?" Mentioned in this Episode: Team Topologies: Organizing Business and Technology Teams for Fast Flow  Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

In this episode, Eric Landes addresses the challenge of getting team members who are inclined to be quiet, reserved, or “introverted” to collaborate for the betterment of the team and the product. Check out our public Scrum training courses if you want to attend Scrum training. Key Takeaways: In the software development world, you may have noticed that many coders tend to be more introverted.  If your Scrum team includes many of these personality types, your Scrum events might be quiet.  The Scrum guide does not specifically have anything to say about personality types in the Developer accountability.  However, it does say - "The specific skills needed by the Developers are often broad …  Developers are always accountable for: Creating a plan for the Sprint, the Sprint Backlog; Instilling quality by adhering to a Definition of Done; Adapting their plan each day toward the Sprint Goal; and, Holding each other accountable as professionals." The fact that developers are accountable for the Sprint plan, and quality speaks to the need for good collaboration.  Also, adapting the plan means teammates must speak up when something changes.  I believe that good collaboration is needed in Scrum, so I recommend that Scrum masters help self-organizing teams ensure that all voices are heard. If you have an introverted team, here are some suggestions for helping team members' voices be heard.  Use anonymous methods.  For instance, have team members use whiteboards to place post-it notes on a board, then read through them.  Virtually this could be using a Miro board for a retrospective.  Give team members a fixed time to post their notes, then ask for feedback and explanations when needed.  This helps voices be heard, even when they refuse to speak to their own notes.  Another method is to have a one-on-one with all team members on a regular basis.  Make sure to bring up any items mentioned in the one-on-one in an anonymous way at the appropriate Scrum event.  How do you encourage team members to find their voice in collaboration? Related to this Episode: A complete list of the current Scrum Training by AgileThought. 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 colleague Andrea Floyd, who is about to start her retirement journey and today is sharing her excitement about this new stage in her life. In this episode, Andrea talks about the many ways in which her life was improved by Agile principles and the framework it provides to face different life scenarios and overcome obstacles.   Key Takeaways Different phases of life involve different goals. We wait for different stages in life with different plans. We collect different tools that we expect will be useful in the new phase. Don’t forget to show up with curiosity! Ask questions; get inquisitive and curious. Avoid taking things for granted or making assumptions. An organization is a living entity that needs to change and adapt. Agile is a more flexible framework that allows learning, pivoting, and adapting without breaking. Some scenarios need to be repeated for consistent outcomes, keep in mind the Agile value behind each scenario. Change doesn’t have to be a reason not to move forward. Agile offers safety to explore, inviting people to experiment to go through a learning experience, knowing that it is OK not to know everything. Take a moment to inspect a situation and learn from it.   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!  

In this episode, Eric Landes addresses a question he received while training: “How many times should I refine a Product Backlog Item before it’s ready for a Sprint?” If you are interested in attending Scrum training, check out our public Scrum training courses. Key Takeaways: How many times should a team refine a PBI before it is ready for the sprint?  The scrum guide talks about refining as an activity and ongoing.  So, the answer is that a team should refine backlog items enough so that they understand the item.  It is ready when the team says it is, and the PBI can be completed within a sprint. Here are some activities a scrum team might undertake to refine their backlog item to ready.  Your team may have better ways for you. Remember the ongoing activity, but these are some ways to get started.    First, the Product Owner refines the item when first getting the PBI. Whether the PO entered the item or someone else did, some initial details can be entered.  The Product Owner talks to people to help clarify what this is solving.  Sometimes this looks like a Product Owner having a feature that is broad in scope.  She then decomposes the feature into multiple stories that she thinks solves the problem.    Second, the Product Owner runs the new PBI by the team in a refinement meeting. Giving the rest of the team some information about this new PBI, and getting feedback on their understanding of what is needed.  If the team is satisfied with the answers, they might estimate the PBI during this refinement session.  But if more clarification is needed, the Product Owner might elect to get more information. Third, if the Product Owner needs more clarification, they get it, maybe doing research, talking to customers, or whatever is needed to clarify the PBI.  After enough gathering enough information -   Fourth - The Product Owner brings refined PBI to the refinement meeting and the team asks any more questions.  Hopefully, the team is confident the PBI can be completed within a sprint, and they estimate. Now the PBI is ready for the sprint.

This week, Dan Neumann is joined by ChatGPT, a large language model developed by open AI. An AI language model, I'm designed to understand natural language and generate human-like responses to questions and prompts, trained on a vast amount of text data, and have knowledge of a wide range of topics including software development project management and Agile methodology.   ChatGPT shares his expertise and insights with Agile Coaches’ Corner listeners in this episode.   Key Takeaways ● ChatGPT shares what is most valuable for an Agile practitioner. ○ The most valuable thing for an agile practitioner is to embrace the agile mindset, which emphasizes the importance of collaboration, continuous Improvement, and flexibility. ○ Understanding Scrum and Kanban is crucial for Agile practitioners. ○ Ongoing learning is essential for Agile practitioners to stay current on techniques. ● Why can it be difficult for people to adopt an Agile mindset? ○ The agile mindset requires individuals to be open to change and embrace a culture of continuous improvement this means being willing to experiment, take risks and learn from failure. ○ Individuals are required to communicate effectively with others and be willing to share knowledge and expertise; for people who are used to working independently or in silence, this can be a challenging adjustment. ○ It requires focusing on bringing value to the customer/end-user and pivoting quickly in response to changes in requirements. ○ Adopting an Agile Mindset requires self-awareness and a willingness to be open to feedback and critique. ● The fixed mindset trap happens when individuals and organizations focus on what has worked in the past and show resistance to change. ○ To overcome this, people must be ready to look for new ways of thinking and working, willing to take risks, and learn from failure. ● Does science back up the growth mindset? ○ Some argue that the growth mindset concept oversimplifies the complex factors contributing to success. The emphasis on individual effort and motivation may overlook the role of systemic factors, such as social inequality and structural barriers. ○ Despite criticisms, many practitioners and organizations find value in the growth mindset concept as a way to promote learning collaboration and a focus on continuous improvement. ● How can leaders start to embrace the uncertainty that goes into important moments like budgeting, release cycles, and communication? ○ It is essential for leaders to recognize that uncertainty is a natural part of any complex project. ○ Rigid expectations can be counterproductive. ○ Leaders can shift the focus from fixing deliveries to outcomes. ○ A Leader can create a culture of psychological safety and experimentation where Teams can feel confident in taking risks. ● Why does ChatGPT name Scrum as a methodology? ○ Scrum is indeed a framework rather than a methodology. ● Can a Chatbot take the work of humans? ○ ChatGPT cannot fully replace a human since it doesn’t have human experience, empathy, and intuition that a human coach has. ○ Agile requires knowledge of human behavior, group dynamics, and organizational culture. ● Agile is a mindset and a way of thinking about work, it is about embracing uncertainty, continuously learning and improving, and collaborating with others to deliver value to customers.   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’s Trainer Talk is with Olatunde, SAFe Program Consultant (SPC). Tunde shares some reflections on how to merge the best of Kanban with the best of Scrum in an approach called “Scrumban.” Key Takeaways: Somebody asked me a question. The question was, “why do you need to Implement Scrumban?” First, I always ask, “what do you know about Scrumban?”  They think it's a buzzword, a nice-sounding framework. But to answer their question, I've always encouraged them: What do you like about Kanban? They said they loved the transparency. Fantastic. They said they love the implementation of the WIP limits. They love the fact that they can see throughput. Throughput is the amount of work they have completed based on past data. What don't you like about Kanban? They will say, “we don't like that you don't have immediate benefit realization.” Their releases are two months. They don't like the fact that it doesn't have defined roles. They don't like that it is the delivery team, the Kanban team, and then the product owner. Then I pivot.  What do you like about Scrum? Well, now they say they like the defined three roles. The Product Owner, the Scrum Master, and the Delivery team, the Scrum Team. They also like transparency and accountability. Well, if you like the best things that you love about Scrum added to the best thing that you love about Kanban, then merge them. Now you have Scrumban. How do you implement it? Scrum always talks about early validation of working software as our greatest priority. That's principle number one behind the Agile Manifesto. So, for early validation, instead of three months in Kanban, move it to two weeks. Instead of two weeks, move it to three weeks. Instead of three weeks, you can move it to a month.  Thirty days. That's it. And then you have backlog refinement. So, practice continuous refinement of your backlog and its priorities. Keep the WIP limit. Keep it. Do you like the Retrospective? Let's add it. You have daily stand-up, which creates daily accountability in Scrumban. You have backlog refinement and continuous refining of the product backlog. You have retrospectives, you'll always find other ways that we can get better. And once a month, always do a demo. Always do a demo to leaders. Always do a demo to stakeholders. And that is some of the biggest benefits of Scrumban. This is the way to go any time you want to merge the benefits of Scrum, plus the transparency and the continuous work-in-process of Kanban. Merge them, then you have Scrumban.   Related to this Episode: A complete list of the current SAFe Training by AgileThought.   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 long-time acquaintance and friend, Tricia Broderick, a leadership advisor and co-author of Lead Without Blame with Diana Larsen.   In this episode, Tricia talks about the book she wrote with Diana, their mission, and the most important messages that are carried in it, such as the true meaning of a Team, the relevancy of collaboration and connection, autonomy, metrics, and much more!   Key Takeaways What makes a Team resilient? Collaboration and connection are the foundations of an authentic Agile Team. Online work does not make connecting to others any easier. Do the leader’s team connections need to be cared for differently than the lateral connections between team members? Power dynamics don’t have to be formal, it could be someone who the leader greatly respects or who has an influential power. A psychologically safe environment welcomes everyone to express their true selves, even though it is impossible to assure emotional safety for everyone at all times since each Team member is unique. Are you showing up with compassion? Bounded autonomy: You cannot empower someone to do something if they don’t have the knowledge or the skills. Trust is required in both directions. Information radiators and appropriate use of metrics are the right way of seeing trends. Sometimes metrics are misused; they need to be used carefully. Metrics need to help the team collaborate towards problem-solving and not as weapons. A Team doesn’t become one only because it is named that way. A group is not a Team, cooperation isn’t the same as collaboration. You are a better leader because you are not perfect, own your mistakes and growth, since they have brought you to the point where you are today. The only way it is impossible is if you stop trying.   Mentioned in this Episode: Lead without Blame: Building Resilient Learning Teams, by Diana Larsen and Tricia Broderick   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!  

In this episode, Eric Landes addresses a question he received while training: “Should we have more than one ‘Definition of Done?’” If you are interested in attending Scrum training, check out our public Scrum training courses.  Key Takeaways: This week, let's talk about the Definition of Done. In one of our classes, we had a question about the Definition of Done. Specifically, how many Definitions of Done can a Scrum Team have? So, I went to the Scrum Guide, and here is what that says: "The moment a Product Backlog item meets the Definition of Done, an Increment is born." The guide does not say it meets the sprints Definition of Done or the potentially shippable definition of done. Instead, it states, "the Definition of Done," implying, in my mind, that there is one Definition of Done. In class, we discussed whether there should be a definition of done for releases, for instance. When some organizations release the software, users need to be trained. Marketing materials might need updating, etc. And I understand that these things need to happen. Having one DoD would reduce friction for releasing. No waiting for another team to complete work. The Scrum team controls when they can release. High-maturity teams and organizations are designed this way. But not all organizations are in a place where we can have the Scrum team do everything necessary for release. So the team may have to grow into it. That is ok. Remember where you are headed and make improvements every sprint to put everything necessary for done into your definition. Related to this Episode: A complete list of the current Scrum Training by AgileThought. 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 Ola Tunde, AgileThought’s practice Lead for Agile Transformation and Coaching in Mexico and Costa Rica.   In this episode, Tunde shares his insights about the power of SAFe training. He describes various available courses and the outcomes attendees get SAFe Training.   Key Takeaways ● SAFe Training: What is it like? ○ When you assist with SAFe training, there should be three outcomes: 1. Knowledge of real-life applications, 2. You will hear success and failure stories, and 3. Enthusiasm. ● People who attend training often assume that their trainer is the best in the world and knows everything. ○ When people come together, they all learn from each other; the trainer learns from the class, and the participants learn from each other. ● What can a Product Owner expect from a SAFe class? ○ The Product Owner changes its value according to which one has it. ○ If a Product Owner attends a POPM class, they will leave the class knowing how to understand the market. The Product Owner will know the market's strengths, the competitors' strengths, threats, opportunities, and weaknesses (SWOT). ○ We empower Product Owners to understand the market. ○ It is a psychologically safe environment where Product Owners can learn. ● SAFe Advanced Scrum Master Class: ○ This class trains and empowers Scrum Masters to be a master in the market and with their clients, implement change within an enterprise, and collaborate with others at program and team levels. ● Tools a SAFe Scrum Master would learn differently from the tools acquired at a Team Level. ○ SAFe Scrum Master can influence change in an organization. ○ RTE cannot be with the Teams at all times, coaching Product Owners and stakeholders to devise a plan of intent that is reasonable, delivers incremental value, does not constitute a risk, handles the technical data, and dictates what will not be done. ○ PR planning needs the Scrum Master’s help (especially in large organizations). ● Leading SAFe: ○ When attendees leave the class, they should be able to influence their Teams to do backlog refinement by understanding the definition and estimates of the backlog. ○ All SAFe classes include PI planning scenarios with them; they go from training to workshop. ● Virtual classes: ○ Everyone with internet service and a computer should be able to receive the class. ○ Interaction between colleagues during classes is an excellent source of learning. ○ Come hungry and open-hearted to the classes. A closed mouth is not fed.   Mentioned in this Episode: Agile Thought Training and Certifications The Leader Who Had No Title: A Modern Fable on Real Success in Business and in Life, by Robin Sharma   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!