Agile Coaches' Corner

Scrum expert Mike Guiler discusses the importance of product vision, adapting Kanban boards, and defining a shared 'Definition of Ready' in Scrum. They emphasize the need to focus on outcomes and utilize visual tools for better teamwork and system progress.

This week, Dan Neumann and Justin Thatil are joined by the first-time guest, Jeannine Gonyon, a Performance Engineering Practice Lead at Agile Thought. This episode explores the differences between performance testing and performance engineering, emphasizing the crucial role of Performance Engineering in mitigating unnecessary risks and protecting the Organization’s reputation.   Key Takeaways Performance Testing and Performance Engineering test: Performance testing is the process that follows manual testing. After ensuring the application is working, testing for “non-functional” takes place, which is called performance testing. Performance engineering tests go to an extra step of analysis to find out exactly where any kind of optimizations are needed. Some Organizations are hesitant to invest in Performance Engineering. Some organizations consider Performance Engineering to be a “luxury.” Would you take a risk with your reputation? You will if you don’t perform performance testing on your product. Knowing the facts before production is priceless! The earlier you do Performance Testing, the more you have the maneuverability to make any changes. The costs of Performance testing: Performance testing does not happen in a shared environment, which adds a cost. There are ways of reducing the costs. You can spin the environment when you need it. The cost is manageable if you do it earlier. If you do performance testing, the earliest is the best way to mitigate risk (better than spending much money later). What is the relationship between Performance Testers and the rest of the Team involved in developing a product? Performance testers are technically aligned with manual testers because they need to know when the product is ready for testing. Performance testers work closely with the development Team, must be involved with the product owners, and be present at every step of the workflow. Performance testers need to know as much about the application as those using it. Performance Testing and AI: Currently, the engineering part can benefit from using AI tools for analysis in a more casual manner. A quick growth of AI tools applied to Performance tests is expected. Testing in Production versus Performance Testing: Performance Testing prevents the risk of a bad user experience. There is a place for performance testing before the product goes to production.   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!  

This week, your host, Dan Neumann, is accompanied by Gill Broza. Gil is known for simplifying the complex and making the implicit explicit so people can make better choices. He is a writer and never prescribes a single right way.   In this episode, Dan and Gil explore how to help teams grow and produce improved outcomes while diving deep into a discussion regarding Gil’s latest book, Deliver Better Results.   Key Takeaways Agile introduced the concept that multiple ways exist to create, ideate, and deliver products. The variety of Agile methods can be paralyzing Gil proposes five levels of adoption to find the best “fit for purpose” The primary purpose is to help the company succeed while doing it timely and showing adaptability. Six aspects of fitness for purpose in the delivery process are throughput, outcomes, timeliness, adaptation, consistency, and cost efficiency. The value lies in how well we serve the company and the effect of the work. The people matter the most; they are the ones transiting the process. The strategies proposed by Gil work because people start to behave differently. Ways of working result from combining the tactics we use (process, practices, roles, artifacts, tools) and the mindset we employ while executing the tactics. The mindset is defined by choice-making, which has three components: purpose, beliefs, and principles. Sometimes, you need to change tactics and mindset simultaneously. It requires hard work but could be the only way to work. Decisions made in one place of the system can have ramifications everywhere else. Gil prefers to use the term “way of working” instead of “process” since it is a bigger construct and includes the choice-making component. The words we use matter; they communicate the way that we work and how we approach tasks.   Mentioned in this Episode: Deliver Better Result: How to Unlock Your Organization’s Potential., by Gil Broza Chapter 1 of Deliver Better Results Thinking in Systems, by Donella Meadows The Drunkard’s Walk: How Randomness Rules Our Lives by Leonard Mlodinow Random Acts of Medicine: The Hidden Forces That Sway Doctors, Impact Patients, and Shape Our Health, by Anupam Jena and Christopher Worsham Thinking in Bets: Making Smarter Decisions When You Don't Have All the Facts, by Annie Duke   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!  

