Agile Coaches' Corner

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!