Agile Coaches' Corner

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!  

This week, Dan Neumann is joined by his colleague, Phillip Lisenba. In this episode, they explore the value that a Scrum Master can provide. Often, organizations reach a moment in their transformation when they question whether or not a Scrum Master is needed and how significant their role is. Listen to Dan and Phillip diving deep into the heart of the role of a Scrum Master and how it is essential for an organization’s success.   Key Takeaways The Scrum Master Role: The primary purpose of a Scrum Master is not administrative; it is to empower and help the Team self-organize and self-manage. In a Daily Scrum, a Scrum Master is optional. A Scrum Master should do more coaching from the back of the room than he does from the front. The Scrum Master empowers the Team to the point where they run the meetings independently. At the beginning of his career, a Scrum Master can tend to do all administrative tasks and more to prove his value but later realizes his job is to empower the Team and set it up for success even when he is not around. The Scrum Master role also reminds the Team that they are all together, not about pointing fingers but solving problems together. Servant Leadership: A Scrum Master must know how to influence the Team while serving them. A Scrum Master finds ways to improve continuously. The Team wants to create what the customer requested and innovate on the architecture to support that. Everyone needs to be on the same page and also be willing to pivot. A Scrum Master needs to know the Team’s needs: What does the Team need? More ownership? More Process? How do we know if the Team is actually improving? Don’t confuse activity with results. A Scrum Master should ask himself: Are we getting a good return on the investment? Are we getting increments of value? The importance of conducting a Sprint Review: The Sprint review is an opportunity for the Team to check on the work they delivered and work with the Product Owner, the business, and the stakeholders to verify they are receiving what they expected.   Mentioned in this Episode: Renew your certification at Scrum.org OKR Institute 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 Christine Bush, an experienced Agile consultant, sharing how she got where she is on her Agile journey.   This episode is dedicated to those who might be new in the Agility field and are looking for guidance and inspiration to persist in moving forward on this continuous learning journey that the enables Agility. Listen to Christine’s testimony about a Special Education Teacher and Agile expert, who applies and combines her training to assist organizations following Agile principles.   Key Takeaways Where did Christine start? Her education started in history and political science, but then turned toward the field of special education, where she spent almost five years.  Special education requires teachers to build specific curriculums adapted to each student’s needs.  These skills are helpful now in Agile, while she helps clients achieve their particular goals. The reasons Christine turned her attention to a technology-related field: Writing a grant showed how passionate she felt about “management” tasks. During her time in special education, she researched, learned, and taught others about brand-new computer software. Christine started working for a Software Company. Joined the PMI Obtained her PMP Later, she got her PMI-ACP. Christine began her education on the Agile ways where she met all kinds of different professionals shifting to Agile. Willing to try on different roles What overlaps did Christine see between special education and a more technology-oriented environment? The common points among these fields were: - Implemented robust frameworks. - Research-based studies are in both fields’ foundations. - Maslow’s hierarchy of needs. - Problem-solving in general. - Collaboration and communication. - Coaching a Team. How is coaching similar in Special education and the Agile methodology? Coaching is done in different parts of the organization. Coaching is helping others grow; students or organizations. People enjoy down-to-earth examples that coaches give to define abstract concepts. Students of all ages love activities.   Mentioned in this Episode: PAL (Professional Agile Leadership) Blooms Taxonomy Turn the Ship Around! - David Marquet   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 Jamie Christoforou, Vice President of Portfolio Management at American Express.   In this episode, Jamie discusses her career, how she became Vice President of Portfolio Management, and how the company leaned toward an Agile methodology at the beginning of its digital transformation. Portfolios don’t stop; they are, by nature, the continuous flow of an organization. Jamie and Dan explore how an organization such as American Express underwent an Agile transformation emphasizing outcome and delivered value by bringing teams together and accelerating strategic alignments.   Key Takeaways Jamie shares about American Express’s transformation from Waterfall to Agile. Firstly, they ensured everyone was ready to shift their mindset to become an Agile organization. They moved forward dynamically; not everything was planned. The focus started to be the outcome that was tried to be achieved. Bringing everyone together! Stakeholders, product teams, and engineers came together in consistent forums. These forums were needed to understand what they were building, why they were doing it, and what was the outcome they were expecting. What does it look like to manage a portfolio in a more Agile way? Portfolio and product operations were critical. Accelerating strategic alignment, bringing together the right people to deliver the same value to customers having the most possible impact. Before Agile, teams worked independently and went through the significant shift of becoming organized by value streams; all the teams came together. Dependency is Agility’s nemesis. Find the right time to start upfront planning. It is important not to start too soon or too late. Keep the focus on the outcome. SAFe and program increments: The SAFe model helps adapt and shift faster when new things occur.  Experimentation at a portfolio level: The product needs to be tested to learn more about it. The process needs to change if the outcome has changed, and everyone must agree. Teams work to drive efficiency, optimization, and the right goals for customers. What would Jamie wish she could have done differently? In the beginning, do not create a structure that is confined to organizational nuances. Define your point of departure and then try to figure out how you will get to your point of arrival. Think about your tool sets; they shouldn’t hinder your journey but should be a way to communicate to have data and insights. (For example, automation is critical! Mainly operating at a big scale.) Processes are only as robust as the outcome they drive.   Mentioned in this Episode: Building For Everyone: Expand Your Market With Design Practices From Google’s Product Inclusion Team, by Annie Jean-Baptise   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 to discuss the connection between the popular series that just came to an end called Ted Lasso, and Agile Coaching. In this episode, Dan and Justin dive deep into Ted Lasso’s messages which are filled with wisdom. They analyze the many parallels that can be found in the main character’s approach to bring about change. His humorous ways of connecting with others amongst his many other tactics are certainly good examples that Agile Coaches can model after.  (FYI: Relax! There are no spoilers contained in this episode!)   Key Takeaways Working in conditions of uncertainty: Ted says, “I can fill two internets with the things I don’t know about football.” which reflects the uncertainty that many Agile Coaches experience when they take on specific projects, specifically when doing brand-new product creation. An Agile Coach has to move forward even in conditions of uncertainty. The end goal needs to be clearly defined. When Ted starts his job, even his boss sets him up for failure. What does it mean for an organization to “be Agile”? What does success look like under Agile principles? Effective vs. Efficient: Sometimes the help available is good enough to move forward while waiting for an expert could be an unnecessary waste of time and delay in finding the solution to the problem at hand. Be willing to experiment; sticking too much to your expertise could prevent your Team from moving forward. Achieve Engagement: First, Ted tries to heal the Team’s dynamics. “You don’t have to be best friends to be good Teammates.” Creating a safe environment: Ted starts with the “suggestion box.” Sometimes it is easier to speak our minds anonymously. Check for alignment: An Agile coach needs to make sure that she/he is in alignment with what the Team also considers a priority. Innovators, early adaptors, and laggers: Ted appears to be against a number of laggers. There is a need for early victories, celebrating those small wins is valuable in order to achieve the overall goal. Believe! You have to believe things can happen, things can change! Have a 10-second memory like Goldfish: Let go! Don’t let your emotions take over. Strive for excellence but don’t get paralyzed by the circumstance.   Mentioned in this Episode: The Surprising Power of Liberating Structures: Simple Rules to Unleash A Culture of Innovation, by Henri Lipmanowicz and Keith McCandless.   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 Buyi Kalala to discuss Agile teams and the fundamental agreements that help to build a strong foundation. In this episode, Dan and Buyi talk about teams, how they operate, how they conduct themselves, and how they achieve consensus about the ultimate goal for the team. Listen to this episode and find a discussion on the Team working Agreement and the value of having a definition of ready and a definition of done.   Key Takeaways Team Working Agreement: When creating a Team, you have to consider that you are dealing with many personalities. Every member has to agree on how they will relate to one another and how the team intends to operate. The true intent of a Team Working Agreement is to make that team the most remarkable that it can be. It is a working document designed to help the team be the best it can be. Working agreements can be created for any group of people, including between teams and their stakeholders. The Working Agreement should evolve over time. What is the definition of ready? A checklist of characteristics for a refined Product Backlog Item (PBI) can help ensure that the work is defined enough to include in a Sprint. The team must have alignment and a shared understanding before backlog items are included in a Sprint. There needs to be a structure that identifies who they are doing the work for, why they are doing it, and what that work entails. Remember: Who, What, Where, When, and Why. Revise your Team’s definition of ready as needed. Definition of Done: The Definition of Done is included in the Scrum Guide. This can be captured as a list of conditions that must be met before the PBI  is accepted by the Product Owner. The Acceptance Criteria are entirely different from the Definition of Done.  AC is specific to a User Story. Characteristics of a Definition of Done applies broadly What is done and what isn’t? New teams sometimes avoid drawing the line. Remember that 80% done isn’t done. Move from implicit to explicit understanding. We need to shift to value-based instead of activity-based.   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 explore the ways in that Rolling Wave Planning can help organizations in their Agile journey. In this episode, Dan and Eric explore the meaning of rolling wave planning and how it can help you respond to changes when delivering projects with high amounts of uncertainty.   Key Takeaways What is Rolling Wave Planning? It consists in planning a piece that is known and understood at the present moment and rolling the other parts into the future. Not planning at all is a misunderstanding of what Agility is. Rolling wave planning involves looking into the future where everyone can see the plan and how it is adjusting. Rolling Wave Planning and its connection to stakeholder management: Rolling Wave Planning in a large organizations equals to multiple teams and even numerous product lines. Agilists plan things and make informed decisions. A programmed increment mechanism is similar to rolling wave planning. Getting started with a Rolling Wave: It is not enough to just bring people together and start. You need to do something before sprinting. Can you deliver value in every Sprint? The best practice is to do some planning, but not too much, when looking ahead at how that value is going to be delivered. It is essential not to over-plan for the future; there are many aspects you are not going to be able to predict. Making sure you don’t get lost in the Rolling Wave: Use some of the constructs within Scrum; first of all, identify your definition of done, and what risks you should mitigate. Keep the alignment with organizational goals.   Mentioned in this Episode: Extreme Ownership: How U.S. Navy Seals Lead and Win, by Jocko Willink   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!  