This week, Dan Neumann and Justin Thatil are joined by Mike Guiler to continue the discussion on Norman Kerth’s book Project Retrospectives. In this episode, they explore the last three chapters, which are filled with exercises to apply at Retrospectives, specifically when sensitive topics are to be addressed.   Key Takeaways Some Retrospective activities are designed to address emotionally charged topics. Failure must be accepted and embraced in postmortem retrospectives; otherwise, no one would be open to discussing it. As a facilitator, try to find the highest leader available in your organization that is willing to share with participants an instance in which they themselves faced failure and what he or she learned from it. This establishes that it is okay to talk about failure. Becoming a Facilitator: You have to “walk the walk”; facilitators are made by practice. Ask for help when you need it! Don’t be afraid to ask for assistance when your capabilities are limited. As a facilitator, you can also contact someone outside your organization for support. A useful resource is getting feedback from a second facilitator about the Retrospective. Don’t be defensive; feedback is always an opportunity to grow. Allow space for intense emotions during Retrospectives. Fostering the expression of emotions is healthy and cathartic for the organization, but sometimes, it can be challenging for the facilitator to deal with them during the event. Listen actively, assign a meaning to those feelings, and try to identify the feeling arousing about that feeling. Identify which feelings can be discussed at the Retrospective and which others should be addressed one-on-one. Tools for Facilitators: Ask for help. When something isn’t working, try something different. Be humble enough to know when to pivot. Avoid triangulation. Encourage people to talk to the person, not about the person. Congruent vs. incongruent messaging: When delivering a message that describes a problem, first address how the problem is impacting you (the self), then the context, and finally, the intention and how this caused the problem. A similar approach is the Situation-Behavior-Impact framework.   What to do after Retrospectives? Collect the readout: Make a summary of what was done in the Retrospective. Collecting a library of Retrospectives can help estimate projects. Retrospectives contain a significant amount of useful data for the organization. After recapitulating the event, think about what can be improved. The information coming from Retrospectives is a great way for a better forecast.   Mentioned in this Episode: Project Retrospectives: A Handbook for Team Reviews, by Norman L. Kerth Intuitive Prediction: Bias and Corrective Procedures, Daniel Kahneman Listen to Project Retrospectives: Book Exploration (Part 1) and (Part 2)   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!  

This week, Dan Neumann and Justin Thatil are joined by Mike Guiler to continue their discussion of Norman Kerth’s book Project Retrospectives. In this episode, they dive deep into chapters 6, 7, and 8, analyzing some of the exercises and techniques described in the book and the immense value of learning to plan retrospectives for them to be fruitful. They close this conversation by addressing “postmortem” retrospectives and the importance of unpacking a failed project.   Key Takeaways Chapter 6: Exercises and Techniques: There are many ways to facilitate retrospectives and this chapter describes several intentional exercises meant to shake things up. Norm addresses three essential parts of a retrospective: the readying, the past, and the future. The readying is meant to allow team members to prepare and bring forward relevant topics. Teams often want to save time in retrospectives by skipping them or shortening their length. They do that because they find them ineffective and do not see the value in investing time and energy. A Scrum Master must invest in making retrospectives into a much more impactful event for the team. About facilitating better retrospectives: Retrospectives need to take a longer time (three hours). There needs to be “emotional freedom” in the group’s atmosphere to facilitate and enable members to participate; it’s crucial to be aware of different personalities and how they engage with others. The topic’s sensitivity during the retrospective needs to be considered. The postmortem retrospectives: When a project fails: Be conscientious about not injecting your perspective; sometimes, it can do more harm. An idea must be presented along with its benefits, strategy, and plan, including the costs and reasons why it is helpful to implement it.   Mentioned in this Episode: Project Retrospectives: A Handbook for Team Reviews, by Norman L. Kerth Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diane Larsen   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!  

This week, Dan Neumann and Justin Thatil are joined by Mike Guiler to share their continuous learning journey. They have been exploring the book Project Retrospectives written by Norman Kerth, and today, you will listen to them discussing chapters 3 to 5, where they dive deep into the role of Retrospective facilitators.  They compare Norm’s guidance against their own experience and reflect how practices presented are still be relevant today as retrospectives are more widely practiced in the industry.   Key Takeaways Retrospectives: Internal or external facilitators? You can be present without necessarily having to share your opinions and thoughts.  An external facilitator for a Retrospective is not part of the Team but can be a well-informed outsider. In the Scrum framework, very often it is the Scrum Master who facilitates the Retrospectives, but it does not have to be this way. There is a conflict between a full contributor on the retrospectives and a facilitator, which is why an external facilitator can be significantly valuable. Should Managers be in a Project Retrospective? Managers must be allowed to be present at Retrospectives, but their involvement needs to be regulated. Engineering retrospectives take time and effort. Sometimes, the same feedback is received during several meetings, which is why it is important to plan retrospectives carefully considering Team Styles, the way the questions are brought forward, and any characteristics that can come up after thoughtfully observing the Team’s dynamics. Identifying the most important topic for the Retrospective must be brought forward by the Team. The best achievement is when the Team expresses its needs as a result of the effective work of a facilitator (as opposed to someone dictating what the Team’s interest or need is).   Mentioned in this Episode: Project Retrospectives: A Handbook for Team Reviews, by Norman L. Kerth   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!  

