This week, your host, Dan Neumann, is joined by Norm Kerth, author of Project Retrospectives: A Handbook for Team Reviews. Norm Kerth wrote this book before Sprint Retrospectives were invented! In this episode, Norm and Dan explore the subject of Project Retrospectives. They discuss the learning opportunity within every major project event, especially in instances where things did not turn out favorably. Norm explains when and when not to have a Retrospective and how to prove its value to organizations reluctant to grant the necessary time to invest in them.

Key Takeaways

• An unconventional career:

• • Norm realized that the best way to move up inside a corporation was not to be in line or follow other people’s paths but to find the void that other people were leaving in the company and fill it. This is an amazing way to contribute.

  • Norm wrote the book Project Retrospectives even before retrospectives and sprints were created.

• Project Retrospective:

• • Learning from past experiences is quite valuable, which is why Retrospectives are so beneficial for a Team.

  • The first step is to assume that every member of the Team is doing the best they can according to their capacities and knowledge. If this is not the foundation, people will fear being blamed for mistakes or errors instead of focusing on the learning opportunity.

  • Once the Team has learned from past experiences, they can decide how they will operate differently in future circumstances.

  • Retelling the story is very crucial.

  • The necessary four questions: What went well? What did I learn? What do I want to do differently the next time? What still puzzles me?

• Retrospectives need time, but organizations do not always agree.

• • When you reach the end of a project and are late starting the new one, don’t rush! Remember that if there is no reflection on the last project, the following will repeat its mistakes.

  • The best way to improve organizational processes is to involve the people doing the work.

  • Consultants must ask four questions: How did you get to where you are? How do you feel about where you are at the moment? Where do you want to go? What do you want to do differently? The Retrospective is the way to find the answers to these questions.

• When is a Retrospective not needed?

• • There is no point in having a retrospective in dysfunctional organizations. It doesn’t matter how a Team changes its ways if the organization has major conflicts that are not addressed.

  • The manager needs to be involved in Retrospectives; if there is no collaboration from leadership, why waste the time?

  • Don’t do the Retrospective only because it is trendy to do it.

• How can Retrospective’s value be demonstrated?

• • First, retell the story of the project, going through the most significant events. Search for the wisdom while answering the four questions.

  • Break the Team into naturally affinity groups (they will probably group together according to the area of work). These subgroups are encouraged to propose what they want to do differently. These suggestions have to be achievable and measurable so their value can be tested in the following Retrospective.

Mentioned in this Episode:

Project Retrospectives: A Handbook for Team Reviews, by Norm 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!

This week, your host, Dan Neumann, is joined by an external guest: Kristen Belcher, a Software Developer turned Agile Coach. In this episode, they discuss liberating structures, simple and subtle tools that can help everyone attending a group event contribute and be included. They dive deep into some of the Liberating Structures, such as 1-2-4-All, Drawing Together, Purpose-to-Practice, and TRIZ. Listen to this thoughtful conversation and get ready to apply some of these practices to the next event you facilitate.

Key Takeaways

• Many structures we use with groups, like presentations, status reports, and even tight discussions, tend to fail because they don’t have space for all the participants’ voices or allow members to think “outside the box.” Sometimes, there is even no structure at all. Liberating structures are the tools that liberate everyone in the conversation to contribute and be included.

• We all have different participation styles: thinkers, talkers, and quiet ones. We all communicate in unique manners, and our input is equally valuable.

• There are 33 liberating structures.

• • One Liberating Structure is 1-2-4-All. You can apply it starting with 1: People have time to think on their own. Then 2: They pair up and discuss with another person. Then 4: The pairs will pair, generating themes and sharing what they learn. Finally, All: Where everybody can share their ideas. Even though everyone won’t be allowed to speak to the large group, they had the chance to contribute in the previous instances.

  • Another Liberating Structure is called Drawing Together. Everyone needs to draw a picture using the same shapes (no artistic ability is required). Every shape has a significance: Circles stand for wholeness, rectangles represent support, triangles represent goals, spirals represent changes, and the stick or star persons represent relationships. The group interprets a picture, and these views are the kickstart for a discussion.

  • Purpose-to-Practice is a tool for identifying our main purpose and rooting the members together. It helps realize who must be included to achieve a shared purpose.

  • TRIZ is the liberating structure created to assess the absolute worst scenario that can happen.

• When choosing a liberating structure, you must match it with the problem you are trying to solve in a group.

• • First, you need to frame the problem to find the right tool to approach it.

  • It's a good idea to have a Plan A and a Plan B for facilitation.

• How can you start applying Liberating Structures?

• • When approaching liberating structures, you will first learn what they are for, then how to approach the space, how people participate, groups, and the sequence of steps to be followed. The material also provides time allocations. You will receive minimum specifications of how the liberating structures are set up.

  • There is no specific script about how you should facilitate.

  • Be comfortable doing something uncomfortable and new.

Mentioned in this Episode:

LiberatingStructures.com

Download the Liberating Structures App

The Art of Gathering, by Priya Parker

The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth, by Amy C. Edmondson

Right Kind of Wrong: The Science of Failing Well. by Amy C. Edmondson

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 hosts, Dan Neumann and Justin Thatil, share seven tips for Agile Facilitation. Collaboration is necessary when solving a problem, and Agile Coaches and Masters work to enable a Team to cooperate. Every event is unique, which is why Facilitation could be considered a form of art.

Key Takeaways

• Contextual Awareness:

