Agile Coaches' Corner

This week, Dan Neumann is joined by Christine Bush, a brand new Agile thinker.   In this episode, Dan and Christine are discussing Agile Transformations. As Lyssa Adkins describes, an Agile Coach is someone who has seen lots of different success and failure patterns over time. Change is never easy, and that is the reason why Dan And Christine are diving deep into the necessary features of a well-conducted Agile transformation.   Key Takeaways What is important when an organization is looking for an Agile Transformation? Transformations have to come from the top and leadership has to be committed to them. The leadership has to be ready to invest in education for the Team members of the organization and to guide them through the Transformation. Transformation cannot be an option. Middle-level managers are key to a successful Transformation, they need to be trained and guided in the process. What is next after the training is over? Agile Coaches are crucial in this stage since the application is a whole different story. Change can be scary. Let’s experiment, instead of thinking about it in terms of winning or losing. Keep your eyes on the goal. Are some other roles instrumental when transitioning? There could be a lack of clarity on some roles at the beginning. All Team members are working together to deliver outcomes in short cycles with rapid feedback loops. The business stakeholders help with the requirements but sometimes they get confused by the new events.   “Don’t just give them the title, buy them the tool, and expect the Agile process to work.”   Organizations want to be Agile but they don’t give them the necessary coaching and facilitation that people need to be successful. Providing support is what enables Teams to become self-organizing and successful. Be patient; small victories can get a long way.   Mentioned in this Episode: “What is Agile Coaching?” by Lyssa Adkins Scrum: The Art of Doing Twice the Work in Half the Time, by Jeff Sutherland   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 Michael Cooper, Agile Thought’s Chief Architect.   In this episode, Dan and Mike explore the topic resulting from the previous conversation they had regarding technical debt, which is, once you identify the debt, what do you do about it? Michael presents three possible strategies: the most common, the undesired, and lastly, the pragmatic and practical solution.   Key Takeaways In response to technical debt, the first thing you can do is nothing. Not doing anything about technical debt is the path chosen by many people. Doing nothing is a pragmatic approach, but only works if you are planning to do nothing with the product. Often a complete replacement is the way chosen to respond to technical debt. This could be considered a relatively undesirable strategy since it is an extremely risky approach. What if the developers that wrote the code are dead? How can you know what was in the original product? Coming up with a completely new product (not a duplication) could be a response to technical debt. This is a safe alternative but depends on whether the stakeholders will accept it. It should not be just a replacement strategy but a comprehensive innovative solution, a game-change strategy. This strategy would cost about twice the budget. The practical solution: Slowly strangling the product. This is a long and pragmatic process, where you may decide to leave parts of the system. This strategy will preserve the functionality of the system and produce the expected result over time. What is the cost to change? It is very difficult to anticipate the costs. How do you train the Team to approach technical debt? The Team makes the decision whether they are capable or not to take the task.   Mentioned in this Episode: Listen to What is Technical Debt? With Michael Cooper   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 colleagues, Hal Hogue and Misi Eyetsemitan.   In this episode, they explore a question that came up in a Coaches’ practice recently that was about the differences between a Product Owner and a Business Analyst. Are both the same? Do they have different business accountabilities? How do both enter the big picture?   Key Takeaways ● Product Owner and a Business Analyst are totally two different roles. ○ They vary by responsibility and by definition of functions; they are two entirely different roles. ○ Both roles can help in the accountabilities of Scrum. ○ Exploring the history, we traditionally had Business Analysts and Project Managers. The Scrum Framework does not have either of these titles. this ○ The Product Owner focuses on the vision and the profitability/marketability of the product (all about value). ○ The Scrum Master is all about the framework. ○ The Development Team has the accountability to develop the product and the process that will ensure that the product or task is addressed in an achievable way. ○ Business Analysts can help the Scrum Team by making sure that the backlog is representative of the vision of the product and the input of the users, stakeholders, and the Developers. ● Business Analysts are valuable when there is a scale in Agile. ○ When there is a robust product that has multiple Teams working on it, a BA is valuable. ● Is the need product- or experience-driven? ○ The answer may depend on the organization and on how Teams are set up. If the organization already has the operational role of a BA embedded within the Scrum Team, you can’t ignore it, it is part of the structure of that Team. ● Exploring each Team member’s accountabilities and responsibilities is a great way to prevent problems and safely scale. The Herculean Doughnut is an effective practice to determine roles and their reaches.     Mentioned in this Episode: Learn more about the Herculean Doughnut Zombie Scrum Survival Guide, by Christiaan Verwijs Find what Dan Harmon’s Story Circle is about.   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 guests, Mariano Oliveti, and Hal Hogue to talk about a topic that was inspired by a listener who recently was in a meeting where this question came up: What does a Scrum Master do with a Team that is very mature?   In this episode, Dan, Mariano, and Hal explore the concept of the maturity of a Team; does the continuous learning journey ever reach an end? Can Scrum Masters fully accomplish their work? Listen to this episode to find the answers to these very thought-provoking questions.   Key Takeaways What does a Mature Team look like? A mature Team has a growth mindset, members are always trying to improve. A mature Team fails occasionally, they learn from these experiences and are not afraid of failure. Members of a mature Team often actively listen to each other, they have healthy conflict, and they are not competing against each other. Mature Teams focus on the outcome of what they are doing. Can a Scrum Master still provide value to a very mature Team? A Team might be great, but it will never be perfect; there is always an opportunity for continuous improvement. If the Scrum Master is achieving a point where he believes there is nothing more to contribute to a Team, maybe he is confronted with his own fixed mindset; did this Scrum Master lose his curiosity? A Scrum Master is part of the Team; he needs to self-reflect on his role constantly in order to do things differently and better for the entire Team. Inviting a third party to facilitate activities for the Team and give an outside perspective is very valuable. A Scrum Master must nurture an experimental mindset in their Team. Trying something different is always an enriching experience. A Scrum Master must provide a safe environment where Team members are not afraid of failure.   Mentioned in this Episode: Learn more about Agile2022, Nashville The Agile Mindset — and Beyond, Linda Rising   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 Agile’s Thought Chief Architect, Michael Cooper to explore the topic of Technical Debt.   In this episode, Dan and Mike share how Technical Debt has become a dirty term among technical and non-technical people, where it can be considered to be a waste of time and money. Mike is here to demystify Tech Debt and talk about the necessary steps to take when encountering it, like finding its root cause and advancing a strategy to address it.   Key Takeaways ● What can be some indications that technical debt is present? ○ The first sign is that things are not going right, people can be unhappy about some aspect of the platform, system, or project. ○ One indicator is that the velocity is slowing down. ○ When decisions are procrastinated we accumulate tech debt... is this a deliberate choice? Not really, but we still refuse to make decisions to address it. ○ Stress is an indicator of Tech Debt. ○ The passage of time will create Tech Debt. ○ When defect rates get to a point that they are no longer tolerable or acceptable, you have to consider the decisions that were put off in order to reach that state. ● How to avoid technical debt: ○ Automated Testing ○ Unit Tests for capturing the developer’s intent ○ Static Code Analysis tools (such as SonarQube) for generating metrics about code complexity. ● Most code in the world has high-tech debt. However, it is not an issue because people don’t need to change it. ○ Software becomes “hard” when it gets enough tech debt. ○ The most used strategy is to do nothing when encountering tech debt, and if you are not making changes to the code, it is an acceptable and reasonable approach. ○ The highest reach approach is trying to change and rewrite the entire codebase. You are likely to lose the functionality that you originally had. ○ One way of approaching tech debt is to make slow changes only when you hit that piece of code again.   Mentioned in this Episode: What is technical debt? By Chris Cairns and Sarah Allen Applied Software Measurement: Assuring Productivity and Quality, by Capers Jones. Agile Estimating and Planning, by Mike Cohn   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 friend and co-worker Ola Tunde.   In this episode, Dan and Tunde are exploring the matter of burnout, which sometimes is not that noticeable, and as a consequence, can pass unnoticed among co-workers. Burnout can result from many personal issues combined with the pressure of working in a small or big organization, and it can translate into a general loss of interest and motivation. Listen to this episode to find the difference between stress and burnout, and how to invest in yourself in order to rescue yourself from burnout.   Key Takeaways How can you tell if you are feeling burnout? Burnout is physical, emotional, or mental exhaustion, accompanied by decreased motivation, lower performance, and a bad attitude towards oneself and others. Burnout is different from depression. Burnout results from prolonged exposure to stress. It is a chronic state, a place of exhaustion. There are three negative psychological impacts that burnout has on a person’s life: Depersonalization. Emotional exhaustion. Lack of personal achievement. There is a close relationship between stress and burnout. When you are under stress you can still control the situation, but when you experience burnout you don’t have the energy to even address certain circumstances. There is a healthy type of stress that promotes getting closer to solving a situation. Leaders need to identify and understand those employees who are feeling burnout. Good leaders (not managers) approach those who are acting differently and showing signs of burnout to find how they could be assisted, starting by giving them the chance to take a break. We are our worst critics, we need to learn to prioritize our needs, and take care of ourselves. Stop for a moment and set the goal of being kind to yourself, shift your mindset. Take care of yourself: workout, take a break to go for a walk, take two days out of work, and take more time off!. Do what relaxes you. Seek help. Leadership needs to create autonomy and empowerment; that is the reason why leaders need to encourage Team members to let their voices be heard.   Mentioned in this Episode: Read more about burnout in this Psychology Today article.   The Leader Who Had No Title: A Modern Fable on Real Success in Business and in Life, Robin Sharma   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