Mike Guiler and Anitra Pavka discuss the importance of user interviews in product discovery, emphasizing open-ended questions, active listening, and cultural shifts towards customer-centric innovation. They highlight the value of small experiments, usability testing, and iterative product delivery with a focus on customer empathy and continuous learning.

This week, Dan Neumann and Justin Thatil are joined by Mike Guiler to discuss the journey of a Project Manager shifting to fill the Scrum Master accountability. This episode mainly focuses on those Scrum Masters who are newer to this accountability and have a Project Management background. In this episode, they explore what happens when a Project Manager is assigned Scrum Master’s accountabilities which can develop differently depending on the person’s expertise and ability to learn and embrace Agile principles.   Listen to this episode to learn about the main aspects of a successful transformation.   Key Takeaways It is common for the Project Manager (PM) to assume the role of the Scrum Master. Scrum Masters who come from Product Management can incorporate their expertise in the process of shifting to Agility. Product Managers often know a lot about the business domain. PMs often have good relationships with the Team, which are crucial to initiating a transformation towards Agile. You can’t easily hire for the business domain knowledge or the relationships. It is often easier to have current staff learn a new way of delivering value. A plan must be set in order to manage expectations between the development Team and stakeholders. Many non-Agile do not know who the stakeholders are Effective Scrum Masters will connect the team to the Stakeholders The Scrum Master must ensure that the entire Scrum Team is engaged with its stakeholders, showing the development of software and articulating the plan.  The Scrum Master does not need to take ownership of the relationship with its stakeholders but should empower the Team How do we create more and better channels of communication with stakeholders? Project Managers often see success as being on time and on budget. As a Scrum Master, being on time and on budget is not enough; the most important thing is delivering the business outcome. Status reporting is another area where PMs must work in transitioning to Scrum Masters. When an Agile Team operates well, progress should be transparent. Even status reports could become less valuable if the entire Team works together and is aligned, working with Sprint Reviews and information radiators.   Mentioned in this Episode: Inspired: How to Create Tech Products Customers Love (Silicon Valley Product Group), by Marty Cagan Project Retrospectives: A Handbook for Team Reviews, by Norman L. Kerth   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!  

Mike Guiler, a Product Leader, joins Dan Neumann and Justin Thatil to discuss the transition from Product Manager to Leader, emphasizing customer-centricity and team collaboration. Topics include OKRs, Story Mapping, and the importance of setting clear objectives for team autonomy and success.

This week, Dan Neumann and Justin Thatil are joined by Mike Guiler to continue the conversation that started in the last episode, where it was discussed how organizations can support their Managers. This time, they explore how Managers can help their Teams to shift to a more Agile approach.   In today’s episode, Mike, Justin, and Dan dive deep into the reasons managers must be prepared to accompany their people in changing to Agile, sharing information, and asking the right questions to ensure the Team’s involvement.   Key Takeaways When an Organization is shifting it is crucial to know what was the Perceived Value Proposition made by the Manager. A Manager as a Leader wants his Team to be informed and involved in the upcoming changes. A Manager must trust and value his Team’s opinions. A Manager must be willing to share information as well as show curiosity about his Team’s points of view about the Organization and its objectives. A Manager needs to support and empower Teams. In the Agile Method, words matter. There is significance in the different frameworks and mindset that come with Agile. A Manager needs to invest in creating amazing relationships with both the business and the technology sides of the organization. A Manager fosters communication and connectivity among all levels of the organization. Clarifying the roles, responsibilities, and what it means to be successful is a crucial part of a Manager’s obligations. “Leadership is communicating people their worth and potential so clearly that they are inspired to see it in themselves.” — Captain David Marquet A leader helps their Team to upscale, so they are not stuck with the tools they already have to rapidly create value, which needs new tools, mindset, and engineering approaches.   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!