• • Teams and events are filled with unique variables that the facilitator cannot always anticipate; as a result, reading the overall atmosphere of a room and the individuals’ body language is a fundamental skill for Facilitators.

  • Every Facilitator has to remember that they are facilitating for a specific audience. Who is this meeting for? What is the value for these participants?

• Use Time boxes.

• • A Facilitator must master the flow of the meeting to achieve the goal in a timely manner.

  • A Facilitator should design the session with the intended activities, promote collaboration from collaborators, and be flexible enough to adapt to changes.

• Mastering the act of active listening:

• • Listening is achieved when being fully present.

  • Seek to understand.

  • Facilitators must be able to paraphrase what they just listened to to ensure they understand what the collaborator is saying.

  • Are collaborators listening to each other? A Facilitator must also promote active listening among participants.

• A Facilitator must foster an open and inclusive communication environment.

• • A Facilitator must become a master observer of the room. Who is participating? Who is silent?

• Design a power start!

• • Set the purpose and the intended outcome for the meeting. This will improve participant engagement.

  • Specify how participants can engage.

  • Visual Facilitation tools are incredibly beneficial for a better Facilitation.

• A Facilitator must handle conflict with grace.

• • Conflict is inevitable, especially in a collaborative environment.

  • Participants should be encouraged to learn from each other. Conflicting perspectives must both be validated.

  • A Facilitator must be clear about which behaviors are acceptable. Safe boundaries are essential to hosting a psychologically safe environment.

• Facilitators must continuously improve their skills.

• • Facilitators must apply learnings in a setting first to realize how they can be improved.

  • Pairing with other Facilitators can be a great way to keep learning continuously.

Mentioned in this Episode:

Empowered: Ordinary People, Extraordinary Products (Silicon Valley Product Group), by Marty Cagan and Chris Jones

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, Justin Thatil, welcomes Ned Pope, Director of Product Practice at Agile Thought. In this episode, Ned and Justin explore the most common challenges encountered while engaging with an enterprise client. Ned shares valuable insights regarding creating a new product effectively and timely, emphasizing the crucial value of openness and collaboration within a Team. Ned highlights the importance of focusing on the problem, the elements of the solution, and how they can be broken down to prioritize the most unique and highest value for clients and customers.

Key Takeaways

• Enterprise clients are dealing with a massive sector of the marketplace.

• • There is a wide range of variance in what the clients are trying to accomplish, so it is important to ground them in their thinking around problem-solving. If you can remove even a minor inconvenience from someone's day, you add value to their life.

  • There must be a list of priorities from executive and senior leadership within the enterprise clients, along with the dates they will be needed. This road map is not based on capacity or capability to deliver a solution around a specific item to be delivered at a particular time.

  • Don’t get frustrated when trying to create a digital product. There is a reason this solution doesn’t exist yet, or in the form you are trying to build it.

  • Make sure everyone is aligned and on the same page.

• Understand and respect the current processes within an Organization.

• • The organization has already figured out how to solve the problem in the current fashion, and you do not want to disrupt that but to provide something that makes that process more manageable, enhances that solution, and makes it more effective and scalable.

• There are tangible elements that form a culture.

• • Empower teams to think creatively about a solution.

  • Openness, resourcefulness, and collaboration are critical elements of an Agile Team.

• Move UX design and UI library components as visual references at the beginning of the process to save time and ultimately allow for a better product.

• • We often get to the details and the complexity of the work and then begin to get consumed with all the nuance and intricacy of the daily work, which can lead to overseeing the most basic aspects.

  • Remember, you are building a visual tool!

  • The vast majority of technology has some form of interface, which generates success and speed with quality and accuracy.

  • Provide visual references to align the Team with what you are trying to accomplish and execute. It is recommended that you bring in a highly skilled UX Designer to the heart of the Product Discovery. Don’t wait until the process is in development; the UX designer needs to join the process from the beginning.

  • Use a UI library.

Mentioned in this Episode:

Scaled Agile

Scrum.org

National Academy of Inventors

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, Justin Thatil, is joined by Mike Guiler to explore complementary practices in Scrum. The Scrum Guide intentionally left many open questions for users to adapt and practice flexibility.

In this episode, Justin and Mike outline several practices, such as identifying the product vision, adapting the Kanban Board, and providing visual information regarding the production process. They also discuss the benefits of using Kanban’s lead and cycle time metrics and close this conversation by diving deep into the importance of identifying a shared definition of ready.

Key Takeaways

• Product Vision:

• • Scrum is always about outcomes.

  • How do we find the right outcome to deliver to our customers?

  • • First, we need to be clear about the product vision and what the organization considers a priority.

    • Second, the Team comes up with a plan to achieve that vision, which unlocks an organization's power.

• Adapt a Kanban board.

• • The Kanban board helps to visualize the process at a particular sprint timebox.

  • Many benefits result from visualizing the steps in the Kanban Board.

• Scrum with Kanban:

• • Stop starting and start finishing! Look at what you are doing and implement better Teamwork.

  • Kanban’s lead time and cycle time metrics give an indication of the system's progress and whether it is getting better. The cycle time measures the time it takes an idea since it enters a print backlog until it is delivered to the customer, while the lead time gives more of a system view.

• Find your definition of “ready.”

• • What has to happen to make a product backlog ready?

  • Get to a shared understanding of what is considered ready within a Team.

  • Reduce the ambiguity about what should and shouldn’t be in the product backlog, resulting in a better sprint plan.

Mentioned in this Episode:

Listen to Episodes 277 and 279 of The Agile Coaches Corner.

Scrum with Kanban

Sprint: How to Solve Big Problems and Set New Ideas in Just Five Days, by Jake Knapp

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 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!