This week, Dan Neumann is joined by two Agile colleagues: Erica Menendez and Justin Thatil.    In this episode, they discuss the features of a high-performing Scrum Team and how this closely interacts with following and honoring the Scrum Values of openness, commitment, focus, courage, and respect. Dan, Erica, and Justin share valuable examples of their own Agile Journeys to define the main characteristics of a mature Scrum Team.   Key Takeaways A great Scrum Team: Follows Scrum values: openness, commitment, focus, courage, and respect. Knows how to focus. Identifies the goal to be achieved and works in a self-organized way in that direction. Is about having the psychological safety to be open about feelings, difficult circumstances, and even celebrations. Social time at the Daily Scrum is up to each Team to determine. The Team must volunteer to take action. Scrum Team members must be able to recognize each other’s strengths. Team Members can help each other with their personal goals. How does a mature Scrum Team behaves when things don’t go well? Courage and respect are needed to face the problem. Team members know how to respectfully disagree. Identify what is going to be improved, changed, and done differently. A Scrum Team must be willing to try something different, experimenting together. A Scrum Team is committed to working together in all of the different Agile values. A Scrum Team is also willing to fail when trying to solve a problem with an innovative approach. Trust lives in a Scrum Team.   Mentioned in this Episode: Agile Selling: Get Up to Speed Quickly in Today's Ever-Changing Sales World, by Jill Konrath   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 Gerardo De La Fuente to talk about Agile and what it looks like to really embrace this Agile methods.   In this episode, Dan and Gerardo discuss those cases when Agile seems to be assumed but actually, it turns out to be just a shallow performance. Are people just showing up or joining with heart and soul in the Agile ways? Listen to this episode for a great synopsis of what truly is to embrace Agile.   Key Takeaways ● Showing up vs Embracing Agile ○ Agility for a Scrum team requires an understanding of all of the different roles in order to have the right expectations. Everyone has different accountabilities! - When Teams are challenged, the Scrum Master might be tempted to provide solutions, but that does not help in the long run. Teams should come to their own conclusions. - A Scrum Master has to know how to facilitate and listen, as well as to make the right questions. - A Scrum Master does not have the leading role in the play, the star is the Team. A Scrum Master needs to embrace the role of a Servant Leader. ● Teams need to understand the purpose of Scrum, its values, and its pillars (transparency, inspection, and adaptation) in order to fully realize the benefits of this Agile method. ● Scrum Masters find a valuable resource in collaborating and sharing situations and ideas. ○ Receiving feedback is crucial! ○ There needs to be psychological safety on the Team so people can be open to feedback. ○ In a Team, all members are peers collaborating with each other. ○ Collaboration also takes place with the Product Owner. ● Admitting you don’t know is tough. ○ It takes courage to provide insides about aspects that are not understood or are being done incorrectly. Being open from the beginning saves a lot of trouble. ○ When there is a knowledge or skill gap, it is helpful to reach out to someone else in the organization for help. ● Agile Teams commit to delivering value ○ The entire Team works together and contributes towards reaching the goal.       Mentioned in this Episode: The Leader Who Had No Title: A Modern Fable on Real Success in Business and in Life, Robin Sharma   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

