Agile Coaches' Corner

This week, your host, Dan Neumann, discusses his perspective on the influence of Artificial Intelligence on Agile Teams. AI has created excitement and great expectations, undoubtedly changing how we perceive work and raising some concerns. In this episode, Dan dives deep into how Generative AI can impact Agile Teams' work, describing AI's use in this field and using valuable examples to describe several manners to incorporate AI to ease the work at different stages of an Agile process.   Key Takeaways Generative AI, a new thinking partner to Agile Teams: There are sensitivities around using the free AI models currently available. AI could be considered a great partner in addition to Team Members. The definition of done for each project cannot be delegated to AI, since the Team needs to determine the pros and cons, define the goals, and what it means to achieve them. Miro AI can be used as a Retrospective partner to examine the retrospective data the Team has been collecting. It can also help provide different ways of facilitating Retrospectives. AI is helpful to Delivery Teams in predicting releases. Agile Teams can use the Monte Carlo Simulation to predict a Team's velocity by looking at historical data to create a range of future possibilities. Sprint planning could be simpler with the aid of AI. An Agile Team can seek AI help to provide other work items that might support the original Sprint Goal, based on the product backlog. How can AI assist in dealing with bottlenecks? AI can help identify some bottleneck trends based on the existing delivery data. AI as a tool for Product Owners and Quality Specialists to identify Acceptance Criteria: AI can assist Product Owners and Quality Specialists in defying product backlog Item acceptance criteria. To generate new acceptance criteria, test cases can be generated using an AI public tool or a technology ecosystem like Microsoft Copilot. Using Microsoft Copilot, a Team can look at the sentiment in which you are engaging with your Teammates. By searching the Team's chat emails, AI can help you anticipate potential issues. Ai can provide strategies to tackle a potential social challenge that might be reflected in the Team's communication. AI can use your historical information for risk management. AI can help a Team identify risks and develop strategies to solve them or even when to accept those risks since the cost of mitigating them exceeds the Team's capabilities. Agile Teams can use AI for prioritization. AI can explore big data, search for information on costs and benefits, and provide useful suggestions for prioritization.   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, your host, Dan Neumann, is discussing how to maximize Team autonomy while maintaining accountability within Agile Frameworks. In this episode, Dan defines the importance of autonomy and accountability in Agile. He explains the challenge faced when too much autonomy leads to a lack of accountability while, on the contrary, too much control inhibits innovation and why leaders should prioritize this delicate balance.   Key Takeaways What is Autonomy in Agile? Autonomy is the ability to self-manage, make decisions, and drive solutions. Give Teams the environment and support they need, and trust them to get the job done. Motivated individuals are the key to success! A Manager must welcome changing requirements but needs the Team to maintain focus. Remember, a Team must harness change for the customer's competitive advantage. Autonomy benefits Agile teams by making decisions faster and fostering creativity and innovation. The Role of Accountability in Agile: Accountability in the Agile context means taking ownership of work, meeting commitments, and ensuring transparency. An Agile Coach should account for progress toward the desired outcome. When things go wrong, slow, or burst, the coach should explain why it happened, what measures were in place to help prevent it, and what the team can do to prevent the problem from happening again. Accountability keeps Teams aligned with business outcomes and stakeholders' expectations. Key Strategies for Balancing Autonomy and Accountability: Clearly Defined Outcomes: Focus on the importance of clear goals, shared objectives, and transparency. Teams need freedom to achieve these goals but must stay accountable for delivering them. Tell it, write it, repeat it, and ask others to repeat it. Create a Culture of Trust: Trust between leaders and Teams drives autonomy. Trust the Team to make decisions, and they will take accountability for their outcomes. Use Agile Metrics Thoughtfully: Discuss key metrics like velocity, burn-down charts, and lead time. Always remember that metrics are tools for learning, not for punishment. Emphasize simplicity as the art of maximizing the amount of work not done. Boundary Setting (Guardrails): How Agile coaches and Scrum Masters can establish non-intrusive guardrails (e.g., WIP limits, capacity planning) to ensure teams are free to work without getting lost or overcommitting. Leadership's Role in Supporting Autonomy and Accountability: Some Leadership behaviors that empower teams are removing obstacles, giving space for innovation, innovation week, buffer in a Sprint, spikes, training resources, conferences, and coding retreats (among others). Agile coaches must highlight the need for regular feedback loops, such as retrospectives, to align accountability without micromanaging.   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, your host, dives deep into how Managers can support and help their Agile Teams. We often fall into common misconceptions, such as believing that self-managing Teams do not need Functional Managers or finding that the Manager's role is not well defined, making it difficult to identify how he can assist an Agile Team. In this episode, Dan shares many valuable tips for Managers trying to find the best ways to help an Agile Team.   Key Takeaways Tip No.1: Encourage Team Involvement. Involve the team in the solution process and respect their expertise and opinions. Involving team members in decision-making processes can lead to better  alignment, trust, and quality of solutions. Tip No.2: Support Learning and Development. Provide time and resources for training and other activities to support the Team's learning and development needs. Give Team members time for training and attending relevant events to increase motivation and performance. Tip No.3: Foster a Flexible and Adaptive Mindset. Encourage managers to adopt a flexible and adaptive mindset and be open to change and feedback. Being adaptable and responsive to changes in the Agile environment has remarkable benefits. Tip No.4: Measure and Improve Workflow. Identify wasteful activities like handoffs and delays and streamline the flow of value to customers. Measuring the total time to deliver customer value and designing an effective workflow can improve Team efficiency. Tip No.5: Align Teams with Common Visions and Goals. Form networks of teams centered on common customers and products and push decision-making out to the network's edges. A Manager should align teams with a shared vision and goals rather than top-down control. Tip No.6: Celebrate Successes and Learn from Challenges. Celebrate the team's successes and identify root causes for defects or challenges to improve continuously. Celebrating achievements and learning from challenges fosters a positive Team culture.   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 welcomes Mike Guiler to explore starting on the right foot and staying aligned during the delivery process. In this episode, Dan discusses the crucial activities that set the stage for a successful project inception. Whether starting a new project or re-initiating an existing one, these activities are essential for aligning your Team, stakeholders, and vision.   Key Takeaways Understanding Project Inception: Project inception is the initial phase of a project where we lay the groundwork for everything that follows. It's about understanding the project's goals, scope, and constraints. This phase is critical because it helps ensure that everyone involved clearly understands what the project aims to achieve and how we plan to get there.   Key Activities in Project Inception: Vision and Goals Workshop: Gather key stakeholders to define the project's vision and goals. Discuss the desired outcomes and how they align with the organization's strategic objectives. Create a shared understanding of the project's purpose and success criteria. Stakeholder Identification and Analysis: Identify all stakeholders on whom the project will impact. Analyze their interests, expectations, and potential influence on the project. Develop a stakeholder engagement plan to ensure effective communication and collaboration. Scope Definition: Clearly define the project's scope, including what is in and out of scope. Use techniques like user stories, use cases, and process flows to capture requirements. Prioritize requirements based on business value and feasibility. Risk Assessment: Identify potential risks that could impact the project's success. Assess the likelihood and impact of each risk. Develop mitigation strategies to address high-priority risks. Team Formation and Roles: Assemble the project Team and define roles and responsibilities. Ensure that Team members have the necessary skills and expertise. Foster a collaborative and supportive Team environment. Initial Planning and Roadmap: Develop a high-level project plan and roadmap. Identify key milestones and deliverables. Establish a timeline for the project's major phases and activities. Best Practices and Tips: Engage Stakeholders Early and Often: Regularly communicate with stakeholders to keep them informed and engaged. Use feedback loops to ensure that their needs and concerns are addressed. Be Flexible and Adaptable: Be prepared to adjust the project plan as new information emerges. Embrace change and use it as an opportunity to improve the project. Focus on Value Delivery: Prioritize activities and deliverables that provide the most value to the organization. Continuously evaluate and adjust the project's direction to maximize value.   Mentioned in this Episode:   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 welcomes Nina Sossamon-Poghe to today's conversation. Nina has an interesting background as a U.S. gymnast, a News Anchor, and a Corporate Leader with a unique perspective on resilience, mental health, and well-being.   In this episode, Dan and Nina discuss an innovative concept, Excellence Exhaustion, while they define and analyze its significance. Nina also shares the “Resilience Route Navigator,” a framework designed to help high achievers combat Excellence Exhaustion.   Key Takeaways What is Excellence Exhaustion? Excellent Exhaustion is different from burnout. Nina likes to define burnout as the mental exhaustion resulting from doing the same thing repeatedly. Excellence exhaustion is the stress and anxiety experienced by high achievers who are driven to surpass their previous achievements. Constantly advancing technology and perpetual connectivity are drivers of Excellence Exhaustion. The Symptoms of Excellence Exhaustion are anxiety, mental fatigue, reduced motivation, and diminished productivity. The Resilience Route Navigator: The Resilience Route Navigator is a framework that helps high achievers combat Excellence Exhaustion through TIPS: Timeline, Isolate the Problem, People, and Story. Timeline thinking: This step is needed to acquire perspective. Whatever is happening to you, put it in the timeline of your life; check on the life that came before this moment and all the blank space ahead for the years yet to come. This exercise is also a great way to gain appreciation for all you have done in your journey so far. Isolate the Problem: Focus on your current situation and leave the past and the future out. At this stage, the present is the main event; this is the only area in which you can take action. People: Who is in this struggle with you? You are not alone. Seek the assistance of others who can assist you in navigating the current situation. Story: It is crucial that you choose the words you use to tell the story of what is going on in your life. Narrate the events in the most empowering and optimistic manner.   Mentioned in this Episode:   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, your host, Dan Neumann, welcomes Mike Guiler to discuss a recent course on Kanban Essentials they experienced together. By the end of the classes, they encountered a common feeling in some participants: fear of failing. Often, acquiring new knowledge, embarking on a new journey, or using a new tool can trigger insecurities: What could happen if it is not right? Where do I begin?   In this episode, they encourage Agilists to face this first stage of hesitation, analyze the limitations, and consider the best scenarios for using a new tool or enforcing an innovative strategy through implementing Kanban.   Key Takeaways Kanban Essentials: Agilists might hesitate to incorporate Kanban into their projects for the first time. It is common to feel insecure and doubt whether it is implemented correctly and how effective it would be. The whole Team has to take ownership of trying Kanban to solve an existing problem. How to start using Kanban? Start Kanban with matters you can control. Make sure you identify the expected result from implementing Kanban and have a way to measure its effectiveness. First, start using Kanban to solve a small problem. After solving it successfully, the Team will earn much more credibility and encouragement to use it to solve a more complicated issue. You can start using your personal Kanban board and convince the entire Team to use it for the whole system. The Problem of Local Optimization: Sometimes, a Team optimizes its work, but this does not translate to the entire organization, resulting in one Team working more effectively when the rest isn't on the same page. There is a need to start small and locally but have the bigger system in mind. Make your work visible. It is crucial to agree on the definition of used terminology (for example, what does a Team define as “done”?). A Team must stop and think about how they are doing what they are doing, and ways to improve it.   Mentioned in this Episode: Kanban Essentials   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, your host, Dan Neumann, is joined by Norm Kerth, author of Project Retrospectives: A Handbook for Team Reviews. Norm Kerth wrote this book before Sprint Retrospectives were invented! In this episode, Norm and Dan explore the subject of Project Retrospectives. They discuss the learning opportunity within every major project event, especially in instances where things did not turn out favorably. Norm explains when and when not to have a Retrospective and how to prove its value to organizations reluctant to grant the necessary time to invest in them.   Key Takeaways An unconventional career: Norm realized that the best way to move up inside a corporation was not to be in line or follow other people's paths but to find the void that other people were leaving in the company and fill it. This is an amazing way to contribute. Norm wrote the book Project Retrospectives even before retrospectives and sprints were created. Project Retrospective: Learning from past experiences is quite valuable, which is why Retrospectives are so beneficial for a Team. The first step is to assume that every member of the Team is doing the best they can according to their capacities and knowledge. If this is not the foundation, people will fear being blamed for mistakes or errors instead of focusing on the learning opportunity. Once the Team has learned from past experiences, they can decide how they will operate differently in future circumstances. Retelling the story is very crucial. The necessary four questions: What went well? What did I learn? What do I want to do differently the next time? What still puzzles me? Retrospectives need time, but organizations do not always agree. When you reach the end of a project and are late starting the new one, don't rush! Remember that if there is no reflection on the last project, the following will repeat its mistakes. The best way to improve organizational processes is to involve the people doing the work. Consultants must ask four questions: How did you get to where you are? How do you feel about where you are at the moment? Where do you want to go? What do you want to do differently? The Retrospective is the way to find the answers to these questions. When is a Retrospective not needed? There is no point in having a retrospective in dysfunctional organizations. It doesn't matter how a Team changes its ways if the organization has major conflicts that are not addressed. The manager needs to be involved in Retrospectives; if there is no collaboration from leadership, why waste the time? Don't do the Retrospective only because it is trendy to do it. How can Retrospective's value be demonstrated? First, retell the story of the project, going through the most significant events. Search for the wisdom while answering the four questions. Break the Team into naturally affinity groups (they will probably group together according to the area of work). These subgroups are encouraged to propose what they want to do differently. These suggestions have to be achievable and measurable so their value can be tested in the following Retrospective.   Mentioned in this Episode: Project Retrospectives: A Handbook for Team Reviews, by Norm Kerth   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, your host, Dan Neumann, is joined by an external guest: Kristen Belcher, a Software Developer turned Agile Coach. In this episode, they discuss liberating structures, simple and subtle tools that can help everyone attending a group event contribute and be included. They dive deep into some of the Liberating Structures, such as 1-2-4-All, Drawing Together, Purpose-to-Practice, and TRIZ. Listen to this thoughtful conversation and get ready to apply some of these practices to the next event you facilitate.   Key Takeaways Many structures we use with groups, like presentations, status reports, and even tight discussions, tend to fail because they don't have space for all the participants' voices or allow members to think “outside the box.” Sometimes, there is even no structure at all. Liberating structures are the tools that liberate everyone in the conversation to contribute and be included. We all have different participation styles: thinkers, talkers, and quiet ones. We all communicate in unique manners, and our input is equally valuable. There are 33 liberating structures. One Liberating Structure is 1-2-4-All. You can apply it starting with 1: People have time to think on their own. Then 2: They pair up and discuss with another person. Then 4: The pairs will pair, generating themes and sharing what they learn. Finally, All: Where everybody can share their ideas. Even though everyone won't be allowed to speak to the large group, they had the chance to contribute in the previous instances. Another Liberating Structure is called Drawing Together. Everyone needs to draw a picture using the same shapes (no artistic ability is required). Every shape has a significance: Circles stand for wholeness, rectangles represent support, triangles represent goals, spirals represent changes, and the stick or star persons represent relationships. The group interprets a picture, and these views are the kickstart for a discussion. Purpose-to-Practice is a tool for identifying our main purpose and rooting the members together. It helps realize who must be included to achieve a shared purpose. TRIZ is the liberating structure created to assess the absolute worst scenario that can happen. When choosing a liberating structure, you must match it with the problem you are trying to solve in a group. First, you need to frame the problem to find the right tool to approach it. It's a good idea to have a Plan A and a Plan B for facilitation. How can you start applying Liberating Structures? When approaching liberating structures, you will first learn what they are for, then how to approach the space, how people participate, groups, and the sequence of steps to be followed. The material also provides time allocations. You will receive minimum specifications of how the liberating structures are set up. There is no specific script about how you should facilitate. Be comfortable doing something uncomfortable and new.   Mentioned in this Episode: LiberatingStructures.com Download the Liberating Structures App The Art of Gathering, by Priya Parker The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth, by Amy C. Edmondson Right Kind of Wrong: The Science of Failing Well. by Amy C. Edmondson   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, your hosts, Dan Neumann and Justin Thatil, share seven tips for Agile Facilitation. Collaboration is necessary when solving a problem, and Agile Coaches and Masters work to enable a Team to cooperate. Every event is unique, which is why Facilitation could be considered a form of art.   Key Takeaways Contextual Awareness: Teams and events are filled with unique variables that the facilitator cannot always anticipate; as a result, reading the overall atmosphere of a room and the individuals' body language is a fundamental skill for Facilitators. Every Facilitator has to remember that they are facilitating for a specific audience. Who is this meeting for? What is the value for these participants? Use Time boxes. A Facilitator must master the flow of the meeting to achieve the goal in a timely manner. A Facilitator should design the session with the intended activities, promote collaboration from collaborators, and be flexible enough to adapt to changes. Mastering the act of active listening: Listening is achieved when being fully present. Seek to understand. Facilitators must be able to paraphrase what they just listened to to ensure they understand what the collaborator is saying. Are collaborators listening to each other? A Facilitator must also promote active listening among participants. A Facilitator must foster an open and inclusive communication environment. A Facilitator must become a master observer of the room. Who is participating? Who is silent? Design a power start! Set the purpose and the intended outcome for the meeting. This will improve participant engagement. Specify how participants can engage. Visual Facilitation tools are incredibly beneficial for a better Facilitation. A Facilitator must handle conflict with grace. Conflict is inevitable, especially in a collaborative environment. Participants should be encouraged to learn from each other. Conflicting perspectives must both be validated. A Facilitator must be clear about which behaviors are acceptable. Safe boundaries are essential to hosting a psychologically safe environment. Facilitators must continuously improve their skills. Facilitators must apply learnings in a setting first to realize how they can be improved. Pairing with other Facilitators can be a great way to keep learning continuously.   Mentioned in this Episode: Empowered: Ordinary People, Extraordinary Products (Silicon Valley Product Group), by Marty Cagan and Chris Jones   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, your host, Justin Thatil, welcomes Ned Pope, Director of Product Practice at Agile Thought. In this episode, Ned and Justin explore the most common challenges encountered while engaging with an enterprise client. Ned shares valuable insights regarding creating a new product effectively and timely, emphasizing the crucial value of openness and collaboration within a Team. Ned highlights the importance of focusing on the problem, the elements of the solution, and how they can be broken down to prioritize the most unique and highest value for clients and customers.   Key Takeaways Enterprise clients are dealing with a massive sector of the marketplace. There is a wide range of variance in what the clients are trying to accomplish, so it is important to ground them in their thinking around problem-solving. If you can remove even a minor inconvenience from someone's day, you add value to their life. There must be a list of priorities from executive and senior leadership within the enterprise clients, along with the dates they will be needed. This road map is not based on capacity or capability to deliver a solution around a specific item to be delivered at a particular time. Don't get frustrated when trying to create a digital product. There is a reason this solution doesn't exist yet, or in the form you are trying to build it. Make sure everyone is aligned and on the same page. Understand and respect the current processes within an Organization. The organization has already figured out how to solve the problem in the current fashion, and you do not want to disrupt that but to provide something that makes that process more manageable, enhances that solution, and makes it more effective and scalable. There are tangible elements that form a culture. Empower teams to think creatively about a solution. Openness, resourcefulness, and collaboration are critical elements of an Agile Team. Move UX design and UI library components as visual references at the beginning of the process to save time and ultimately allow for a better product. We often get to the details and the complexity of the work and then begin to get consumed with all the nuance and intricacy of the daily work, which can lead to overseeing the most basic aspects. Remember, you are building a visual tool! The vast majority of technology has some form of interface, which generates success and speed with quality and accuracy. Provide visual references to align the Team with what you are trying to accomplish and execute. It is recommended that you bring in a highly skilled UX Designer to the heart of the Product Discovery. Don't wait until the process is in development; the UX designer needs to join the process from the beginning. Use a UI library.   Mentioned in this Episode: Scaled Agile Scrum.org National Academy of Inventors   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, your host, Justin Thatil, is joined by Mike Guiler to explore complementary practices in Scrum. The Scrum Guide intentionally left many open questions for users to adapt and practice flexibility.   In this episode, Justin and Mike outline several practices, such as identifying the product vision, adapting the Kanban Board, and providing visual information regarding the production process. They also discuss the benefits of using Kanban's lead and cycle time metrics and close this conversation by diving deep into the importance of identifying a shared definition of ready.   Key Takeaways Product Vision: Scrum is always about outcomes. How do we find the right outcome to deliver to our customers? First, we need to be clear about the product vision and what the organization considers a priority. Second, the Team comes up with a plan to achieve that vision, which unlocks an organization's power. Adapt a Kanban board. The Kanban board helps to visualize the process at a particular sprint timebox. Many benefits result from visualizing the steps in the Kanban Board. Scrum with Kanban:  Stop starting and start finishing! Look at what you are doing and implement better Teamwork. Kanban's lead time and cycle time metrics give an indication of the system's progress and whether it is getting better. The cycle time measures the time it takes an idea since it enters a print backlog until it is delivered to the customer, while the lead time gives more of a system view. Find your definition of “ready.” What has to happen to make a product backlog ready? Get to a shared understanding of what is considered ready within a Team. Reduce the ambiguity about what should and shouldn't be in the product backlog, resulting in a better sprint plan.   Mentioned in this Episode: Listen to Episodes 277 and 279 of The Agile Coaches Corner. Scrum with Kanban Sprint: How to Solve Big Problems and Set New Ideas in Just Five Days, by Jake Knapp   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 and Justin Thatil are joined by the first-time guest, Jeannine Gonyon, a Performance Engineering Practice Lead at Agile Thought. This episode explores the differences between performance testing and performance engineering, emphasizing the crucial role of Performance Engineering in mitigating unnecessary risks and protecting the Organization's reputation.   Key Takeaways Performance Testing and Performance Engineering test: Performance testing is the process that follows manual testing. After ensuring the application is working, testing for “non-functional” takes place, which is called performance testing. Performance engineering tests go to an extra step of analysis to find out exactly where any kind of optimizations are needed. Some Organizations are hesitant to invest in Performance Engineering. Some organizations consider Performance Engineering to be a “luxury.” Would you take a risk with your reputation? You will if you don't perform performance testing on your product. Knowing the facts before production is priceless! The earlier you do Performance Testing, the more you have the maneuverability to make any changes. The costs of Performance testing: Performance testing does not happen in a shared environment, which adds a cost. There are ways of reducing the costs. You can spin the environment when you need it. The cost is manageable if you do it earlier. If you do performance testing, the earliest is the best way to mitigate risk (better than spending much money later). What is the relationship between Performance Testers and the rest of the Team involved in developing a product? Performance testers are technically aligned with manual testers because they need to know when the product is ready for testing. Performance testers work closely with the development Team, must be involved with the product owners, and be present at every step of the workflow. Performance testers need to know as much about the application as those using it. Performance Testing and AI: Currently, the engineering part can benefit from using AI tools for analysis in a more casual manner. A quick growth of AI tools applied to Performance tests is expected. Testing in Production versus Performance Testing: Performance Testing prevents the risk of a bad user experience. There is a place for performance testing before the product goes to production.   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, your host, Dan Neumann, is accompanied by Gill Broza. Gil is known for simplifying the complex and making the implicit explicit so people can make better choices. He is a writer and never prescribes a single right way.   In this episode, Dan and Gil explore how to help teams grow and produce improved outcomes while diving deep into a discussion regarding Gil's latest book, Deliver Better Results.   Key Takeaways Agile introduced the concept that multiple ways exist to create, ideate, and deliver products. The variety of Agile methods can be paralyzing Gil proposes five levels of adoption to find the best “fit for purpose” The primary purpose is to help the company succeed while doing it timely and showing adaptability. Six aspects of fitness for purpose in the delivery process are throughput, outcomes, timeliness, adaptation, consistency, and cost efficiency. The value lies in how well we serve the company and the effect of the work. The people matter the most; they are the ones transiting the process. The strategies proposed by Gil work because people start to behave differently. Ways of working result from combining the tactics we use (process, practices, roles, artifacts, tools) and the mindset we employ while executing the tactics. The mindset is defined by choice-making, which has three components: purpose, beliefs, and principles. Sometimes, you need to change tactics and mindset simultaneously. It requires hard work but could be the only way to work. Decisions made in one place of the system can have ramifications everywhere else. Gil prefers to use the term “way of working” instead of “process” since it is a bigger construct and includes the choice-making component. The words we use matter; they communicate the way that we work and how we approach tasks.   Mentioned in this Episode: Deliver Better Result: How to Unlock Your Organization's Potential., by Gil Broza Chapter 1 of Deliver Better Results Thinking in Systems, by Donella Meadows The Drunkard's Walk: How Randomness Rules Our Lives by Leonard Mlodinow Random Acts of Medicine: The Hidden Forces That Sway Doctors, Impact Patients, and Shape Our Health, by Anupam Jena and Christopher Worsham Thinking in Bets: Making Smarter Decisions When You Don't Have All the Facts, by Annie Duke   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 and Justin Thatil are joined by Mike Guiler to continue the discussion on Norman Kerth's book Project Retrospectives. In this episode, they explore the last three chapters, which are filled with exercises to apply at Retrospectives, specifically when sensitive topics are to be addressed.   Key Takeaways Some Retrospective activities are designed to address emotionally charged topics. Failure must be accepted and embraced in postmortem retrospectives; otherwise, no one would be open to discussing it. As a facilitator, try to find the highest leader available in your organization that is willing to share with participants an instance in which they themselves faced failure and what he or she learned from it. This establishes that it is okay to talk about failure. Becoming a Facilitator: You have to “walk the walk”; facilitators are made by practice. Ask for help when you need it! Don't be afraid to ask for assistance when your capabilities are limited. As a facilitator, you can also contact someone outside your organization for support. A useful resource is getting feedback from a second facilitator about the Retrospective. Don't be defensive; feedback is always an opportunity to grow. Allow space for intense emotions during Retrospectives. Fostering the expression of emotions is healthy and cathartic for the organization, but sometimes, it can be challenging for the facilitator to deal with them during the event. Listen actively, assign a meaning to those feelings, and try to identify the feeling arousing about that feeling. Identify which feelings can be discussed at the Retrospective and which others should be addressed one-on-one. Tools for Facilitators: Ask for help. When something isn't working, try something different. Be humble enough to know when to pivot. Avoid triangulation. Encourage people to talk to the person, not about the person. Congruent vs. incongruent messaging: When delivering a message that describes a problem, first address how the problem is impacting you (the self), then the context, and finally, the intention and how this caused the problem. A similar approach is the Situation-Behavior-Impact framework.   What to do after Retrospectives? Collect the readout: Make a summary of what was done in the Retrospective. Collecting a library of Retrospectives can help estimate projects. Retrospectives contain a significant amount of useful data for the organization. After recapitulating the event, think about what can be improved. The information coming from Retrospectives is a great way for a better forecast.   Mentioned in this Episode: Project Retrospectives: A Handbook for Team Reviews, by Norman L. Kerth Intuitive Prediction: Bias and Corrective Procedures, Daniel Kahneman Listen to Project Retrospectives: Book Exploration (Part 1) and (Part 2)   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 and Justin Thatil are joined by Mike Guiler to continue their discussion of Norman Kerth's book Project Retrospectives. In this episode, they dive deep into chapters 6, 7, and 8, analyzing some of the exercises and techniques described in the book and the immense value of learning to plan retrospectives for them to be fruitful. They close this conversation by addressing “postmortem” retrospectives and the importance of unpacking a failed project.   Key Takeaways Chapter 6: Exercises and Techniques: There are many ways to facilitate retrospectives and this chapter describes several intentional exercises meant to shake things up. Norm addresses three essential parts of a retrospective: the readying, the past, and the future. The readying is meant to allow team members to prepare and bring forward relevant topics. Teams often want to save time in retrospectives by skipping them or shortening their length. They do that because they find them ineffective and do not see the value in investing time and energy. A Scrum Master must invest in making retrospectives into a much more impactful event for the team. About facilitating better retrospectives: Retrospectives need to take a longer time (three hours). There needs to be “emotional freedom” in the group's atmosphere to facilitate and enable members to participate; it's crucial to be aware of different personalities and how they engage with others. The topic's sensitivity during the retrospective needs to be considered. The postmortem retrospectives: When a project fails: Be conscientious about not injecting your perspective; sometimes, it can do more harm. An idea must be presented along with its benefits, strategy, and plan, including the costs and reasons why it is helpful to implement it.   Mentioned in this Episode: Project Retrospectives: A Handbook for Team Reviews, by Norman L. Kerth Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diane Larsen   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 and Justin Thatil are joined by Mike Guiler to share their continuous learning journey. They have been exploring the book Project Retrospectives written by Norman Kerth, and today, you will listen to them discussing chapters 3 to 5, where they dive deep into the role of Retrospective facilitators.  They compare Norm's guidance against their own experience and reflect how practices presented are still be relevant today as retrospectives are more widely practiced in the industry.   Key Takeaways Retrospectives: Internal or external facilitators? You can be present without necessarily having to share your opinions and thoughts.  An external facilitator for a Retrospective is not part of the Team but can be a well-informed outsider. In the Scrum framework, very often it is the Scrum Master who facilitates the Retrospectives, but it does not have to be this way. There is a conflict between a full contributor on the retrospectives and a facilitator, which is why an external facilitator can be significantly valuable. Should Managers be in a Project Retrospective? Managers must be allowed to be present at Retrospectives, but their involvement needs to be regulated. Engineering retrospectives take time and effort. Sometimes, the same feedback is received during several meetings, which is why it is important to plan retrospectives carefully considering Team Styles, the way the questions are brought forward, and any characteristics that can come up after thoughtfully observing the Team's dynamics. Identifying the most important topic for the Retrospective must be brought forward by the Team. The best achievement is when the Team expresses its needs as a result of the effective work of a facilitator (as opposed to someone dictating what the Team's interest or need is).   Mentioned in this Episode: Project Retrospectives: A Handbook for Team Reviews, by Norman L. Kerth   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, Justin Thatil, your host, welcomes Mike Guiler and Anitra Pavka. Today, they address the product discovery phase and some of the challenges the engineering Team usually faces while identifying what they will build and which special skills will be required to perform the task effectively. Also in this episode, they explore interviewing techniques and usability testing.   Key Takeaways Interviewing users is universally helpful. Interviewing users is so important that it should be done every week. We need to be informed, and the only way to do this is by talking to the users. Before the interview begins, you need to make sure you know what you want to obtain from the conversation. A discussion guide might help to lead an interview and make it more consistent. Focus on allowing people to keep on talking. Engage in the conversation with active listening skills  Open-ended questions are ideal for promoting a deep conversation. Fall in love with solving the problem and avoid fixating on a particular solution. Put an effort into understanding the underlying motivations to solve a particular problem. The organizational culture needs to promote the Discovery and Delivery Teams to talk to the customer and get feedback. Encourage small experiments that try to address a problem from a different perspective and use a different tool to solve it. If the experiment is successful, the new approach could be applied to other matters. Usability testing: Was the product easy to learn? Was the user able to get through the product efficiently? Were there errors along the way? Search to find out answers to questions about value. You can use moderated and unmoderated usability tests to get the feedback the Team seeks. Share the findings across the Team. They can influence how they approach the following prototype and evolve the solution.   Mentioned in this Episode:   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 on X (Formerly Twitter) @AgileThought using #AgileThoughtPodcast!  

