Advertise on podcast: Agile Coaches' Corner

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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!