This week, Dan Neumann, your host, is answering a very common question: Why would an organization use Kanban or Scrum?
 In this episode, he explains the benefits of both approaches, describing each of them and identifying which of them is more suitable for an organization.   Key Takeaways ● The kind of work an organization is doing will define the methodologies or approaches to take. ○ Scrum is an excellent framework for organizations that are doing complex work, as it is creating software. ○ If you are in conditions of uncertainty, you want to deliver value frequently, and de-risk your approach, a Scrum framework is the most applicable. ○ The Kanban method is more thana board with signs and signals. ○ The Kansan method is a disciplined approach. It includes making status clear, articulating clear policies, set work in process limits, measuring and manage flow, and then make incremental improvements over time. ● Scrum or Kanban: A false choice. ○ Both can complement. ● Why Scrum? ○ It works! ○ Scrum is clearer than Kanban about rolls, events, and artifacts. ○ Be cautious, there are people using Scrum immaturely and not to its fullest benefit. ○ It is much easier to find employees using the titles in the Scrum framework. ● Why Kanban? ○ With Kanban, organizations start where they are. ○ The Kanban method is great for creating transparency and supporting experiments for how you want to improve the flow of work. ○ The Kanban method can be applied at many different levels and related to other groups within the organization. ● How long can your organization maintain focus? ○ Kanban fits better for organizations that are doing work that is frequently changing priorities. ○ Scrum looks to support a product goal, and focus is maintained for longer periods (three to four weeks sometimes).   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 Eric Landes to answer a listener’s question about development. Our listener asked: How can a non-technical Scrum Master or a Scrum Master introduce technical skills and practices to strongly opinionated engineers?   In this episode, Dan and Eric are sharing how to shift the mindset from wanting to know it all about the design to one where emergence is embraced. They share practical tips and examples of real Agile scenarios to make change easier and lessen its costs.   Key Takeaways ● How to help engineers to embrace emergence: ○ Model the behavior and examples. ○ Go on a learning journey together. Invite them to join the process if they have some technical knowledge. ○ What is in it for them? They don’t have to spend time on a design to release that later could not scale as expected, or didn't address the customer’s needs. ● How to make change easy? ○ Eric shares how he started his Agile journey by creating an application that received a lot of resistance from the management. ● Emerging design is critical. ○ The design is fundamental to the core functionality, but the architecture is probably going to fall over in an unexpected way, even with experts things don’t always get exactly right. Testing rapidly is the way of finding what is wrong earlier. ○ Make critical architectural decisions first, instead of waiting until the last possible moment. ● What are the things people need to get right in the first Sprint? ○ Chose at least one programming language to use. ○ Identify the tools that are going to be used and where are you going to deploy the first iteration. ○ Let’s experiment with the architecture. ● The cost of change in the development is still present. ○ Take it to the Team: How can we lower the cost of change? How can we make architectural change easier?   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!