Description: This week, Dan Neumann shares the most downloaded episode from the Agile Coaches’ Corner podcast called What is Agile? where Sam Falco and Dan unpack the true meaning of Agile. You can’t miss it!   Key Takeaways: Why was it necessary for the Agile Manifesto to be declared? What is the history behind it? It was created in reaction to what was happening in the software industry in 2001 (predominantly waterfall and other predictive methods with lousy track records for delivering on time). In response to “scope creep” (AKA changes or uncontrolled growth in a project’s scope at any point after a project begins). Because it is tough to predict what you need to do when you’re trying to solve a new problem every time. Out of necessity (as any work that requires creativity and a high degree of uncertainty about the outcome you’re trying to achieve [such as software development] is difficult without a set of principles and values). Because every problem is unique with software development. In the Harvard Business Review in 1986, an article was published titled “The New New Development Game” that outlined the need for a new way of working where teams could be given objectives instead of tasks, and they work together as a unit to accomplish their work. The “relay race” method was clearly not working, and agility offered a better model, better compared to playing rugby. “Agile wasn’t: ‘Let’s get together and think about a new way of doing things.’ It was: … ‘Hey, we’re doing some things. It seems to be getting better results than the industry as a whole. What are we doing that’s common across the different methods?’” — Dan Neumann What is the Agile Manifesto? Those that came up with the Agile Manifesto didn’t put it together to justify their existence; they put it together because they recognized the success they were having through its methodology and wanted to figure out the commonalities. It’s the thing we point to when someone says, “What is agile?” If you ask if something is Agile, you can reference the manifesto’s values and principles. What is Agile? It’s creating a competitive advantage and being the disruptive force. Delivering working software as your primary measure of success. A collection of values and principles as laid out in the Agile Manifesto. It is the ability to respond to change and demand deliberately, not just react. Controlling risk: Building stuff that people actually want and will use. Solve the problem that the customer has called for and not gold-plating everything. Agile practices are simply that; practices — they’re good in some circumstances and not good in others. Are you changing just to change or are you harnessing change for competitive advantage? Is change happening to you or are you creating the change? Change is not just about keeping up with your competition but making your competition keep up with you.   Mentioned in this Episode: Extreme Ownership: How U.S. Navy SEALs Lead and Win, by Jocko Willink   The New New Product Development Game, by Hirotaka Takeuchi and Ikujiro Nonaka | Harvard Business Review (January 1986)   Agile Software Development Ecosystems: Problems, Practices, and Principles, by James A. Highsmith   The Surprising Power of Liberating Structures: Simple Rules to Unleash A Culture of Innovation, by Henri Lipmanowicz and Keith McCandless   LiberatingStructures.com   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 Misi Eyetsemitan to address the topic of Portfolio Management in an Agile ecosystem. In this episode, they discuss Agile Portfolio Management as a dynamic approach that enables organizations to effectively manage and prioritize their projects, initiatives, and investments. Dan and Misi explore how Agile Portfolio Management embraces flexibility, adaptability, and continuous learning. This transformative approach empowers teams to respond quickly to changing market demands, seize opportunities, and deliver value incrementally. In this rapidly evolving business landscape, Agile Portfolio Management is a vital framework for organizations seeking to navigate complexity, drive innovation, and achieve sustainable success; listen to today’s episode and learn more about its implementation, benefits, factors, components, and even its challenges.   Key Takeaways Challenges when implementing an Agile Portfolio Management: Trying to do too much can be an obstacle. Scaling can be complex when an organization is transforming to Agility. Mindset changes are needed! Context switching can be painful. In the hands of the customer, everything cannot represent the same value. Shifting from a project mindset to a product mindset. Shift to a customer-centered practice; this is a paradigm shift. Ask: What kind of product does our customer want? What does this product mean to the customer? Agile Portfolio Management is a Team Sport; it pertains to all the organization. Agile Portfolio Management is a good platform for business Agility. Organizations can deliver great value in the customers’ hands as a result of working with Agile Portfolio Management. There is continuous planning since there is a constant evaluation of the ongoing process. It is very useful to leverage insights from the market, the customer, and those executing the development. Factors that need to be considered when making decisions in terms of what is most valuable: Cost of delay. Value in the hand of the customer. What needs to be prioritized? What are our: Must haves, Could Haves, and Should haves? What are the components of Portfolio Management? Trust must exist not only for leaders but for those who execute. There needs to be a system alignment in respect of what the priorities are. Consistent communication and partnership, everyone needs to understand the “whys.” How to get started in Portfolio Management: It can be a challenge to hoard money at the beginning to realize later that it needs to be spent or there won’t be the same amount the following year. To successfully implement an Agile Portfolio Management there needs to be transparency and trust. Decentralization of decision-making, especially at the local level. Teams need to be able to scale the Agile Mindset across the organization. Implementing customer-centric strategies all across the organization.   Mentioned in this Episode: Agile Portfolio Management, by Jochen Krebs   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 one of the Principal Consultants at Agile Thought: Eric Landes. Training often appears as spending hours sitting behind a computer screen or in a classroom, absorbing information. However, Immersive Programs present a radically different approach.   In this episode, Dan and Eric delve into the key characteristics of an Immersion Program. They draw a comparison with a more conventional method, listing the advantages of this innovative and engaging approach that becomes a great means to maintaining alive a continuous learning process.   Key Takeaways How is an immersion program different from a more traditional educational approach? Traditional classes are not optimal for all practitioners. The immersion program proposes a structure separated into parts, and the time is not linear since its dynamics involve reviewing previous concepts before continuing to move forward. Immersion programs avoid long periods of instruction, framing the content into smaller sections that could be made up of two or three hours a week, and a whole program could last eight weeks. Trainers dedicate their time and work to clients after the training as part of a coaching engagement. Immersion is a way of getting continuous learning without stopping the rhythm of the work. Immersion programs do not disturb the production of work. The content in an immersion program does not change from Scrum Master or Product Owner. Immersion programs offer a different format and consider diverse learning styles. Immersion programs suit well into a community of practice. Challenges of taking immersion classes: How can you effectively do Scrum while taking an immersion program over the course of eight weeks? Eric shares how Immersion Programs coexist with an effective line of production.   Mentioned in this Episode: Scrum.org Running Remote: Master the Lessons from the World’s Most Successful Remote-Work Pioneers, by Liam Martin and Rob Rawson   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!