This week, Dan Neumann and Justin Thatil are joined by Mike Guiler to discuss the journey of a Project Manager shifting to fill the Scrum Master accountability. This episode mainly focuses on those Scrum Masters who are newer to this accountability and have a Project Management background. In this episode, they explore what happens when a Project Manager is assigned Scrum Master's accountabilities which can develop differently depending on the person's expertise and ability to learn and embrace Agile principles.   Listen to this episode to learn about the main aspects of a successful transformation.   Key Takeaways It is common for the Project Manager (PM) to assume the role of the Scrum Master. Scrum Masters who come from Product Management can incorporate their expertise in the process of shifting to Agility. Product Managers often know a lot about the business domain. PMs often have good relationships with the Team, which are crucial to initiating a transformation towards Agile. You can't easily hire for the business domain knowledge or the relationships. It is often easier to have current staff learn a new way of delivering value. A plan must be set in order to manage expectations between the development Team and stakeholders. Many non-Agile do not know who the stakeholders are Effective Scrum Masters will connect the team to the Stakeholders The Scrum Master must ensure that the entire Scrum Team is engaged with its stakeholders, showing the development of software and articulating the plan.  The Scrum Master does not need to take ownership of the relationship with its stakeholders but should empower the Team How do we create more and better channels of communication with stakeholders? Project Managers often see success as being on time and on budget. As a Scrum Master, being on time and on budget is not enough; the most important thing is delivering the business outcome. Status reporting is another area where PMs must work in transitioning to Scrum Masters. When an Agile Team operates well, progress should be transparent. Even status reports could become less valuable if the entire Team works together and is aligned, working with Sprint Reviews and information radiators.   Mentioned in this Episode: Inspired: How to Create Tech Products Customers Love (Silicon Valley Product Group), by Marty Cagan Project Retrospectives: A Handbook for Team Reviews, by Norman L. Kerth   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 and Justin Thatil are joined by their colleague, Mike Guiler. In this episode, they explore how a Product Manager shifts from just management to leadership and how this transformation influences the role. Dan, Justin, and Mike discuss tools and strategies, including OKRs, Story Mapping, and Hackathons, among others.   Key Takeaways Product management must study the market and users, becoming customer-centric and ensuring it is still viable for the business at the same time. It takes more than one individual to effectively perform the discovery function. It's a Team effort (Product Designer, Product Owner, and a Technical member). Discovery and design sessions are opportunities for Teams to unlock the art of the possible. The Team has to learn from rapid feedback while ensuring steps are taken to not hurt organizational reputation. A Product Manager must first understand how to help the Team approach a particular problem. A great way is to identify OKRs (Objectives and Key Results) and focus on the target market the Team is going after. Once the Team is aligned, the job can be done. A Product Manager sets an objective for the Team and allows them to work autonomously toward reaching it. Story Mapping: A Product Manager's ally on the journey to product discovery. Story Mapping is an easy way to frame what the Team is trying to achieve and the tool that might be the most efficient for that purpose. Story Mapping can also help identify the target persona for which the Team is building a particular feature. There is tremendous value in having the Team involved in Story Mapping and, as a result, immersed in and knowledgeable about the problem at hand. Hackathons are a great way to keep a Team motivated. Allow the engineers to explore; you will keep them engaged and motivated.   Mentioned in this Episode: Fall in Love with the Problem, Not the Solution: A Handbook for Entrepreneurs, by Uri Levine Inspired: How to Create Tech Products Customers Love (Silicon Valley Product Group), by Marty Cagan   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 and Justin Thatil are joined by Mike Guiler to continue the conversation that started in the last episode, where it was discussed how organizations can support their Managers. This time, they explore how Managers can help their Teams to shift to a more Agile approach.   In today's episode, Mike, Justin, and Dan dive deep into the reasons managers must be prepared to accompany their people in changing to Agile, sharing information, and asking the right questions to ensure the Team's involvement.   Key Takeaways When an Organization is shifting it is crucial to know what was the Perceived Value Proposition made by the Manager. A Manager as a Leader wants his Team to be informed and involved in the upcoming changes. A Manager must trust and value his Team's opinions. A Manager must be willing to share information as well as show curiosity about his Team's points of view about the Organization and its objectives. A Manager needs to support and empower Teams. In the Agile Method, words matter. There is significance in the different frameworks and mindset that come with Agile. A Manager needs to invest in creating amazing relationships with both the business and the technology sides of the organization. A Manager fosters communication and connectivity among all levels of the organization. Clarifying the roles, responsibilities, and what it means to be successful is a crucial part of a Manager's obligations. “Leadership is communicating people their worth and potential so clearly that they are inspired to see it in themselves.” — Captain David Marquet A leader helps their Team to upscale, so they are not stuck with the tools they already have to rapidly create value, which needs new tools, mindset, and engineering approaches.   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 and Justin Thatil are joined by Mike Guiler to explore how organizations can better support their managers. In this episode, they discuss two adoption patterns, the grassroots and the top-down approach, and the distinction between being a Manager and a Leader.   Key Takeaways The grassroots adoption pattern and the top-down approach in an Agile Organization: Grassroots starts at a Team level. The top-down approach begins with the boss. If an Agile Team is self-managing: What does a Manager do? A Manager must decide whether he wants to be just a Manager or a Leader because these are different roles. Leaders set clear objectives; they are not so focused on the daily chores but on the higher business-valued conversations. A Leader cares about how to build the environment. A Manager needs to work his way to becoming a Leader and less about assigning tasks to Team members. A leader's work should come from a mentorship place, sharing his knowledge and experience for the Team to explore (instead of being told what to do). An Organization can support a Manager embracing Leadership and becoming a servant leader. A Leader evaluates options and consults them with the Team; a leader does not impose practices. Communication is more valuable than processes and tools. The organization must have a plan in mind but check first how the Team responds. A Leader's job is to establish the vision, shifting away from the “how.” While the Team is busy executing the hypothesis, the Leader is thinking about the next step. The Alignment of OKRs is vital for an Organization. Ensuring that OKRs match the plans for the product and what the business wants to achieve is fundamental for companies. This way, everyone knows what's most important. How role descriptions are set up (performance reviews, salary adjustments) can influence the leader's job.   Mentioned in this Episode: Who Moved My Cheese?, by Spencer Johnson What Got You Here Won't Get You There, by Marshall Goldsmith and Mark Reiter Team of Teams, by General Stanley McChrystal   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 an external guest: Seth Maust, President and Founder of Five Star Life, an organization that aims to change perceptions of education, sports, and culture. Seth began 20 years ago researching why so many children were dropping out of school because they did not value education and ultimately did not value themselves. Five Star Life focuses on dismantling this root issue by ingraining a different curriculum they created that guides students in developing successful mindsets.   Key Takeaways Five Star Life focuses on attacking the root cause of student dropout. Children are not motivated to continue their studies because they don't believe in the current education system. A good education teaches students how to think (not what to think). A successful life begins with the right mindset. Create new habits. It is a 28-week investment. The Five Star Life system teaches students to think critically. The application of the learned knowledge is fundamental. Students learn to handle conflict the right way. Choose your hard! Ignoring conflict is hard, and confronting conflict is too. Motivation is the result of vision. What is the first step that you can take to achieve your goal? Focus on taking small, incremental steps. An excellent way to start is to make an image of what you want to achieve and pin it somewhere you can see it daily. First, you must create a vision and then goals, but most of all, you must truly believe it will happen. When you attach emotion to an image, belief is born. Everything you are now is the result of subconscious programming. Unless you consciously choose to keep developing, you will remain what you are and you will repeat the same cycles.   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, your host, Justin Thatil, is joined by three of his colleagues, Mike Guiler, Jim Beale, and Mariano Oliveti. In this episode, they explore the topic of accountability in Agile Teams and organizations. These four Agilists share their insights and experience on the role of accountability while explaining the value of tools such as OKRs and KPIs and the influence of a true leader in encouraging Teams by involving them in the whole process, trusting them, and enabling them to be self-directed and reliant.   Key Takeaways Why is accountability so important? How do we keep accountability in an organization? Accountability is needed to identify who will be in charge of each task. Accountability should start at the top but needs to be emphasized at all levels of the organization. OKR (Objectives and key results) is a goal-setting framework that assists in keeping the Team accountable and provides a way to measure the outcomes. KPIs are key performance indicators that also contribute to keeping accountability. KPIs measure a team's performance to ensure they are on track to meet their project objectives. Leaders encourage accountability in Teams. If a leader is willing to engage with a Team, he will share goals with them and the journey to achieve them. Leaders need to value the involvement of every member and encourage self-driven work. Keeping people informed of the “why” motivates them, while the “what” will only give them tasks. A good leader holds his Team accountable and empowers them to make decisions. Overall, a leader trusts his Team.   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 and Justin Thatil are joined by Mariano Oliveti and Erica Menendez to discuss DevOps, mainly how it contributes to creating safety and providing feedback during an Agile product journey.   In this episode, they share their knowledge about how DevOps eases the work and ensures value delivery. Listen to this conversation among Agilists for actionable suggestions and amazing real-life examples of Agile Teams benefiting from DevOps.   Key Takeaways The problems DevOps can help to solve: DevOps can help solve inefficiencies such as the ones resulting from introducing a lot of bugs into the code or when there is a lack of Team Collaboration. DevOps helps to break down the silos. DevOps is a real time saver. Opportunities that DevOps gives: DevOps provides the opportunity for automation, testing early, and keeping a repeatable and reliable process that will work. DevOps ensures that, at the end of the day, the result is a product that was built in an efficient way. Employees working with DevOps are generally happier and more satisfied with their work, especially when automation makes their tasks easier to achieve and grants them the time to invest in the things that really matter. Applying DevOps infrastructure allows us to scale in a repeatable manner. DevOps is also a way to find what is wrong even before the customer does. Starting with DevOps is free. Begin with what you have and grow from there. Big changes are rough! The more you work with DevOps, the better you will get at it.   Mentioned in this Episode: ACF Coaching Certification   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 and Justin Thatil are joined by Anitra Pavka, an Agile Coach with vast experience in product ownership and management. In this episode, Anitra discusses the value of prioritizing people in the software development journey and shares ways and strategies to communicate more efficiently among the Team and with users. She also outlines different approaches to engaging better with users to minimize risks and maximize time use.   Key Takeaways Anitra emphasizes the importance of being human-centric in software development. Always approach people with empathy and compassion. Telling stories is a great way to reach people and communicate your message. Be curious and open. Be aware of who you are building a system for. Capture users as a persona with a set of behaviors, goals, and motivations. The Team needs to know who the user is. The Team then can use its creativity and ideas to meet the needs of those users. The whole Team contributes to the conversation. Ways to engage with end users: What are the end users doing daily to deal with the problem you are looking at solving? Interact with people to see what they actually do instead of what they say they do. Seek customer feedback sooner than later to reduce risk in the long run. Learn to ask the right questions. 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, Mariano Oliveti joined Dan Neumann to discuss the importance of continuous learning and growth as an Agile Coach In this episode, Mariano shares his experience growing as a Coach. Listen to this conversation where Mariano and Dan dive deep into the steps of this incremental journey, which begins with awareness, followed by proficiency, to achieve mastery later.    Key Takeaways The first step is identifying how you would like to grow as a coach  At the beginning of your learning process, ask yourself: How do you intake and process information? What is your learning style? The second step is to find the topics that best resonate with you. To be an Agile Coach, you must perform specific skills at different levels, such as teaching, mentoring, facilitating, or coaching. There are complementary skills that can help you along the journey to becoming an Agile Coach. You need to have a good understanding of Agile practices and the Scrum framework. Business knowledge is also necessary. Be aware of your strengths and your opportunities. How can you be intentional about your learning? Being intentional is critical to mastering what you do.  Be honest with yourself about your goals and objectives and how you want to reach them. Listening is the primary skill an Agile Coach needs to have. Listening internally to how you react to the events around you and finding opportunities to grow. Leaning is a journey, be patient with yourself and respect your process.   Mentioned in this Episode: The  8 Stances of a Scrum Master ACF Coaching Certification DevOps Handbook   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 and Justin Thatil are joined by two external guests for Kanban University: Joey Spooner, Vice President for Community Development and Product Management, and Todd Little, Chairman of Kanban University.   In this episode, experts from Kanban University join the podcast to share their expertise with the audience. Listen to this conversation and learn about the trajectory of Kanban University and its fantastic community. Also, they dive into a profound exploration of what Kanban Methodology really is and how it can improve what you are already doing.   Key Takeaways What is Kanban? Kanban University has been educating a vast community on its method since 2013. The Kanban method is often misunderstood. Some significant aspects characterize the Kanban Methodology. It is a way to visualize the workflow, called operational practice. There are also Management Practices, which consist of taking and managing policies effectively in an organization. The practices of collaboration and experimentation are also of crucial importance. Kanban can also be used as a complementary practice to Scrum. A fundamental principle of the Kanban Methodology is to Start with what you do now. If you have started with Scrum, you can improve it with Kanban. Kanban is fundamentally an approach to improving your process framework; it isn't a framework itself. The Kanban Method vs. the Lean Manufacturing: Lean Manufacturing aims to remove uncertainty, which is conceived as a waste. Sometimes, uncertainty does not need to be eliminated; it is inherited, and often, it is this uncertainty that brings value. Kanban tries to understand knowledge work and its behaviors while still representing the workflow. How does Kanban manage the predictability challenge while doing complex work? There are three common challenges while working with complex work: Delay, Dependencies, and Dormancies. Every Team needs to explore possible solutions for these challenges. Check Team reliability. An approach to predictability: Do more and better estimates. Advice for Scrum Practitioners starting to use Kanban: You can use Kaban on top of what you are doing with Scrum for more efficiency. Kanban tools allow Teams to stay focused and deliver consistently. Find first what your struggle is at the moment and see how Kanban can help with it. Learn to manage resistance to change and get accustomed to constant evolutionary change. Learn from the water's capacity for adapting to its environment. Agile needs to adapt to culture as much as a culture needs to adapt to Agility. Take small steps. You have to get your system under control, map it out, and ensure it is not overloaded. If a system is overloaded, it is not predictable.   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 and Justin Thatil are joined by an external guest, James D Murphy, a United States Air Force Veteran, F15 Fighter, and instructed pilot. James founded a company called Afterburner Inc. and is now the CEO of Afterburner Capital; he wrote seven books and is an expert on the Agile Delivery Framework.   In this episode, they discuss the concept of flawless execution, meaning an execution that is as impeccable as possible (nothing is perfect!). James shares how he combined his military training with his work as an entrepreneur and expert in the Agile framework.   Key Takeaways Flawless execution can't be perfect; mistakes will take place. Start with simple frameworks that are easy and scalable. Find purposeful tasks and actions. Developing and effectively communicating the purpose of the Team's job is crucially important. Knowing more about the context and details is essential to prioritize the purpose. Intention and vision need to stay connected. The Team needs to be involved in every step of the process. The key to flawless execution is to have a common language to get work done. The truth is more critical than artificial harmony. Teams must foster psychological safety, which means that anyone can feel safe admitting an error without fearing reprimand. Building a safe culture takes time. Flawless execution needs a systematic approach. The system followed must enable good execution as well as flexibility; in this matter, simplicity overpowers complexity. Complexity will decrease performance while augmenting the chance of errors. First is the planning phase (who is going to do what and when). Once it's over, no more brainstorming takes place. After planning, the plan is briefed (repetition of what was planned and the accountabilities that come along with it). Execute! Don't get off track. Debrief as soon as the mission is over. Debriefing is almost as important as the mission itself, leaving a lesson to the entire enterprise, not just a small Team. Is there a gap between the obtained results and what was imagined and expected from the plan? The Team should ask itself, how did the success occur? And why? This entire process must be leader-led. It is the leader who first has to admit his/her mistakes. This transparency and honesty create the much-needed psychological safety at the Tream. Learn More: Afterburner website Afterburner on YouTube James D. Murphy on LinkedIn 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 and Justin Thatil, your hosts, are joined by Erica Menendez and Mariano Oliveti to discuss what it takes to deliver high-quality Agile Projects.   In this episode, they dive deep into what a successful Agile project looks like and describe the necessary steps to be taken in order to reach it.   Key Takeaways Clarify the purpose The company should have a purpose The culture you create should be in support of the purpose The products should align with that purpose Deeply understand the real needs of your users and meet those Adopting Agility can increase employee satisfaction Empower team members to take action in support of the company's purpose Empowerment increases engagement Engaged and empowered employees tend to lead to happiness. Understand that the entire Team works towards a specific goal. Focusing on people is a crucial aspect of a successful Agile Project, optimizing the relationship with people, ensuring there is collaboration among them, and granting space for people to open up in a psychologically safe environment. Fear of criticism and resistance to feedback are barriers to address. Working in an Agile way allows more predictability. Agile Teams add transparency to their work and separate tasks into smaller parts, which enables them to look at things a lot more closely than traditional Waterfall. Transparency must appear at all organizational levels, having realistic expectations and empowering everyone to make decisions. Implement feedback loops. Be willing to pivot based on feedback. Foster continuous learning Embrace experimentation   Mentioned in this Episode: The Coaching Trading Alliance: Life Coach Training and Certification   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 and Justin Thatil are joined by Erik Lindgren to discuss the concepts of MVP (Minimum Viable Product) and MMP (Minimum Marketable Product) and the differences between them.   In this episode, they explore an example of a successful brand that started the simplest way possible and became a multimillion-dollar success a decade later!   Key Takeaways Erik shares the story of Honest Tea, which grew into a multimillion-dollar company. They started with the MVP (making tea at Eric's home to sell later), and ten years later, Coca-Cola bought forty percent for forty-three million dollars. What is the simplest way to get to the market fast? Start with the minimum to get on the market and test your idea. It is crucial to shift from an existing platform to a new one with the minimum risk possible. What is the difference between MVP and MMP? MVP: We are unsure if there is a market for this product, who will buy it, and how they will respond to it; for that, you put together a business hypothesis. MMP: What is something that the market will really adopt broadly? There is a considerable risk in taking the Big Bang approach to a project. An integrative and incremental approach seems more effective than redoing the entire ERP system before going live. Grow a system organically instead of trying to do it all at once. A team must ensure they know whom they are solving a problem for to focus£ on what matters most. Mentioned in this Episode: Watch Flamin'Hot Documentary Scrum@Scale Framework   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 and Justin Thatil are joined by Rich Hundhausen for the second part of a deep conversation about Nexus. Rich is a software developer, Professional Scrum Trainer, and co-creator of the Nexus Framework for scaling Scrum.   In this episode, they dive deep into how to deliver value in the form of a working integrated increment of product, the role of the Integration Team, and the characteristics of each Nexus Event. They share valuable stories exemplifying how Nexus works for an improved scaling experience.   Key Takeaways Scale Scrum is still Scrum (plus additional features). The Nexus Integration Team is not in the original Scrum framework. The Integration Team is actually the Nexus's Scrum Master. This team is responsible for ensuring that Scrum is followed as established in the Scrum Guide and that its work is effective. The Integration Team works in a Scrum way by coaching, facilitating, teaching, and mentoring, but not hands-on (unless absolutely necessary). The Scrum Team's Developers do the work. The Integration Team does not do the integration, but it is accountable for it. Integration can mean lots of different things. Integration means solving any kind of dependency. The Nexus Integration Team does not have to meet daily but only when required. Everyone on the Integration Nexus Team has a daily job on the Scrum Teams and/or is the Product Owner, so when something does not go as planned, they bring it to the attention of the Integration Team when possible. The Nexus Events: First Event: Nexus Sprint Planning. This event aims to take another look at the upcoming work to ensure the organization of Teams and consider any last-minute changes. Big Room Planning takes place during this stage. All the planning at this moment is only for the current sprint (never beyond that). The output for the Nexus Sprint Planning is the Nexus Sprint Backlog for each Team, and the goal is to make any dependencies transparent to mitigate them daily. Scrum of Scrums: Scrum Team members are allowed to talk at any given moment. Second Event: The Nexus Daily Scrum. It is a Scrum of Scrums that occurs before the Daily Scrum. At this mandatory event, dependencies and integration issues are discussed. Third Event: The Nexus Sprint Review is where Stakeholders give feedback on the done increment but in a big room event. This event is the time to share feedback on potential cross-team work. The Last Event: The Nexus Sprint Retrospective. This event is an opportunity for the Scrum Team to inspect and adapt how they work, first through a pre-meeting with the representatives, then Teams have their individual retrospectives, and after, representatives meet again to make transparent any new experiments or improvements so the bottom-up intelligence can then be shared with the other Teams. There are around 60 complementary practices to Nexus (but none are new). Mentioned in this Episode: The Nexus Guide Listen to “Continuous Learning: Professional Scrum Facilitation Skills Training with Patricia Kong” and “The Nexus Framework for Scaling Scrum with the Scrum.org Team”   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, your hosts, Dan Neumann, and Justin Thatil, welcome an external guest, Rich Hundhausen, software developer, Professional Scrum Trainer, and co-creator of the Nexus Framewokr for scaling Scrum. This episode is the first of two parts, in which they discuss the features of Nexus and when and how to implement it.   Listen to this episode for a description of Nexus, how it started, and why it was developed. Rich, Dan, and Justin also dive deep into the definition of scaling, what is considered done, and the Nexus goal. Stay tuned for part two!   Key Takeaways Why do we have a Nexus Scaling Framework? Rich started working with Ken Schwaber, co-creator of Scrum, in 2009. Together, they created Scrum.org, “The home of professionals.” They later became interested in Scaling according to the Scale Agile framework. Are you really in a situation where you need to scale? Rule number one when scaling is “Don't.” Let your Team tackle the problems first. Always start small and add as needed. What is Scaling? Scaling is simply one product owner and backlog and multiple Scrum Teams. Everything you learned about Scrum for a single Team still applies at Scale with the Nexus. Additional features, such as the exoskeleton, are required for scaling. The number one reason to build Nexus was for dependencies on different areas (not only technical). Refinement has been a proof practice at single-team Scrum, and at Nexus, it has become a required event called Cross Team Refinement. What is the definition of Done? Everyone at Nexus is a creative person, and these people are motivated when they have space to implement their creativity. All Teams should have autonomy, purpose, and the ability to master their actions. Each Scrum Team can have its definition of done, but it has to stay on top of the unified set of items that the other teams share. The Nexus Goal: Do everything you committed to in the product backlogs.   Mentioned in this Episode: “Shu, Ha, Ri” Episode of The Agile Coaches Corner. Dan Pink's books and TedTalks   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 and Justin Thatil are joined by Erik Lindgren to discuss scope creep, a term that everyone working in software development knows well. The expression refers to adding further features or functions of a new product, requirements, or work that is not authorized.   In this episode, they dive deep into the challenge of managing timelines and budgets and how frequently a Team can find itself off-track, which is undoubtedly an uncomfortable position. Erik, Dan, and Justin discuss the importance of prioritizing properly, including possible improvements and requirements. Scope creep can be a learning opportunity waiting to be embraced by the Team!   Key Takeaways Scope Creep in an Agile environment: In an Agile setting, new ideas must be added to the backlog for them to be prioritized. Once in the backlog, it is necessary to decide whether it is a high priority or not. The stakeholder and client must know about the additional items so they can contribute to the Team in deciding what needs to be included and what can stay out. The involvement of the stakeholders can often be challenging for Agile Teams. What is the most valuable idea to be implemented now? The fact that some ideas are not prioritized at a particular moment does not mean they won't ever happen; they can take place at a different time. Keeping open communication with stakeholders can sometimes be a challenge. Often, Teams don't want to feel “exposed,” which is why they withhold certain information. Teams must share vital information with the customer; they can only tell what is essential for them. The “all or nothing” delivery threatens adequate time and budget management. A Team must focus on delivering new increments of value while balancing the inclusion of innovative features. Wanting to achieve everything on the backlog and additional items might be unrealistic; something must come out. Scope creep can be avoided with collaborative delivery. It can be a learning experience for the Team!   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 and Justin Thatil discuss Agility: How do you know if you truly are in an Agile environment? In this episode, they explore the meaning of Agile and the different features that make this framework unique, including Creativity, Teamwork, Mindset, Continuous Learning, and Psychological Safety.   Key Takeaways Does Scrum allow creativity? The Scrum framework was designed for complex situations where creativity is necessary since there is no “one right way” to solve a problem. What does it really mean to be Agile? Agile: Able to move quickly and easily. In the Agile framework, this is a constant guideline; the decisions must flow quickly and easily. Autonomy is crucially important. Teams need to be self-sufficient to deliver value. Inspecting and adapting the plan is necessary since a budget needs to be respected. Agile Teams deliver value throughout the process. Agile is about an actual team working on an actual problem (thinkers and doers are not working separately on finding solutions). Agile mindset vs a fixed mindset: Agilists learn by doing rather than over-analyzing before taking action. Every Agilist is part of a Team working towards a goal, not a solo player. By attending their daily Scrum, you can tell if a team is only Agile by name. They always work as a team rather than as individuals doing their jobs. Alignment! What is really the Team's approach? What is the business opportunity the Team is trying to reach? Effectively managing budgets can enable Agility Continuous improvement: There is no lifetime commitment to a particular decision. Instead, adjustments are made according to the needs. Value progress over an attempt to design for perfection Encourage ongoing learning Psychological safety needs to be modeled within the Team, and a context of continuous improvement allows space for speaking up and accepting failures to readjust the course of action.   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, Justin Thatil is joined by two of his Agile colleagues, Mike Guiler and Mariano Oliveti, to discuss the tiredness and frustration that can sometimes be caused by following the Agile process. Some organizations can even be convinced that Agile did not work for them; how can this wound be healed?   Key Takeaways Some organizations are sure that Agile didn't work for them. Sometimes, these organizations tried some Agile ways but never started from the beginning. Was “moving faster” all the organization wanted? If you don't adapt the values and behaviors, Agile will not be guaranteed to speed up the process. First, the organization needs to change its culture. These organizations might need to consider that Agile is a process, a hard process. Today's transformations are different from what they were ten years ago. Benefits of Agile: Many organizations need help with accountability, while Agile proposes an excellent method to ensure it. Agile is a way of approaching organizations to figure out what they can do for them based on their current needs. Agile is the approach that assists an organization in transforming its culture into a long-lasting, durable one with self-managing teams that achieve the desired outcomes. Doing Agile vs. Being Agile: Doing Agile is about going through the motions and checking the boxes, but, for being Agile, it is critical to change the culture. There has to be a need for change in the Organization, otherwise, Agile would not work.   Mentioned in this Episode: The Five Dysfunctions of a Team: A Leadership Fable, by Patrick Lencioni   Overcoming the Five Dysfunctions of a Team: A Field Guide for Leaders, Managers, and Facilitators, by Patrick Lencioni   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 and Justin Thatil are joined by an external guest called Rich Visotcky, President and Founder of Joint Insights, who is passionate about creating shared understanding. Rich is a Professional Scrum Trainer with Scrum.org.   In this episode, they explore the topic of cultural impact on transformation. We work in and for organizations that include several different cultures; this imposes challenges, resistances, successes, and opportunities to be seized, as well as other strategies to be used for better performance and communication while on the path of transformation.   Key Takeaways It is essential to know what is foundational for each company and how it has contributed to its success. Leadership can be the drive to success, but it is the culture that guides the Team to achieve its goals. The first step for transformation is to find what the organization truly values. Making changes doesn't mean losing who we are. Sometimes, it is necessary to take risks. The fear of doing something wrong can keep a Team from trying new paths. Self-management cannot be prioritized at the expense of accountability. Self-management does not mean anyone can do whatever they want. A Team needs boundaries (but not too many). A Team's success can be found in the balance between self-management, accountability, and well-executed boundaries. Changes need to be aligned. Leaders must communicate why the changes are important and back them up; they must often highlight what they are working towards. The company's values must be used and reminded throughout the entire change path. There can be two or three simultaneous initiatives to avoid confusing people with many variables. Conflict is inherent to the process. Attributes for a company to be truly Agile: Cooperation. Speed of decision making. Engaging in Trials. Empowerment. Technology adoption. Simplicity. Knowledge sharing. Innovation focus.   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, your host, Dan Neumann, is talking about a prominent topic: are the times of remote working about to end? Today, he is solo hosting this episode to assist you in navigating this new trend and successfully surviving these changes.   In this episode, Dan discusses hybrid work and the trend of returning to in-person work. He shares some strategies to help Teams thrive in this new work scenario. Things are changing rapidly in this evolving landscape, and several companies require their staff to return to the office; listen to this episode and get some valuable ideas on adapting and succeeding in this ever-changing world.   Key Takeaways The pandemic brought the remote working environment as a solution to many problems. For many companies, remote working was not a choice; it was a matter of business survival. Some benefits of remote working are time and money savings, freedom, and flexibility. Also, companies can attract more talent remotely. The ability of companies to innovate was hindered by remote work. Tips to work better in a hybrid environment: The benefits of a hybrid working environment are the flexible location to perform a job and the possibility of choosing which hours someone would decide to work. These aspects imply both synchronous and asynchronous communication. There can be a communication barrier between the in-work and remote workers; more spontaneity occurs in the office. Lacking non-verbal cues of remote communication can affect its effectiveness (video can help, but it is undoubtedly less accurate than in-person communication). Remote work promotes more isolation, less communication outside of the direct work area, and fewer additions of new members to Teams. Being onsite increases the opportunity to connect more to people in general, including those not strictly in our areas of expertise. There is a need to establish explicit Team norms (Make them visible!). When hybrid communication occurs in a Team, you must explicitly make room for the remote worker. What are your Team's agreements regarding responding to messages? Good calendar hygiene is a factor that enables good remote communication. Communicating clearly how a decision will be made can be challenging in a hybrid working environment. Decisions are not made arbitrarily; ensure what will be decided and how. Use mirroring for collaborating with the Team.   Mentioned in this Episode: Business Insider: “The remote work era may be coming to an end — if companies can afford to keep their offices open” “How Remote Work Affects Our Communication and Collaboration”   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, Justin Thatil, your host, welcomes Quincy Jordan and Pamela Dukes, Olympic Athlete and Agilist, who engage in a thoughtful conversation regarding how these two areas of expertise intertwine and how the abilities applied to professional sports enhance her role as an Agilist.   In this episode, you will learn about Pamela's journey as a professional athlete, the lessons learned, and the challenges that brought the knowledge that enriched her experience in the Agile arena.   Key Takeaways Pamela shares her most significant lessons as an Olympian and Hall of Fame athlete: “What got you here will keep you here.” You don't need a Herculean effort to go on; you just have to stay consistent. The Team has to support each other. If you are not competing, you are busy cheering for someone else. Quincy, who also went through his athlete years, brings two of the most meaningful teachings he obtained from his coach: All the way through (you don't stop until you are done). Run your race (stay away from comparisons). The Scrum framework mirrors the structure of College Athletics. The Head Coach was the Chief Product Officer, and his assistants were the product officers. The Scrum Master was the Team captain. The plans set for training could be weekly, monthly, or yearly, and once arranged, that was the guideline the athletes follow every day. Everyone knew the plan, but when circumstances changed, the plan was adjusted accordingly. These dynamics work similarly in Scrum; there are planned sprints and releases. At the end of each week, they would do competition drills where performance was tested (which looks like a sprints review) followed by a talk, reflecting on what could be improved (a lot like retrospectives). Get the lead, keep the lead. It is easier to do well and keep doing well than getting into a technical or cultural debt and getting out of it. Empower your Team: The success criteria should be how well you teach others. Practicing skill sharing is critically important. Leaders should walk away from the dangerous “hero complex”; a true leader teaches others how to do what they do. No one is particularly responsible; a Team succeeds and walks through challenges together. Each Team member has to do their part for the entire Team to reach the goal.   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 and Justin Thatil are joined by Misi Eyetsemitan. In this episode, they discuss the future of Agile, the advantages and challenges they see, and how far the Agile Methodology has come in the last two decades since its origins when it was created to achieve better and more efficient software development.   Listen to this episode and learn more about where Agile is going.   Key Takeaways The Agile Manifesto was not created rigidly but was open for future updates. Agile evolves powered by the problems that exist today. The execution of Agile will remain applicable in the future. In the future, Agilists will have to revisit the basics of Agile. Future Agilists will have to know why they have chosen Agile and why they are leveraging Agile. Agile is never the solution but brings organizations to the solutions they seek. Agile requires to have a transformative mindset. What are some challenges in the future of Agile? It will depend on the response of the Agilists. Agile is not a one-size-fits-all kind of methodology. The principles of Agile can be applied in various ways to tackle different problems. Measuring the value an Agile Team delivers is still a challenge. The key is to keep the focus on value. There are many ways to quantify value delivery. It is difficult for organizations and Teams to identify the metrics to measure what success looks like. The future of the diversity of Agile Teams: Agile Teams will continue to be more diverse. Diversity will also be needed to solve more complex issues.   Mentioned in this Episode: Learn more about Systemic Coaching Check the courses offered by the International Federation of Coaches   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 and his co-host Justin Thatil are joined by Hal Hogue, who has transitioned from an Agile Coach position to a Managing role and today shares the features of such a shift.   In this episode, Hal discusses his journey from working with managing engineers to becoming one of them. He mentions the particularities of both of these roles, the overlaps between them, and how these positions can work together to advocate for Agility and fast flow.   Key Takeaways What are Agile Coaches? The Agile Coach is a leader (just like the Manager). Agile Coaches are focused on letting others grow (individuals or Teams). Agile Coaches also serve as teachers. Coaches teach the true meaning of being Agile by living the values and principles specified in the Manifesto. Agile Coaches are change agents, helping organizations avoid becoming stagnant. The manager role is not defined in the Scrum Guide, but that does not mean it cannot exit. Manager accountabilities: A Manager's first responsibility is to know about the people part of the Team. A Manager needs to know what motivates the Team and their aspirations. It requires a lot of active listening and asking questions. A Manager should set clear expectations and roles for the Team. The Team should clearly know the reasons why they do their jobs. There is a critical relationship between the Engineering Manager and the Product Owner. These two roles need constant communication, aligning goals not only for the product but also around quality. A Manager should not decide things for the Team but should take essential matters to the Team and let them be part of designing the solution by giving them options and tools; this requires a lot of trust in both directions. Managers can help with impediment escalation or performance issues. The Engineering Manager and Product Owner is a critical relationship, as well as the Manager and Agile Coach or Scrum Master. A leader must be a coach and a servant leader for the Team but also for the Product Owner. A Coach can help a Manager understand what Agility is, its principles, and its values.   Mentioned in this Episode: Team Topologies: Organizing Business and Technology Teams for Fast Flow, by Matthew Skelton and Manuel Pais   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 two AgileThought colleagues, Justin Thatil, the show's cohost, and Lizmeth Rodriguez. They discuss the topic of how to achieve a seamless Value Flow, one of the SAFe principles, and the general importance of flow in a system. These three expert Agilists also assess the differences between Kanban and SAFe, especially regarding their approach to scaling.   Key Takeaways Principles of SAFe: Make value flow without interruptions. Value has to move efficiently from start to finish. What are the differences between Kanban and SAFe? SAFe is a detailed plan for working with big companies using Agile methods. Kanban is a simple way to make work run smoothly and always find ways to do things better. Kanban is not as strict as SAFe. SAFe and Kanban approach scaling at Agile differently. SAFe is a framework for large-scale Agile adoption, while Kanban is a more flexible methodology that can be adapted to various contexts and scales. According to SAFe there are 8 flow accelerators: 1. Visualize and limit WIP. 2. Address bottlenecks. 3. Minimize handoffs and dependencies. 4. Get faster feedback. 5. Work in smaller batches. 6. Reduce queue length. 7. Optimize time “in the zone.” 8. Remediate legacy policies and practices.   Mentioned in this Episode: Learn more about Measuring Flow with Flow Metrics Actionable Agile Metrics for Predictability: An Introduction, Daniel S. Vacanti The Heart of Business: Leadership Principles for the Next Era of Capitalism, Hubert Joly   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!  

Dive into six rules for managing your product backlog with AgileThought's Dan Neumann, Justin Thatil, and Mike Cooper. In the episode, Mike Cooper emphasizes the importance of managing expectations in Agile projects. The trio explores the principles of Agile scope management, the value of transparent communication, and the critical role of discipline in Agile success. 1. Analogy for Setting Expectations:     - Mike Cooper emphasizes the importance of setting real expectations at the beginning of a project.     - He uses an analogy of buying a dream house but having budget constraints, likening it to building systems with a defined budget and timeframe.   2. Scope Management:     - The concept of making everything transparent in the portfolio, deciding what's in and what's out.     - Six rules discussed:          1. Everything goes in the backlog.         2. Prioritize with the client or internal stakeholders.         3. Provide estimates.         4. Maintain transparency.         5. Nurture what's not in scope.         6. Say yes to everything, but place it in the backlog.      3. Importance of Communication:     - Justin Thatil emphasizes that everything they discuss boils down to different methods of communication.     - The objective is to know what to build and how to solve the problems they're set to tackle as a team.   4. Reminders for Development Teams:     - Mike Cooper reiterates the importance of including everything in the backlog.     - Teams often want to be accommodating, but they need to do so within the framework of the backlog.      5. Cost and Context Switching:     - Mike Cooper talks about the cost of small adjustments and changes.     - The accumulation of tiny tasks over time can lead to significant workloads and stressed teams.      6. Discipline in Agile:     - Mike Cooper and Dan Neumann discuss the misconception that agile means a lack of discipline.     - They stress that agile requires discipline and that "lazy agile" can be problematic.   7. Continuous Learning:     - Mike Cooper shares his current read, "A Culture Map" by Erin Meyer, recommended by his boss.     - The book delves into understanding cultural differences, especially for those working across borders.  

Dive into the intricacies of empowering teams with Justin Thatil, Mariano Oliveti and Erica Menendez. They unravel the ties between trust, psychological safety, and the overarching impact on organizational morale and performance.   Major Discussion Points: Analogies & Metaphors in Team Dynamics Concept of kick-starting a team. Driving metaphor: Same route, varying challenges daily. Trust in Teams Importance and fragility of trust. Danger of general punitive measures after one team's misstep. Rules, Guardrails, & Accountability Establishment and reassessment after failures. Relationship between autonomy, self-accountability, and psychological safety. Negative spiral from lack of psychological safety leading to a command-control environment. Concept of Experimentation "Fail fast, cheap, and forward." ROI of experimentation and organizational risk tolerance. Differences in approach for predictable vs. unpredictable industries. Journey of Empowerment The long process built on trust and time. Dynamics of teams slowly evolving as trust develops.   Mentioned in this Episode: Failing Well with Dr. Amy Edmondson  Listen to Mariano, Erica and Justin in a recent episode! Podcast Ep 249. Coaching vs. Mastering the Details with Mariano Oliveti and Erica Menendez 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!   Share These Tweets! “Self-Accountability begins with Self Awareness” — Mariano Oliveti   “Empowerment through trust and autonomy takes time” – Erica Menendez

This week, Dan Neumann is joined by Erica Menendez and Phillip Lisenba to explore the Product Owner's accountabilities, especially when they are filled by a highly technical professional, and how this can impact the Team's work in positive and negative ways. They share their own Agile experiences dealing with mature Product Owners and what the Agile and the Scrum framework proposes for these cases.   Key Takeaways Challenges and opportunities of dealing with a highly technical Product Owner: The Product Owner's relationship with the Team will determine the extent of the accountabilities on each side. A strong Scrum Master can help balance the Team out due to the collaboration of a technical Product Owner who has brought a lot to the table and helped the Team create a solution. The Team and Product Owner working in a psychologically safe environment grow together in constant intercommunication. A mature Product Owner helps maintain the balance. A very technical Product Owner can be highly prescriptive and fall into the mistake of making highly predictive sprint plans, and, as a result, developers turn more into coders. The Product Owner has to be able to transfer some of their knowledge to the Team since they won't always be there to help them. The Scrum Guide remarks that the Product Owner is the “what” person, and the Team is the “how.” The entire Scrum Team is accountable for creating a valuable, helpful increment every sprint. The Product Owner is responsible for a backlog that optimizes value, and there could be a dysfunction if the Product Owner is disconnected and can't contribute as a partner for a valuable sprint plan. When the Product Owner and the Team can communicate directly, they can take advantage of everyone's skills; that way, they can leverage everything the Team brings. Everything depends on relationships and communication.   Mentioned in this Episode: Listen to Podcast Ep 197. Approaching Vacations with an Agile Perspective Get SAFe certified!   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 Justin Thatil and Mike Dionne to discuss the topic of Agile assessments. Let's assume it: No one likes to be assessed since it tends to feel deeply uncomfortable. In this episode, these three colleagues discuss the meaning of an assessment, its purpose (that changes according to different environments), and how to conduct assessments following the Agile methodology.   Key Takeaways First: What are you trying to assess? Remember that data can be changed and looked at in many different ways (what could be a problem). The Assessments at the Scrum Master level are meant to evaluate the current state of a Team. Start with a series of questions for a health check: Do you feel you are listened to by a Team? Do you feel you have a voice? Do you feel the Team acknowledges you? Do you feel safe in that environment? If the answer is “Yes” to all four questions on a 1-5 scale, give it a 5. If the answer is affirmative to only a couple of the questions, give it a 3 or 4; if the answer is ‘Yes” to only one, put a 0 or 1. This process must be repeated, and you will realize that people answer with varying honesty over time. Over the journey, you will notice how the Team dynamics start to pick up. As a result of the assessment, the Scrum Master becomes better informed in his or her role. How is the Team performing? Velocity isn't everything! Other parts of the overall assessment can also give a good perspective regarding a Team's performance. Scrum enables problems to surface faster so that they can be addressed quicker. Velocity is only suitable for predicting how long it can take to finish a group of backlog items. Start with the Team's identity and move to the things that improve the Team's performance to reach the goal you had set. After that, find what you want to improve next. Repeat this process once a quarter. We can control the process, not necessarily the outcome. The whole organization needs to pull in the same direction. The Team needs to be willing to participate in the assessment. If the Team feels the measurement is unnecessary or useless, the assessment won't be used as a tool for improvement, and this metric won't have the value that it was expected to have. Assessments also exist for organizations. How long does it take to develop an idea? Does the organization have the ability to improve?   Mentioned in this Episode: Check this episode: “Jorgen Hesselberg on Data-Driven Continuous Improvement”.   The Tools: 5 Tools to Help You Find Courage, Creativity, and Willpower — and Inspire You to Live Life in Forward Motion, by Phil Stutz and Barry Michels   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 Phillip Lisenba, Justin Thatil, and Erica Menendez to discuss the particularities of the Business Analyst role in a Scrum Team.   In this episode, they explore the valuable role of a Business Analyst and the crucial role of effective communication among Team members to maximize the efficiency and effectiveness of a Scrum Team.    Key Takeaways The Three Scrum Accountabilities: The first accountability of the Agile Team is the Scrum Master, whose responsibility is to help the Team form Scrum at the maximum level, providing interaction and coaching. The Product Owner is responsible for the backlog's value, priority, and order. The Business Analyst can be considered as one of the Developers on the team. Sometimes, the BA fills some of the Product Owner's accountabilities regarding the backlog. For a Healthy Backlog, the Team must know how to split responsibilities properly. Every organization is different, sometimes, the BA works with the Team, and the product owner works with the Business and splits responsibilities up. In sharing responsibilities, communication is critical. Having clarity and alignment about the product goal and the sprint goal is fundamental. Developers, Product owners, and Team members working together need structure and boundaries for everyone to accomplish their goals and responsibilities. Keep the goodwill! Maintain the culture of communication; you never know when you will have to call up somebody for a favor. Take advantage of refinement sessions with the developers to confirm what needs to be changed (as opposed to researching it yourself). Documenting everything is, most of the time, not necessary. It is only necessary to record some stories and some product backlog lines specifically for each goal. Communication is a time saver; it prevents unnecessary documentation since developers are already informed about the process and implied accountabilities. If people can figure things out by themselves, writing every detail down becomes less of a need.   Mentioned in this Episode: SAFe: Scale Agile Framework Certification   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 and host of today's conversation, Justin Thatil; Justin welcomes Mariano Oliveti and Erica Menendez to discuss a recurrent topic: Coaching versus Mastering the Details.   This episode addresses the complexities of coaching, especially considering the different maturity levels and even diverse areas of expertise within a Team. They also dive deep into the matter of a Scrum Master's expertise, debating whether or not it is a requirement to perform the role better.   Key Takeaways To coach anybody doesn't necessarily mean you have to be the master of that specific topic, but it could be really beneficial in certain situations. Coaching will depend on the maturity of the Team and even in which areas each Team shows more maturity than others. Does the Scrum Master need to understand every single detail of the work the Team is doing? Certainly not, but it can help! A Scrum Master must need to know a certain type of technology to be able to do the work. A Scrum Master needs to show empathy to know the Team's struggles and identify their challenges. The Scrum Master must ensure the Team knows its purpose and how to reach it. A Scrum Master is not defined by their technical background. A Scrum Master needs to know the details regarding the Agile Methodology but learns with each new client the aspects of that particular business, process, tools, and overall product. A Scrum Master encourages a continuous education mindset within the Team. When a Team gets better at sharing information about their learning, it indicates a Scrum Master is fostering a psychologically safe environment. A Scrum Master models vulnerability for the Team Members to feel safe to practice it, too.   Mentioned in this Episode: The Scrum Guide   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 welcomes his colleague, Justin Thatil, who hosts today's episode. Justin is joined by Quincy Jordan and Phillip Lisenba to discuss Executive Coaching. In this episode, they address Executive coaching, its differences and similarities with regular coaching, how it is done, and how it can be encouraged. Listen to this episode, which contains actionable tips for your Agile practice!   Key Takeaways Is Executive Coaching the same as regular coaching? Both encourage, believe, and help Teams become even greater than they are. An Executive Coach must have the business knowledge and the experience that relates to the struggles that the Team deals with. An Executive coach must know how to be a listener, too. Continued improvement is an important aspect of Executive Coaching. A Coach needs to manage timing and reading the group. A coach must tell who is coachable and who isn't and be curious enough about why someone shows coaching resistance. An Executive coach must be adaptable and agile when encountering an opportunity to help the Team and become a better partner and friend to them. The mindset of the CEO directly influences the work of an Executive Coach. Before intending to coach, you need to invest in creating a relationship with each Team member. An Executive Coach should try to help the Team out quickly. Goal setting: How to set a vision to lead the Team toward: Every leader should have the crisper possible vision. Without a vision, people will feel scattered. A Team led by an Executive Coach is a place where tough conversations are welcomed. Nurturing a positive and healthy culture makes a great contribution to creating a psychologically safe space for a Team to grow. An Executive Coach should invite the Team to give him feedback about the areas where he needs to improve. Coach whom you can reach, coach whom you can coach, and whom you have access to. Improve that culture! ABC: Always Be Coaching and Always Be Coachable.   Mentioned in this Episode:   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, your host is Justin Thatil, and he is joined by Michael Guiler and Jim Beale to answer one of the listeners' questions: What does “good” look like for a Team during a sprint planning, a sprint, a PBI, or a backlog?   In this episode, Justin, Michael, and Jim share functional tips and great examples of what is considered good (and bad) in different crucial Agile moments.   Key Takeaways What does “good” look like for sprint planning? A good sprint planning starts with a good PBI. It needs to state what the desired outcome is clearly. Make sure there is plenty of collaboration on the PBI. You need to have a healthy backlog. Separate some time to look ahead; a fair estimation is needed. What does a “bad” sprint planning look like? Writing PBIs in sprint planning or the sprint; when you are behind the curve, you are winding them in real-time. PBIs are written by the product owner. Or business analyst outside of the Team (working in isolation). What does a “good” daily scrum look like? It is great when the developer accountabilities start talking to each other. A good sprint goal is essential (PBIs align with them). Pay attention to where people are directing their comments. Remember, this is a Team work where everyone is working collaterally.   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!  

Dan Neumann welcomes Justin Thatil and Mike Guiler to today's conversation.   This week, they are discussing estimation and sizing in an Agile environment. Both estimation and sizing are essential for Agile teams to plan their work, manage expectations, and adapt to changes in a flexible manner. They promote a collaborative approach to understanding the work ahead, fostering team communication, and enabling the team to provide more accurate forecasts without the rigid limitations of fixed time-based estimates. Listen to this episode for actionable tips and examples of how to best estimate and size for the best interest of Organizations and Teams.   Key Takeaways Estimations can be inaccurate sometimes. Pressure on the Team can cause the estimations not to be good in predicting the costs of a product. Positivity bias can also influence estimations negatively. Removing the contingencies does not make the estimation better. The key to estimating is taking a project, breaking it down into details, estimating the number of hours, and adding them up. All the sequencing and the dependencies are not considered. Remember there is a Team working on that project; you can't take only one member's speed or ability under consideration, but the idea is to consider the issues the whole Team could confront. The estimate process needs to be leveled up. Establish a scale so you can evaluate the size of the project and its proper cost. Remember to include the contingencies, the unknown. Human ability to compare can only be achieved accurately when it is done among two known things. Can story points be represented by hours? A Team's data can be normalized to take care of the next estimation. Example: I am a product owner, how do I determine the cost of a featured leveled backlog? I have to identify a real value. Add up the Featured Leveled Backlog times the Team Velocity, and that will equal the number of sprints, which will lead to a cost. Does it need to be faster? Employ more than one Team! Ask: How much do you want to spend and how quickly do you want to move? Hours: Are they useful for estimation or, on the contrary, are they misleading? It depends on the maturity of the Team. Justin shares an example of a way to discover the average velocity of a Team.   Mentioned in this Episode: Story Points — a mathematical perspective, Salman Ali Banani Intuitive prediction biases and corrective procedures Lead without Blame: Building Resilient Learning Teams 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!  

This week, Dan Neumann is joined by his colleague Justin Thatil to talk about what good Scrum Masters do when an Agile Team reaches maturity.   In this episode, they discuss the features of the Emergent Collaboration Maturity Model, its stages, and how this relates to the role of the Scrum Master as a leader, facilitator, coach, manager, mentor, teacher, and change agent. A Scrum Master fills many roles; join Dan and Justin in this discussion to explore the benefits of having a Scrum Master and the risks of not having one.   Key Takeaways What does a mature Team look like? A mature Team knows how to self-organize and solve problems. A mature Team understands its purpose. A mature Team knows its members' strengths and features. Scrum Teams become self-managing Teams; they are always encouraged to experiment. Emergent Collaboration Maturity Model: The different stages in the Maturity Model are Unaware, Exploratory, Defined, Adoptive, and Adaptive. Justin shares the example of Patagonia. What is the value of having a Scrum Master in an Organization? The eight stances of a Scrum Master: servant-leader, facilitator, coach, manager, mentor, teacher, impediment remover, and change agent. A Mature Team is a high-performance Team. The Team must feel beyond happy about their work, pushing it further, wanting to constantly improve, and taking their work to the next level. A mature Team has reasonable forecasts and manages stakeholders' expectations. Organizations are constantly experiencing changes and transformations. A Scrum Master can be working with a Team for an amount of time and during that period, many changes take place; the number of the Team's members, the product, and the challenges that the Team faces, all of these can change. A mature Team takes on the task/challenge that is presented, and evolves and changes in order to find solutions. The Scrum Master's accountability needs to be defined clearly. It is a serious misunderstanding to believe that if a Scrum Master is really good he can take multiple Agile Teams. What is a Scrum Master's career path? The Leadership of the future looks like the role of a Scrum Master, a leader who brings the best out of the people that they work with.   Mentioned in this Episode: The 8 Stances of a Scrum Master Quality over Quantity: Squirrel Burgers Learn more about Jacob Morgan The Female Brain, by Dr. Louann Brizendine   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!