Agile Coaches' Corner: Recent Episodes

View Details

This week, your host, Dan Neumann, discusses his perspective on the influence of Artificial Intelligence on Agile Teams. AI has created excitement and great expectations, undoubtedly changing how we perceive work and raising some concerns. In this episode, Dan dives deep into how Generative AI can impact Agile Teams’ work, describing AI’s use in this field and using valuable examples to describe several manners to incorporate AI to ease the work at different stages of an Agile process.

Key Takeaways

• Generative AI, a new thinking partner to Agile Teams:
• There are sensitivities around using the free AI models currently available.
• AI could be considered a great partner in addition to Team Members.
• The definition of done for each project cannot be delegated to AI, since the Team needs to determine the pros and cons, define the goals, and what it means to achieve them.

• Miro AI can be used as a Retrospective partner to examine the retrospective data the Team has been collecting. It can also help provide different ways of facilitating Retrospectives.

• AI is helpful to Delivery Teams in predicting releases.

• Agile Teams can use the Monte Carlo Simulation to predict a Team’s velocity by looking at historical data to create a range of future possibilities.

• Sprint planning could be simpler with the aid of AI.

• An Agile Team can seek AI help to provide other work items that might support the original Sprint Goal, based on the product backlog.

• How can AI assist in dealing with bottlenecks?

• AI can help identify some bottleneck trends based on the existing delivery data.

• AI as a tool for Product Owners and Quality Specialists to identify Acceptance Criteria:

• AI can assist Product Owners and Quality Specialists in defying product backlog Item acceptance criteria.

• To generate new acceptance criteria, test cases can be generated using an AI public tool or a technology ecosystem like Microsoft Copilot.

• Using Microsoft Copilot, a Team can look at the sentiment in which you are engaging with your Teammates.

• By searching the Team’s chat emails, AI can help you anticipate potential issues.

• Ai can provide strategies to tackle a potential social challenge that might be reflected in the Team’s communication.

• AI can use your historical information for risk management.

• AI can help a Team identify risks and develop strategies to solve them or even when to accept those risks since the cost of mitigating them exceeds the Team’s capabilities.

• Agile Teams can use AI for prioritization.

• AI can explore big data, search for information on costs and benefits, and provide useful suggestions for prioritization.

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!

View Details

This week, your host, Dan Neumann, is discussing how to maximize Team autonomy while maintaining accountability within Agile Frameworks. In this episode, Dan defines the importance of autonomy and accountability in Agile. He explains the challenge faced when too much autonomy leads to a lack of accountability while, on the contrary, too much control inhibits innovation and why leaders should prioritize this delicate balance.

Key Takeaways

• What is Autonomy in Agile?
• Autonomy is the ability to self-manage, make decisions, and drive solutions.
• Give Teams the environment and support they need, and trust them to get the job done. Motivated individuals are the key to success!
• A Manager must welcome changing requirements but needs the Team to maintain focus. Remember, a Team must harness change for the customer’s competitive advantage.

• Autonomy benefits Agile teams by making decisions faster and fostering creativity and innovation.

• The Role of Accountability in Agile:

• Accountability in the Agile context means taking ownership of work, meeting commitments, and ensuring transparency.
• An Agile Coach should account for progress toward the desired outcome. When things go wrong, slow, or burst, the coach should explain why it happened, what measures were in place to help prevent it, and what the team can do to prevent the problem from happening again.

• Accountability keeps Teams aligned with business outcomes and stakeholders’ expectations.

• Key Strategies for Balancing Autonomy and Accountability:

• Clearly Defined Outcomes: Focus on the importance of clear goals, shared objectives, and transparency. Teams need freedom to achieve these goals but must stay accountable for delivering them. Tell it, write it, repeat it, and ask others to repeat it.
• Create a Culture of Trust: Trust between leaders and Teams drives autonomy. Trust the Team to make decisions, and they will take accountability for their outcomes.
• Use Agile Metrics Thoughtfully: Discuss key metrics like velocity, burn-down charts, and lead time. Always remember that metrics are tools for learning, not for punishment. Emphasize simplicity as the art of maximizing the amount of work not done.

• Boundary Setting (Guardrails): How Agile coaches and Scrum Masters can establish non-intrusive guardrails (e.g., WIP limits, capacity planning) to ensure teams are free to work without getting lost or overcommitting.

• Leadership’s Role in Supporting Autonomy and Accountability:

• Some Leadership behaviors that empower teams are removing obstacles, giving space for innovation, innovation week, buffer in a Sprint, spikes, training resources, conferences, and coding retreats (among others).
• Agile coaches must highlight the need for regular feedback loops, such as retrospectives, to align accountability without micromanaging.

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!

View Details

This week, Dan Neumann, your host, dives deep into how Managers can support and help their Agile Teams. We often fall into common misconceptions, such as believing that self-managing Teams do not need Functional Managers or finding that the Manager’s role is not well defined, making it difficult to identify how he can assist an Agile Team. In this episode, Dan shares many valuable tips for Managers trying to find the best ways to help an Agile Team.

Key Takeaways

• Tip No.1: Encourage Team Involvement.
• Involve the team in the solution process and respect their expertise and opinions.
• Involving team members in decision-making processes can lead to better

alignment, trust, and quality of solutions.

• Tip No.2: Support Learning and Development.
• Provide time and resources for training and other activities to support the Team’s learning and development needs.

• Give Team members time for training and attending relevant events to increase motivation and performance.

• Tip No.3: Foster a Flexible and Adaptive Mindset.

• Encourage managers to adopt a flexible and adaptive mindset and be open to change and feedback.

• Being adaptable and responsive to changes in the Agile environment has remarkable benefits.

• Tip No.4: Measure and Improve Workflow.

• Identify wasteful activities like handoffs and delays and streamline the flow of value to customers.

• Measuring the total time to deliver customer value and designing an effective workflow can improve Team efficiency.

• Tip No.5: Align Teams with Common Visions and Goals.

• Form networks of teams centered on common customers and products and push decision-making out to the network's edges.

• A Manager should align teams with a shared vision and goals rather than top-down control.

• Tip No.6: Celebrate Successes and Learn from Challenges.

• Celebrate the team's successes and identify root causes for defects or challenges to improve continuously.
• Celebrating achievements and learning from challenges fosters a positive Team culture.

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!

View Details

This week, Dan Neumann welcomes Mike Guiler to explore starting on the right foot and staying aligned during the delivery process. In this episode, Dan discusses the crucial activities that set the stage for a successful project inception. Whether starting a new project or re-initiating an existing one, these activities are essential for aligning your Team, stakeholders, and vision.

Key Takeaways

• Understanding Project Inception:
• Project inception is the initial phase of a project where we lay the groundwork for everything that follows. It’s about understanding the project’s goals, scope, and constraints.

• This phase is critical because it helps ensure that everyone involved clearly understands what the project aims to achieve and how we plan to get there.

• Key Activities in Project Inception:

• Vision and Goals Workshop:

• Gather key stakeholders to define the project’s vision and goals.

• Discuss the desired outcomes and how they align with the organization’s strategic objectives.

• Create a shared understanding of the project’s purpose and success criteria.

• Stakeholder Identification and Analysis:

• Identify all stakeholders on whom the project will impact.

• Analyze their interests, expectations, and potential influence on the project.

• Develop a stakeholder engagement plan to ensure effective communication and collaboration.

• Scope Definition:

• Clearly define the project’s scope, including what is in and out of scope.

• Use techniques like user stories, use cases, and process flows to capture requirements.

• Prioritize requirements based on business value and feasibility.

• Risk Assessment:

• Identify potential risks that could impact the project’s success.

• Assess the likelihood and impact of each risk.

• Develop mitigation strategies to address high-priority risks.

• Team Formation and Roles:

• Assemble the project Team and define roles and responsibilities.

• Ensure that Team members have the necessary skills and expertise.

• Foster a collaborative and supportive Team environment.

• Initial Planning and Roadmap:

• Develop a high-level project plan and roadmap.

• Identify key milestones and deliverables.

• Establish a timeline for the project’s major phases and activities.

• Best Practices and Tips:

• Engage Stakeholders Early and Often:
• Regularly communicate with stakeholders to keep them informed and engaged.

• Use feedback loops to ensure that their needs and concerns are addressed.

• Be Flexible and Adaptable:

• Be prepared to adjust the project plan as new information emerges.

• Embrace change and use it as an opportunity to improve the project.

• Focus on Value Delivery:

• Prioritize activities and deliverables that provide the most value to the organization.
• Continuously evaluate and adjust the project’s direction to maximize value.

Mentioned in this Episode:

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!

View Details

This week, Dan Neumann welcomes Nina Sossamon-Poghe to today’s conversation. Nina has an interesting background as a U.S. gymnast, a News Anchor, and a Corporate Leader with a unique perspective on resilience, mental health, and well-being.

In this episode, Dan and Nina discuss an innovative concept, Excellence Exhaustion, while they define and analyze its significance. Nina also shares the “Resilience Route Navigator,” a framework designed to help high achievers combat Excellence Exhaustion.

Key Takeaways

• What is Excellence Exhaustion?
• Excellent Exhaustion is different from burnout. Nina likes to define burnout as the mental exhaustion resulting from doing the same thing repeatedly.
• Excellence exhaustion is the stress and anxiety experienced by high achievers who are driven to surpass their previous achievements.
• Constantly advancing technology and perpetual connectivity are drivers of Excellence Exhaustion.

• The Symptoms of Excellence Exhaustion are anxiety, mental fatigue, reduced motivation, and diminished productivity.

• The Resilience Route Navigator:

• The Resilience Route Navigator is a framework that helps high achievers combat Excellence Exhaustion through TIPS: Timeline, Isolate the Problem, People, and Story.
• Timeline thinking: This step is needed to acquire perspective. Whatever is happening to you, put it in the timeline of your life; check on the life that came before this moment and all the blank space ahead for the years yet to come. This exercise is also a great way to gain appreciation for all you have done in your journey so far.
• Isolate the Problem: Focus on your current situation and leave the past and the future out. At this stage, the present is the main event; this is the only area in which you can take action.
• People: Who is in this struggle with you? You are not alone. Seek the assistance of others who can assist you in navigating the current situation.
• Story: It is crucial that you choose the words you use to tell the story of what is going on in your life. Narrate the events in the most empowering and optimistic manner.

Mentioned in this Episode:

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!

View Details

This week, your host, Dan Neumann, welcomes Mike Guiler to discuss a recent course on Kanban Essentials they experienced together. By the end of the classes, they encountered a common feeling in some participants: fear of failing. Often, acquiring new knowledge, embarking on a new journey, or using a new tool can trigger insecurities: What could happen if it is not right? Where do I begin?

In this episode, they encourage Agilists to face this first stage of hesitation, analyze the limitations, and consider the best scenarios for using a new tool or enforcing an innovative strategy through implementing Kanban.

Key Takeaways

• Kanban Essentials:
• Agilists might hesitate to incorporate Kanban into their projects for the first time. It is common to feel insecure and doubt whether it is implemented correctly and how effective it would be.

• The whole Team has to take ownership of trying Kanban to solve an existing problem.

• How to start using Kanban?

• Start Kanban with matters you can control.
• Make sure you identify the expected result from implementing Kanban and have a way to measure its effectiveness.
• First, start using Kanban to solve a small problem. After solving it successfully, the Team will earn much more credibility and encouragement to use it to solve a more complicated issue.

• You can start using your personal Kanban board and convince the entire Team to use it for the whole system.

• The Problem of Local Optimization:

• Sometimes, a Team optimizes its work, but this does not translate to the entire organization, resulting in one Team working more effectively when the rest isn’t on the same page.

• There is a need to start small and locally but have the bigger system in mind.

• Make your work visible.

• It is crucial to agree on the definition of used terminology (for example, what does a Team define as “done”?).
• A Team must stop and think about how they are doing what they are doing, and ways to improve it.

Mentioned in this Episode:

Kanban Essentials

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!

View Details

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!

View Details

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!

View Details

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!

View Details

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!

View Details

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!

View Details

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!

View Details

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!

View Details

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!

View Details

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!

View Details

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!

View Details

This week, Justin Thatil, your host, welcomes Mike Guiler and Anitra Pavka. Today, they address the product discovery phase and some of the challenges the engineering Team usually faces while identifying what they will build and which special skills will be required to perform the task effectively. Also in this episode, they explore interviewing techniques and usability testing.

Key Takeaways

• Interviewing users is universally helpful.
• Interviewing users is so important that it should be done every week.
• We need to be informed, and the only way to do this is by talking to the users.
• Before the interview begins, you need to make sure you know what you want to obtain from the conversation. A discussion guide might help to lead an interview and make it more consistent.
• Focus on allowing people to keep on talking.
• Engage in the conversation with active listening skills

• Open-ended questions are ideal for promoting a deep conversation.

• Fall in love with solving the problem and avoid fixating on a particular solution.

• Put an effort into understanding the underlying motivations to solve a particular problem.

• The organizational culture needs to promote the Discovery and Delivery Teams to talk to the customer and get feedback.

• Encourage small experiments that try to address a problem from a different perspective and use a different tool to solve it. If the experiment is successful, the new approach could be applied to other matters.

• Usability testing:

• Was the product easy to learn? Was the user able to get through the product efficiently? Were there errors along the way?
• Search to find out answers to questions about value.
• You can use moderated and unmoderated usability tests to get the feedback the Team seeks.
• Share the findings across the Team. They can influence how they approach the following prototype and evolve the solution.

Mentioned in this Episode:

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 on X (Formerly Twitter) @AgileThought using #AgileThoughtPodcast!

View Details

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!

View Details

This week, Dan Neumann and Justin Thatil are joined by their colleague, Mike Guiler. In this episode, they explore how a Product Manager shifts from just management to leadership and how this transformation influences the role. Dan, Justin, and Mike discuss tools and strategies, including OKRs, Story Mapping, and Hackathons, among others.

Key Takeaways

• Product management must study the market and users, becoming customer-centric and ensuring it is still viable for the business at the same time.

• It takes more than one individual to effectively perform the discovery function. It's a Team effort (Product Designer, Product Owner, and a Technical member).

• Discovery and design sessions are opportunities for Teams to unlock the art of the possible.

• The Team has to learn from rapid feedback while ensuring steps are taken to not hurt organizational reputation.
• A Product Manager must first understand how to help the Team approach a particular problem. A great way is to identify OKRs (Objectives and Key Results) and focus on the target market the Team is going after. Once the Team is aligned, the job can be done.

• A Product Manager sets an objective for the Team and allows them to work autonomously toward reaching it.

• Story Mapping: A Product Manager’s ally on the journey to product discovery.

• Story Mapping is an easy way to frame what the Team is trying to achieve and the tool that might be the most efficient for that purpose.
• Story Mapping can also help identify the target persona for which the Team is building a particular feature.

• There is tremendous value in having the Team involved in Story Mapping and, as a result, immersed in and knowledgeable about the problem at hand.

• Hackathons are a great way to keep a Team motivated.

• Allow the engineers to explore; you will keep them engaged and motivated.

Mentioned in this Episode:

Fall in Love with the Problem, Not the Solution: A Handbook for Entrepreneurs, by Uri Levine

Inspired: How to Create Tech Products Customers Love (Silicon Valley Product Group), by Marty Cagan

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!

View Details

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!

View Details

This week, Dan Neumann and Justin Thatil are joined by Mike Guiler to explore how organizations can better support their managers. In this episode, they discuss two adoption patterns, the grassroots and the top-down approach, and the distinction between being a Manager and a Leader.

Key Takeaways

• The grassroots adoption pattern and the top-down approach in an Agile Organization:
• Grassroots starts at a Team level.

• The top-down approach begins with the boss.

• If an Agile Team is self-managing: What does a Manager do?

• A Manager must decide whether he wants to be just a Manager or a Leader because these are different roles. Leaders set clear objectives; they are not so focused on the daily chores but on the higher business-valued conversations. A Leader cares about how to build the environment.

• A Manager needs to work his way to becoming a Leader and less about assigning tasks to Team members. A leader’s work should come from a mentorship place, sharing his knowledge and experience for the Team to explore (instead of being told what to do).

• An Organization can support a Manager embracing Leadership and becoming a servant leader.

• A Leader evaluates options and consults them with the Team; a leader does not impose practices. Communication is more valuable than processes and tools.
• The organization must have a plan in mind but check first how the Team responds.
• A Leader’s job is to establish the vision, shifting away from the “how.”

• While the Team is busy executing the hypothesis, the Leader is thinking about the next step.

• The Alignment of OKRs is vital for an Organization.

• Ensuring that OKRs match the plans for the product and what the business wants to achieve is fundamental for companies. This way, everyone knows what’s most important.
• How role descriptions are set up (performance reviews, salary adjustments) can influence the leader’s job.

Mentioned in this Episode:

Who Moved My Cheese?, by Spencer Johnson

What Got You Here Won’t Get You There, by Marshall Goldsmith and Mark Reiter

Team of Teams, by General Stanley McChrystal

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!

View Details

This week, Dan Neumann is joined by an external guest: Seth Maust, President and Founder of Five Star Life, an organization that aims to change perceptions of education, sports, and culture. Seth began 20 years ago researching why so many children were dropping out of school because they did not value education and ultimately did not value themselves. Five Star Life focuses on dismantling this root issue by ingraining a different curriculum they created that guides students in developing successful mindsets.

Key Takeaways

• Five Star Life focuses on attacking the root cause of student dropout.
• Children are not motivated to continue their studies because they don’t believe in the current education system.
• A good education teaches students how to think (not what to think).

• A successful life begins with the right mindset.

• Create new habits.

• It is a 28-week investment.
• The Five Star Life system teaches students to think critically.

• The application of the learned knowledge is fundamental.

• Students learn to handle conflict the right way.

• Choose your hard! Ignoring conflict is hard, and confronting conflict is too.

• Motivation is the result of vision.

• What is the first step that you can take to achieve your goal?
• Focus on taking small, incremental steps.
• An excellent way to start is to make an image of what you want to achieve and pin it somewhere you can see it daily.

• First, you must create a vision and then goals, but most of all, you must truly believe it will happen. When you attach emotion to an image, belief is born.

• Everything you are now is the result of subconscious programming.

• Unless you consciously choose to keep developing, you will remain what you are and you will repeat the same cycles.

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!

View Details

This week, your host, Justin Thatil, is joined by three of his colleagues, Mike Guiler, Jim Beale, and Mariano Oliveti.

In this episode, they explore the topic of accountability in Agile Teams and organizations. These four Agilists share their insights and experience on the role of accountability while explaining the value of tools such as OKRs and KPIs and the influence of a true leader in encouraging Teams by involving them in the whole process, trusting them, and enabling them to be self-directed and reliant.

Key Takeaways

• Why is accountability so important? How do we keep accountability in an organization?
• Accountability is needed to identify who will be in charge of each task.
• Accountability should start at the top but needs to be emphasized at all levels of the organization.
• OKR (Objectives and key results) is a goal-setting framework that assists in keeping the Team accountable and provides a way to measure the outcomes.

• KPIs are key performance indicators that also contribute to keeping accountability. KPIs measure a team's performance to ensure they are on track to meet their project objectives.

• Leaders encourage accountability in Teams.

• If a leader is willing to engage with a Team, he will share goals with them and the journey to achieve them.
• Leaders need to value the involvement of every member and encourage self-driven work.
• Keeping people informed of the “why” motivates them, while the “what” will only give them tasks.
• A good leader holds his Team accountable and empowers them to make decisions. Overall, a leader trusts his 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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

This week, Dan Neumann and Justin Thatil are joined by Mariano Oliveti and Erica Menendez to discuss DevOps, mainly how it contributes to creating safety and providing feedback during an Agile product journey.

In this episode, they share their knowledge about how DevOps eases the work and ensures value delivery. Listen to this conversation among Agilists for actionable suggestions and amazing real-life examples of Agile Teams benefiting from DevOps.

Key Takeaways

• The problems DevOps can help to solve:
• DevOps can help solve inefficiencies such as the ones resulting from introducing a lot of bugs into the code or when there is a lack of Team Collaboration.
• DevOps helps to break down the silos.

• DevOps is a real time saver.

• Opportunities that DevOps gives:

• DevOps provides the opportunity for automation, testing early, and keeping a repeatable and reliable process that will work.
• DevOps ensures that, at the end of the day, the result is a product that was built in an efficient way.
• Employees working with DevOps are generally happier and more satisfied with their work, especially when automation makes their tasks easier to achieve and grants them the time to invest in the things that really matter.
• Applying DevOps infrastructure allows us to scale in a repeatable manner.

• DevOps is also a way to find what is wrong even before the customer does.

• Starting with DevOps is free.

• Begin with what you have and grow from there. Big changes are rough!
• The more you work with DevOps, the better you will get at it.

Mentioned in this Episode:

ACF Coaching 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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

This week, Dan Neumann and Justin Thatil are joined by Anitra Pavka, an Agile Coach with vast experience in product ownership and management. In this episode, Anitra discusses the value of prioritizing people in the software development journey and shares ways and strategies to communicate more efficiently among the Team and with users. She also outlines different approaches to engaging better with users to minimize risks and maximize time use.

Key Takeaways

• Anitra emphasizes the importance of being human-centric in software development.
• Always approach people with empathy and compassion.
• Telling stories is a great way to reach people and communicate your message.
• Be curious and open.

• Be aware of who you are building a system for.

• Capture users as a persona with a set of behaviors, goals, and motivations.

• The Team needs to know who the user is.
• The Team then can use its creativity and ideas to meet the needs of those users.

• The whole Team contributes to the conversation.

• Ways to engage with end users:

• What are the end users doing daily to deal with the problem you are looking at solving?
• Interact with people to see what they actually do instead of what they say they do.
• Seek customer feedback sooner than later to reduce risk in the long run.
• Learn to ask the right questions.

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!

View Details

This week, Mariano Oliveti joined Dan Neumann to discuss the importance of continuous learning and growth as an Agile Coach

In this episode, Mariano shares his experience growing as a Coach. Listen to this conversation where Mariano and Dan dive deep into the steps of this incremental journey, which begins with awareness, followed by proficiency, to achieve mastery later.

Key Takeaways

• The first step is identifying how you would like to grow as a coach

• At the beginning of your learning process, ask yourself: How do you intake and process information? What is your learning style?

• The second step is to find the topics that best resonate with you.

• To be an Agile Coach, you must perform specific skills at different levels, such as teaching, mentoring, facilitating, or coaching.

• There are complementary skills that can help you along the journey to becoming an Agile Coach.

• You need to have a good understanding of Agile practices and the Scrum framework.
• Business knowledge is also necessary.

• Be aware of your strengths and your opportunities.

• How can you be intentional about your learning?

• Being intentional is critical to mastering what you do.
• Be honest with yourself about your goals and objectives and how you want to reach them.
• Listening is the primary skill an Agile Coach needs to have.

• Listening internally to how you react to the events around you and finding opportunities to grow.

• Leaning is a journey, be patient with yourself and respect your process.

Mentioned in this Episode:

The 8 Stances of a Scrum Master

ACF Coaching Certification

DevOps Handbook

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!

View Details

This week, Dan Neumann and Justin Thatil are joined by two external guests for Kanban University: Joey Spooner, Vice President for Community Development and Product Management, and Todd Little, Chairman of Kanban University.

In this episode, experts from Kanban University join the podcast to share their expertise with the audience. Listen to this conversation and learn about the trajectory of Kanban University and its fantastic community. Also, they dive into a profound exploration of what Kanban Methodology really is and how it can improve what you are already doing.

Key Takeaways

• What is Kanban?
• Kanban University has been educating a vast community on its method since 2013.
• The Kanban method is often misunderstood. Some significant aspects characterize the Kanban Methodology. It is a way to visualize the workflow, called operational practice. There are also Management Practices, which consist of taking and managing policies effectively in an organization. The practices of collaboration and experimentation are also of crucial importance.
• Kanban can also be used as a complementary practice to Scrum.

• A fundamental principle of the Kanban Methodology is to Start with what you do now. If you have started with Scrum, you can improve it with Kanban. Kanban is fundamentally an approach to improving your process framework; it isn’t a framework itself.

• The Kanban Method vs. the Lean Manufacturing:

• Lean Manufacturing aims to remove uncertainty, which is conceived as a waste.
• Sometimes, uncertainty does not need to be eliminated; it is inherited, and often, it is this uncertainty that brings value.

• Kanban tries to understand knowledge work and its behaviors while still representing the workflow.

• How does Kanban manage the predictability challenge while doing complex work?

• There are three common challenges while working with complex work: Delay, Dependencies, and Dormancies. Every Team needs to explore possible solutions for these challenges.
• Check Team reliability.

• An approach to predictability: Do more and better estimates.

• Advice for Scrum Practitioners starting to use Kanban:

• You can use Kaban on top of what you are doing with Scrum for more efficiency.
• Kanban tools allow Teams to stay focused and deliver consistently.

• Find first what your struggle is at the moment and see how Kanban can help with it.

• Learn to manage resistance to change and get accustomed to constant evolutionary change.

• Learn from the water's capacity for adapting to its environment.
• Agile needs to adapt to culture as much as a culture needs to adapt to Agility.
• Take small steps.
• You have to get your system under control, map it out, and ensure it is not overloaded. If a system is overloaded, it is not predictable.

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!

View Details

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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

This week, Dan Neumann and his co-host Justin Thatil are joined by Hal Hogue, who has transitioned from an Agile Coach position to a Managing role and today shares the features of such a shift.

In this episode, Hal discusses his journey from working with managing engineers to becoming one of them. He mentions the particularities of both of these roles, the overlaps between them, and how these positions can work together to advocate for Agility and fast flow.

Key Takeaways

• What are Agile Coaches?
• The Agile Coach is a leader (just like the Manager).
• Agile Coaches are focused on letting others grow (individuals or Teams).
• Agile Coaches also serve as teachers. Coaches teach the true meaning of being Agile by living the values and principles specified in the Manifesto.

• Agile Coaches are change agents, helping organizations avoid becoming stagnant.

• The manager role is not defined in the Scrum Guide, but that does not mean it cannot exit.

• Manager accountabilities:
• A Manager’s first responsibility is to know about the people part of the Team.
• A Manager needs to know what motivates the Team and their aspirations. It requires a lot of active listening and asking questions. A Manager should set clear expectations and roles for the Team.
• The Team should clearly know the reasons why they do their jobs.
• There is a critical relationship between the Engineering Manager and the Product Owner. These two roles need constant communication, aligning goals not only for the product but also around quality.
• A Manager should not decide things for the Team but should take essential matters to the Team and let them be part of designing the solution by giving them options and tools; this requires a lot of trust in both directions.

• Managers can help with impediment escalation or performance issues.

• The Engineering Manager and Product Owner is a critical relationship, as well as the Manager and Agile Coach or Scrum Master.

• A leader must be a coach and a servant leader for the Team but also for the Product Owner.
• A Coach can help a Manager understand what Agility is, its principles, and its values.

Mentioned in this Episode:

Team Topologies: Organizing Business and Technology Teams for Fast Flow, by Matthew Skelton and Manuel Pais

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!

View Details

This week, Dan Neumann is joined by two AgileThought colleagues, Justin Thatil, the show's cohost, and Lizmeth Rodriguez. They discuss the topic of how to achieve a seamless Value Flow, one of the SAFe principles, and the general importance of flow in a system. These three expert Agilists also assess the differences between Kanban and SAFe, especially regarding their approach to scaling.

Key Takeaways

• Principles of SAFe:
• Make value flow without interruptions.

• Value has to move efficiently from start to finish.

• What are the differences between Kanban and SAFe?

• SAFe is a detailed plan for working with big companies using Agile methods.
• Kanban is a simple way to make work run smoothly and always find ways to do things better.
• Kanban is not as strict as SAFe.

• SAFe and Kanban approach scaling at Agile differently. SAFe is a framework for large-scale Agile adoption, while Kanban is a more flexible methodology that can be adapted to various contexts and scales.

• According to SAFe there are 8 flow accelerators:

• 1. Visualize and limit WIP.
• 1. Address bottlenecks.
• 1. Minimize handoffs and dependencies.
• 1. Get faster feedback.
• 1. Work in smaller batches.
• 1. Reduce queue length.
• 1. Optimize time “in the zone.”
• 1. Remediate legacy policies and practices.

Mentioned in this Episode:

Learn more about Measuring Flow with Flow Metrics

Actionable Agile Metrics for Predictability: An Introduction, Daniel S. Vacanti

The Heart of Business: Leadership Principles for the Next Era of Capitalism, Hubert Joly

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!

View Details

Dive into six rules for managing your product backlog with AgileThought’s Dan Neumann, Justin Thatil, and Mike Cooper. In the episode, Mike Cooper emphasizes the importance of managing expectations in Agile projects. The trio explores the principles of Agile scope management, the value of transparent communication, and the critical role of discipline in Agile success.

1. Analogy for Setting Expectations:

2. Mike Cooper emphasizes the importance of setting real expectations at the beginning of a project.

3. He uses an analogy of buying a dream house but having budget constraints, likening it to building systems with a defined budget and timeframe.

4. Scope Management:

5. The concept of making everything transparent in the portfolio, deciding what's in and what's out.

6. Six rules discussed:

7. Everything goes in the backlog.

8. Prioritize with the client or internal stakeholders.

9. Provide estimates.

10. Maintain transparency.

11. Nurture what's not in scope.

12. Say yes to everything, but place it in the backlog.

13. Importance of Communication:

14. Justin Thatil emphasizes that everything they discuss boils down to different methods of communication.

15. The objective is to know what to build and how to solve the problems they're set to tackle as a team.

16. Reminders for Development Teams:

17. Mike Cooper reiterates the importance of including everything in the backlog.

18. Teams often want to be accommodating, but they need to do so within the framework of the backlog.

19. Cost and Context Switching:

20. Mike Cooper talks about the cost of small adjustments and changes.

21. The accumulation of tiny tasks over time can lead to significant workloads and stressed teams.

22. Discipline in Agile:

23. Mike Cooper and Dan Neumann discuss the misconception that agile means a lack of discipline.

24. They stress that agile requires discipline and that "lazy agile" can be problematic.

25. Continuous Learning:

26. Mike Cooper shares his current read, "A Culture Map" by Erin Meyer, recommended by his boss.

27. The book delves into understanding cultural differences, especially for those working across borders.

View Details

Dive into the intricacies of empowering teams with Justin Thatil, Mariano Oliveti and Erica Menendez. They unravel the ties between trust, psychological safety, and the overarching impact on organizational morale and performance.

Major Discussion Points:

Analogies & Metaphors in Team Dynamics

• Concept of kick-starting a team.
• Driving metaphor: Same route, varying challenges daily.

Trust in Teams

• Importance and fragility of trust.
• Danger of general punitive measures after one team's misstep.

Rules, Guardrails, & Accountability

• Establishment and reassessment after failures.
• Relationship between autonomy, self-accountability, and psychological safety.
• Negative spiral from lack of psychological safety leading to a command-control environment.

Concept of Experimentation

• "Fail fast, cheap, and forward."
• ROI of experimentation and organizational risk tolerance.
• Differences in approach for predictable vs. unpredictable industries.

Journey of Empowerment

• The long process built on trust and time.
• Dynamics of teams slowly evolving as trust develops.

Mentioned in this Episode:

Failing Well with Dr. Amy Edmondson

Listen to Mariano, Erica and Justin in a recent episode! Podcast Ep 249. Coaching vs. Mastering the Details with Mariano Oliveti and Erica Menendez

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!

Share These Tweets!

“Self-Accountability begins with Self Awareness” — Mariano Oliveti

“Empowerment through trust and autonomy takes time” – Erica Menendez

View Details

This week, Dan Neumann is joined by Erica Menendez and Phillip Lisenba to explore the Product Owner’s accountabilities, especially when they are filled by a highly technical professional, and how this can impact the Team’s work in positive and negative ways. They share their own Agile experiences dealing with mature Product Owners and what the Agile and the Scrum framework proposes for these cases.

Key Takeaways

• Challenges and opportunities of dealing with a highly technical Product Owner:
• The Product Owner’s relationship with the Team will determine the extent of the accountabilities on each side.
• A strong Scrum Master can help balance the Team out due to the collaboration of a technical Product Owner who has brought a lot to the table and helped the Team create a solution. The Team and Product Owner working in a psychologically safe environment grow together in constant intercommunication.
• A mature Product Owner helps maintain the balance.
• A very technical Product Owner can be highly prescriptive and fall into the mistake of making highly predictive sprint plans, and, as a result, developers turn more into coders.

• The Product Owner has to be able to transfer some of their knowledge to the Team since they won’t always be there to help them.

• The Scrum Guide remarks that the Product Owner is the “what” person, and the Team is the “how.”

• The entire Scrum Team is accountable for creating a valuable, helpful increment every sprint. The Product Owner is responsible for a backlog that optimizes value, and there could be a dysfunction if the Product Owner is disconnected and can’t contribute as a partner for a valuable sprint plan.
• When the Product Owner and the Team can communicate directly, they can take advantage of everyone’s skills; that way, they can leverage everything the Team brings.
• Everything depends on relationships and communication.

Mentioned in this Episode:

Listen to Podcast Ep 197. Approaching Vacations with an Agile Perspective

Get SAFe certified!

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!

View Details

This week, Dan Neumann is joined by Justin Thatil and Mike Dionne to discuss the topic of Agile assessments. Let’s assume it: No one likes to be assessed since it tends to feel deeply uncomfortable. In this episode, these three colleagues discuss the meaning of an assessment, its purpose (that changes according to different environments), and how to conduct assessments following the Agile methodology.

Key Takeaways

• First: What are you trying to assess?

• Remember that data can be changed and looked at in many different ways (what could be a problem).

• The Assessments at the Scrum Master level are meant to evaluate the current state of a Team.

• Start with a series of questions for a health check: Do you feel you are listened to by a Team? Do you feel you have a voice? Do you feel the Team acknowledges you? Do you feel safe in that environment? If the answer is “Yes” to all four questions on a 1-5 scale, give it a 5. If the answer is affirmative to only a couple of the questions, give it a 3 or 4; if the answer is ‘Yes” to only one, put a 0 or 1.
• This process must be repeated, and you will realize that people answer with varying honesty over time. Over the journey, you will notice how the Team dynamics start to pick up.

• As a result of the assessment, the Scrum Master becomes better informed in his or her role.

• How is the Team performing?

• Velocity isn’t everything! Other parts of the overall assessment can also give a good perspective regarding a Team’s performance.
• Scrum enables problems to surface faster so that they can be addressed quicker.

• Velocity is only suitable for predicting how long it can take to finish a group of backlog items.

• Start with the Team’s identity and move to the things that improve the Team’s performance to reach the goal you had set. After that, find what you want to improve next. Repeat this process once a quarter.

• We can control the process, not necessarily the outcome.
• The whole organization needs to pull in the same direction.

• The Team needs to be willing to participate in the assessment. If the Team feels the measurement is unnecessary or useless, the assessment won’t be used as a tool for improvement, and this metric won’t have the value that it was expected to have.

• Assessments also exist for organizations.

• How long does it take to develop an idea? Does the organization have the ability to improve?

Mentioned in this Episode:

Check this episode: “Jorgen Hesselberg on Data-Driven Continuous Improvement”.

The Tools: 5 Tools to Help You Find Courage, Creativity, and Willpower — and Inspire You to Live Life in Forward Motion, by Phil Stutz and Barry Michels

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!

View Details

This week, Dan Neumann is joined by Phillip Lisenba, Justin Thatil, and Erica Menendez to discuss the particularities of the Business Analyst role in a Scrum Team.

In this episode, they explore the valuable role of a Business Analyst and the crucial role of effective communication among Team members to maximize the efficiency and effectiveness of a Scrum Team.

Key Takeaways

• The Three Scrum Accountabilities:
• The first accountability of the Agile Team is the Scrum Master, whose responsibility is to help the Team form Scrum at the maximum level, providing interaction and coaching.
• The Product Owner is responsible for the backlog’s value, priority, and order.

• The Business Analyst can be considered as one of the Developers on the team.

• Sometimes, the BA fills some of the Product Owner’s accountabilities regarding the backlog.

• For a Healthy Backlog, the Team must know how to split responsibilities properly.
• Every organization is different, sometimes, the BA works with the Team, and the product owner works with the Business and splits responsibilities up.
• In sharing responsibilities, communication is critical.

• Having clarity and alignment about the product goal and the sprint goal is fundamental.

• Developers, Product owners, and Team members working together need structure and boundaries for everyone to accomplish their goals and responsibilities.

• Keep the goodwill! Maintain the culture of communication; you never know when you will have to call up somebody for a favor.

• Take advantage of refinement sessions with the developers to confirm what needs to be changed (as opposed to researching it yourself). Documenting everything is, most of the time, not necessary. It is only necessary to record some stories and some product backlog lines specifically for each goal.

• Communication is a time saver; it prevents unnecessary documentation since developers are already informed about the process and implied accountabilities.
• If people can figure things out by themselves, writing every detail down becomes less of a need.

Mentioned in this Episode:

SAFe: Scale Agile Framework 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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

This week, Dan Neumann is joined by his colleague and host of today’s conversation, Justin Thatil; Justin welcomes Mariano Oliveti and Erica Menendez to discuss a recurrent topic: Coaching versus Mastering the Details.

This episode addresses the complexities of coaching, especially considering the different maturity levels and even diverse areas of expertise within a Team. They also dive deep into the matter of a Scrum Master’s expertise, debating whether or not it is a requirement to perform the role better.

Key Takeaways

• To coach anybody doesn’t necessarily mean you have to be the master of that specific topic, but it could be really beneficial in certain situations.

• Coaching will depend on the maturity of the Team and even in which areas each Team shows more maturity than others.

• Does the Scrum Master need to understand every single detail of the work the Team is doing? Certainly not, but it can help!

• A Scrum Master must need to know a certain type of technology to be able to do the work.
• A Scrum Master needs to show empathy to know the Team’s struggles and identify their challenges.

• The Scrum Master must ensure the Team knows its purpose and how to reach it.

• A Scrum Master is not defined by their technical background.

• A Scrum Master needs to know the details regarding the Agile Methodology but learns with each new client the aspects of that particular business, process, tools, and overall product.

• A Scrum Master encourages a continuous education mindset within the Team.

• When a Team gets better at sharing information about their learning, it indicates a Scrum Master is fostering a psychologically safe environment.
• A Scrum Master models vulnerability for the Team Members to feel safe to practice it, too.

Mentioned in this Episode:

The Scrum Guide

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!

View Details

This week, Dan Neumann welcomes his colleague, Justin Thatil, who hosts today’s episode. Justin is joined by Quincy Jordan and Phillip Lisenba to discuss Executive Coaching. In this episode, they address Executive coaching, its differences and similarities with regular coaching, how it is done, and how it can be encouraged. Listen to this episode, which contains actionable tips for your Agile practice!

Key Takeaways

• Is Executive Coaching the same as regular coaching?
• Both encourage, believe, and help Teams become even greater than they are.
• An Executive Coach must have the business knowledge and the experience that relates to the struggles that the Team deals with. An Executive coach must know how to be a listener, too.
• Continued improvement is an important aspect of Executive Coaching.
• A Coach needs to manage timing and reading the group.
• A coach must tell who is coachable and who isn’t and be curious enough about why someone shows coaching resistance.

• An Executive coach must be adaptable and agile when encountering an opportunity to help the Team and become a better partner and friend to them.

• The mindset of the CEO directly influences the work of an Executive Coach.

• Before intending to coach, you need to invest in creating a relationship with each Team member.

• An Executive Coach should try to help the Team out quickly.

• Goal setting: How to set a vision to lead the Team toward:

• Every leader should have the crisper possible vision.

• Without a vision, people will feel scattered.

• A Team led by an Executive Coach is a place where tough conversations are welcomed.

• Nurturing a positive and healthy culture makes a great contribution to creating a psychologically safe space for a Team to grow.

• An Executive Coach should invite the Team to give him feedback about the areas where he needs to improve.

• Coach whom you can reach, coach whom you can coach, and whom you have access to. Improve that culture!
• ABC: Always Be Coaching and Always Be Coachable.

Mentioned in this Episode:

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!

View Details

This week, your host is Justin Thatil, and he is joined by Michael Guiler and Jim Beale to answer one of the listeners’ questions: What does “good” look like for a Team during a sprint planning, a sprint, a PBI, or a backlog?

In this episode, Justin, Michael, and Jim share functional tips and great examples of what is considered good (and bad) in different crucial Agile moments.

Key Takeaways

• What does “good” look like for sprint planning?
• A good sprint planning starts with a good PBI.
• It needs to state what the desired outcome is clearly.
• Make sure there is plenty of collaboration on the PBI.
• You need to have a healthy backlog.

• Separate some time to look ahead; a fair estimation is needed.

• What does a “bad” sprint planning look like?

• Writing PBIs in sprint planning or the sprint; when you are behind the curve, you are winding them in real-time.

• PBIs are written by the product owner. Or business analyst outside of the Team (working in isolation).

• What does a “good” daily scrum look like?

• It is great when the developer accountabilities start talking to each other.
• A good sprint goal is essential (PBIs align with them).
• Pay attention to where people are directing their comments.
• Remember, this is a Team work where everyone is working collaterally.

Mentioned in this Episode:

Lead without Blame: Building Resilient Learning Teams, by Diana Larsen and Tricia Broderick

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!

View Details

Dan Neumann welcomes Justin Thatil and Mike Guiler to today’s conversation.

This week, they are discussing estimation and sizing in an Agile environment. Both estimation and sizing are essential for Agile teams to plan their work, manage expectations, and adapt to changes in a flexible manner. They promote a collaborative approach to understanding the work ahead, fostering team communication, and enabling the team to provide more accurate forecasts without the rigid limitations of fixed time-based estimates. Listen to this episode for actionable tips and examples of how to best estimate and size for the best interest of Organizations and Teams.

Key Takeaways

• Estimations can be inaccurate sometimes.
• Pressure on the Team can cause the estimations not to be good in predicting the costs of a product.
• Positivity bias can also influence estimations negatively.

• Removing the contingencies does not make the estimation better.

• The key to estimating is taking a project, breaking it down into details, estimating the number of hours, and adding them up.

• All the sequencing and the dependencies are not considered.

• Remember there is a Team working on that project; you can’t take only one member’s speed or ability under consideration, but the idea is to consider the issues the whole Team could confront.

• The estimate process needs to be leveled up.

• Establish a scale so you can evaluate the size of the project and its proper cost.
• Remember to include the contingencies, the unknown.

• Human ability to compare can only be achieved accurately when it is done among two known things.

• Can story points be represented by hours?

• A Team’s data can be normalized to take care of the next estimation.

• Example: I am a product owner, how do I determine the cost of a featured leveled backlog? I have to identify a real value.

• Add up the Featured Leveled Backlog times the Team Velocity, and that will equal the number of sprints, which will lead to a cost.
• Does it need to be faster? Employ more than one Team!

• Ask: How much do you want to spend and how quickly do you want to move?

• Hours: Are they useful for estimation or, on the contrary, are they misleading?

• It depends on the maturity of the Team.
• Justin shares an example of a way to discover the average velocity of a Team.

Mentioned in this Episode:

Story Points — a mathematical perspective, Salman Ali Banani

Intuitive prediction biases and corrective procedures

Lead without Blame: Building Resilient Learning Teams Diana Larsen and Tricia Broderick.

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!

View Details

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!

View Details

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!

View Details

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!

View Details

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!

View Details

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!

View Details

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!

View Details

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!

View Details

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!

View Details

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!

View Details

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!

View Details

This week, Dan Neumann, your host, is joined by Christine Bush. In this episode, Dan and Christine embark on an insightful exploration of Disciplined Agile, a domain in which Christine is certified. They unravel some of the intricacies of Disciplined Agile, addressing its profound impact on organizations.

Throughout the episode, you’ll gain a general understanding of what Disciplined Agile is, learn more about the six distinct life cycles that define this approach, and discover how they contribute to organizational growth and success. Tune in to today’s show and gain valuable insights that will guide your organization on its journey towards continuous improvement and enable you to navigate the ever-evolving landscape of Disciplined Agile.

Key Takeaways

• What is Discipline Agile?
• • It is a tool kit rather than a framework.
  • Discipline Agile meets the organization where it is.
  • Discipline Agile finds the best ways of working for each organization.
• The six life cycles in Disciplined Agile:
• • The Agile Life Cycle: A Scrum-based Project Life Cycle.
  • The Lean Life Cycle: A Kanban-based Project Life Cycle.
  • The Continuous Delivery: Agile Life Cycle.
  • The Continuous Delivery: Lean Life Cycle.
  • The Exploratory (Lean Startup) Life Cycle.
  • The Program Life Cycle for a Team of Teams.
• Within an organization, different life cycles can be used by other business units.
• • Disciplined Agile focuses on: What is the team? What does it need?
• Christine dives deep into the Agile Life Cycle.
• • The work is primarily for organizations looking for enhancements or new features.
  • An Agile Life Cycle allows users to Identify, Prioritize, and Estimate.
• It is essential to analyze your context in Disciplined Agile.
• • The spiral diagram is one tool provided by this tool kit that considers the team size, geographic distribution, compliance needs, and technical and domain complexity.
  • It is necessary to evaluate technical complexity.

Mentioned in this Episode:

Find more about Disciplined Agile at Project Management Institute

Learn about DAC Certification (Disciplined Agile Coach)

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!

View Details

This week, Dan Neumann is joined by his colleague Justin Thatil to explore POWER Start, a great strategy to help you plan, structure, and run your meetings effectively.

In this episode, Dan and Justin dive deep into the structure of POWER Start and the fantastic benefits that result from using it as the most effective tool to make meetings productive and, even sometimes, the way of knowing when an event needs to be canceled.

Key Takeaways

• What is POWER Start?
• • It is a formula that was created to allow people invited to a meeting to have the right frame in order to have a productive session.
  • POWER: Purpose, Outcomes, WIIFM (What is in it for the attendee?), Engagement, and Roles and Responsibilities.
  • POWER start is the formula for the host of the meeting to communicate to the folks who will be attending the event about the most important aspects of it, for example: How is the Team going to be engaging? What is the purpose of the meeting? How they will be contributing to it?
• PURPOSE:
• • Knowing the purpose of the meeting is crucially important, which also lets you know why someone is invited to a particular meeting.
  • Knowing the purpose of a meeting means understanding the reason why people are getting together.
• OUTCOME:
• • The outcome is explicit, and it refers to what could be deliverable.
  • What are we trying to achieve as a result of this meeting?
  • Sharing this information helps the assistants to prepare for it and be able to anticipate what the session will be like.
• WIIFM (What is in it for the attendee?):
• • This section contains the benefit that each of the attendees can expect from a particular meeting.
  • Sometimes there is a concrete reward.
  • It can also be a reminder that there is a bigger purpose to what each of the attendees is doing.
  • You can engage and propose solutions; it goes beyond the idea of being lectured by someone.
• ENGAGEMENT. How does POWER Start engage the participants?
• • The meeting’s host need to puts into practice facilitation techniques.
  • Sometimes staying concentrated is not that simple! Using the proper engagement tools is vital.
• ROLES and RESPONSIBILITIES:
• • What is expected from the attendees of a meeting?
  • A Scrum master is expected to exercise the art of participation so members are encouraged to be engaged in their roles.
• After the meeting:
• • The “after” should be based on the outcome you had set for the meeting.
  • What are the actions that I need to take after the meeting?

Mentioned in this Episode:

The 5 AM Club: Own Your Morning. Elevate Your Life, by Robin Sharma

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

This week, Ola Tunde joins Dan Neumann to explore the innovations on SAFe, which just launched the 6.0 version.

In this episode, they talk about the new features of SAFe 6.0, including new strategic themes. Dan and Ola Tunde dive deep into the benefits and advancements this latest version of SAFe offers Teams and Organizations.

Key Takeaways

• Strategic Themes that SAFe presents:

  • Strengthening the Foundation for Business Agility
  • Empowering the Agile Team even in their responsibilities, giving decision-making authority to the Teams.
  • Accelerating value flow: How does a Team identify the bottlenecks? What is slowing down the value of delivery?
  • Enhancing business agility with SAFe across the business
  • Building the future with AI, Big Data, and Cloud
  • Delivering better outcomes with measure, grow, and OKRs

  • How does machine learning fit into SAFe 6.0?

  • SAFe 6.0 gives exposure to AI.

  • SAFe 6.0 enables and promotes the uses and practices of AI.

  • SAFe 6.0 focuses on measurements on every level before scaling.

  • Velocity is not what we should measure.

  • SAFe 6.0 empowers the Scrum Master but also holds it accountable.
  • A Scrum Master must help with the improvements of Flow by using metrics.
  • A Scrum Master must support the solutions in delivering each iteration.
  • SAFe 6.0 will help organizations hire more quality than hiring bodies.

Mentioned in this Episode:

Become a Professional Scrum Trainer

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!

View Details

This week, Dan Neumann is joined by Mike Guiler to discuss the benefits of Agility, including employee satisfaction, predictable delivery, and speed to market among others.

Key Takeaways:

• Agility leads to employee satisfaction since every Team member is connected to the purpose of the work.
• Sustainable pace is enabled by Agile Methods
• • Agile done well eliminates the “death march”
  • Deliver slices of value
  • Deliver the most valuable items first
  • Agile delivery is not “all-or-nothing,” enabling us to decide what we can release without
• Predictable delivery is mostly assured with Agile, and even when the mark is missed it can be adjusted back in a brief period.
• Reduction of Waste
• • The Increment is inspected frequently
  • We learn from what we deliver
  • You can stop and pivot when going down a path that is not what the customer needs
  • Make change easier
  • Validate assumptions early
• Reduce Risk
• • Don’t build the whole thing before we deliver it
  • Reduce risk by gradually exposing your features to users versus an “all-or-nothing” release
  • Incremental deliveries reduce risk by validating assumptions.
  • You get real customer feedback.
• Speed to Market
• • Deliver the right things, reduce waste, and get a slice delivered!
  • Do not expect that your developers will “code faster”
• Faster Return on Investment
• • Generate revenue with small slices
  • Decide when to stop investing further in a product
• When you decide to transform your business outcomes, you need to consider the benefits you are striving for when you make decisions within your organization. Keep the end goal in mind at all times.
• We want to be efficient instead of effective.
• • Collaboration works wonders; a Team is more resilient and efficient when collaborating.
  • Some people are not ready to work in a Team; they need space and time to gradually start feeling more comfortable with teaming.
  • Scrum is often perceived as having a lot of meetings when in reality, the meetings required are the minimum necessary to keep the Team aligned toward achieving the common purpose.

Mentioned in this Episode:

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, by Nicole Forsgren Ph.D., Jez Humble, and Gene Kim

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!

View Details

This week, Dan Neumann is handing his role as a host to Buyi Kalala and Mike Guiler, who are leading today’s episode. Gerardo DeLaFuente and Eric Lindgren join them to discuss information radiators for leadership.

In this episode, they explore how information radiators influence a Team’s performance and the delivery of value when going from one engagement to the next. They also dive deep into the benefits and challenges of using these tools and list which tools are best, to begin with.

Key Takeaways

• What are some of the best Agile engagement tools?
• • These tools provide excellent visibility of the work in different stages, from conception to delivery. This information will give us a good way of understanding how the Team is performing.
  • Value Generator: Some metrics can be used internally or when you are delivering a system to customers.
  • Sierra and Jira are great tools for the Team to update their work and show different types of progress (a feature, a sprint, a release). These tools require less time to manipulate the data.
  • DevOps.
• How much value are we creating and delivering?
• • One of Agile’s advantages is that all the work can be shown. Using radiator information tools is a great way to obtain feedback and ensure the Team is on the correct path, make a turnover, and apply the necessary changes to adapt.
• Leaders benefit from using engagement tools in several ways.
• • Leaders can decompose the work associated with features epics and highlight when the Team is expected to deliver the value related to the product goal by communicating that through a big information board to communicate with Leaders and Executives; this way, delivery dates can be anticipated.
• How can a Leader explain the facts behind the metrics?
• • First, explain how the tool works (How many sprints at a given velocity?).
  • The number of sprints will increase while more unexpected situations arise in the process.
• What type of information radiators are good to start with?
• • Burn Down chart shows what you have planned for the sprint and the progress towards that goal.
  • Burn Ups Charts can be used at the feature level because it shows the total backlog and the progress toward meeting it (and how much the backlog is growing).
  • Flow Diagrams are used to manage flow stability.
  • DevOps provide the ability to build dashboards that help identify velocity, lead, and cycle time.
• Is there anything that prevents Teams from capturing information within a tool?
• • First, the Team needs to know how to update the information.
  • The Team needs to work with the parameters and make adjustments while advancing the work.
  • The Team has to be self-accountable to make all the necessary changes.
  • Without the complete set of data, you won’t get an accurate anticipation of the upcoming process.
• Explain to the Team why these tools are beneficial.
• • Team members focus on delivering products, which is why they feel administrative work is a burden and a waste of time.
  • Scrum Masters need to be great communicators, explaining to the Team members the reasons to use these tools and also the benefits resulting from using them.

Mentioned in this Episode:

Check articles in Scrum Alliance and Scrum.org.

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!

View Details

This week, Dan Neumann is joined by Buyi‌ ‌Kalala‌ to talk about the Scrum Master role and the misconceptions associated with it.

In this episode, Dan and Buyi address the personality types that seem more effective/successful in the Scrum Master role.

Key Takeaways

• What do Scrum Masters really do?
• • There are a lot of misconceptions regarding the roles of a Scrum Master.
  • A Scrum Master guides Team members to find a more effective way to deliver work, improving what they do and ensuring they follow Agile principles.
  • Teams are diverse, and each Scrum Master is responsible for navigating different cultures, terminologies, and approaches.
  • A Scrum Master must observe the Team when they formulate their plans and go through a daily Scrum, seeing how they deliver value (which could be complicated in a highly remote work environment).
• Personality types, training, and experience that match better with the Scrum Master role.
• • Some great Scrum Masters happened to be teachers in the past, and most are also parents.
  • Experience is as important as certifications for a Scrum Master.
  • The Scrum Master Certification needs to come from a reliable source, but it is just a stepping stone; putting the knowledge into practice is fundamental.
  • There are a lot of ways to deliver value, but there are some practices that certainly benefit the Scrum Master in the implementation of the process.
  • A Scrum Master needs to give to get, this is fully relational, and the foundation to really build a good relationship is trust.
• Diversity enriches a Scrum Master’s work.
• The role of a Scrum Master is all about presenting and delivering value to the Teams and building high-performance forming Teams.

Mentioned in this Episode:

Become a Professional Scrum.org Trainer

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!

View Details

This week, Dan Neumann is joined by his colleague Mike Guiler to talk about Teams. Dan and Mike explore the four types of Team topologies and the three different types of interactions among them. They also dive deep into how to design effective Teams and how to help them grow so they can move at the speed of the customer.

Key Takeaways

• Why is a Team more than just a group of people?
• • Sometimes you can see a collection of people, not really a Team.
  • It is impossible for everyone to talk to everybody; the Team structure supports effective communication.
  • A Team must have the power to make decisions, which is called bounded autonomy. A Team has autonomy and uses its expertise to decide the most appropriate decision at a given time.
  • A Team can choose what it considers the right tool at a particular moment.
• Team Topologies:
• • Four different types of Teams:
  • • Stream-aligned Team: aligned to a flow of work from (usually) a part of the business domain. This type of Team is a lot like a Scrum Team.
    • Enabling Team: enables a Stream-aligned team to overcome impediments and can also notice missing capacities. This Team allows the stream-aligned Team to keep growing.
    • Complicated Subsystem Team: where significant mathematics/calculation/technical expertise is required.
    • Platform Team: a collection of other Team types which provide an exciting internal product to accelerate delivery by Stream-aligned Teams.
• Three different interaction modes between Teams:
• • Collaboration: It is about working together for a designated time to discover new things (APIs, practices, technologies, etc.).
  • X-as-a-Service: Defines the scenario when Team A provides, and Team B consumes something “as a Service.”
  • Facilitation: It happens when a Team helps and mentors another Team.

Mentioned in this Episode:

Team Topologies: Organizing Business and Technology Teams for Fast Flow, by Matthew Skelton and Manuel Pais

“What is a Thinnest Viable Platform (TVP)?”

User Story Mapping: Discover the Whole Story, Build the Right Product, by Jeff Patton and Peter Economy

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!

View Details

In this episode, Eric Landes addresses the challenge of doing Continuous Delivery on a Scrum team. Many teams and organizations struggle with Continuous Delivery, and some think that in a Sprint there can be only one release. Or, they struggle with getting their Increment good enough to be “potentially shippable.” What’s a Scrum Team to do?

Check out our public Scrum training courses if you want to attend Scrum training.

Key Takeaways:

The 2020 Scrum Guide talks about Scrum teams creating multiple increments within one Sprint. Now the Scrum Guide is encouraging frequent releases. Which makes my DevOps-focused heart sing!

What does this mean to your teams? In my opinion, aiming to deliver to production frequently helps your team focus on quality. The Scrum Guide does not specifically say to release to your customer. Potentially shippable is the term, but I encourage teams to aim for customer feedback through frequently releasing to production! If the team makes releasing to Production part of their DoD, they need to figure out what that means in their organization. How do they ensure high quality and safety for the product before it gets to the customer?

For software teams, this would include thinking of automated testing and automated deployments. Teams that adopt these practices include that work when decomposing PBIs into your Sprint plan. This thinking helps the team focus on how they can automate other requirements to meet organization standards and remove bottlenecks to production deployments. For instance, if your organization has compliance policies, your team may be able to automate compliance verification. This can be done using third-party tools, or your team can customize the automation necessary for compliance verification.

Discuss these options within your team. Help team members think outside the box for solutions. For organizations that have gates in place, like a change advisory board (CAB), talk through options that meet the requirements. For example, your CAB requires a list of new features that are being deployed. Use release automation to automatically create release notes and notify CAB members of the notes.

Most of the time, teams object to continuous delivery based on organizational impediments, not technical ones! Keep this in mind as you encourage your Scrum team to self-manage obstacles. Show others in the organization better ways to ensure the quality and safety organizations strive for in production.

Use PBIs to experiment with team members' ideas. As the Product Owner orders an experiment in the backlog and brings it into the Sprint, teams measure the experiment's impact toward continuous delivery. Continue to use the framework to your advantage to achieve Continuous Delivery. This is doable, teams, don't be afraid to use Scrum and Experiment toward Continuous Delivery!

Related to this Episode:

A complete list of the current Scrum Training by AgileThought.

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!

View Details

This week, Dan Neumann is joined by his colleague and friend, Adam Ulery, to talk about product backlogs.

In this episode, Dan and Adam explore the recent patterns showing interesting ways of using Agile terms, as it is an example nowadays that people call product backlogs the source of requirements for the Team, they discuss today the challenges that may arise as a result of this misinterpretation.

Key Takeaways

• What are product backlogs? And why they are not just the source of requirements.
• • A product backlog is a list of all the things that will be needed for product development.
  • If you consider product backlogs the source of requirements, then the only action that can be taken is to deliver them, not leaving any room for creativity or flexibility. No new alternatives seem to be welcomed if “the requirements” are already set.
  • The product backlog often grows when items are added (this is one main distinction from a list of requirements).
• Where’s the commitment point?
• • Adam advises differing that commitment point as far into the future as possible so the Team can make the best decision that they can.
• Don’t forget the learning component.
• • We are building to learn, always trying to learn and to use that knowledge to inform what we do next.
  • We always update our plans based on what we are learning.
• Do Teams have to have a hierarchical structure with epic and features?
• • Adam explains how this became a trend over time.
  • There is a need to organize the work to show to the client, but when encountering unexpected work that needs to be done, it does not need to appear in the user story format since it is simply not valuable.

Mentioned in this Episode:

The Art of Prayer, Kenneth E. Hagin

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!

View Details

This week, Dan Neumann is joined by Quincy Jordan. In this episode, Dan and Quincy discuss the current state of events for the Agile movement, they dive into an insightful discussion about what Agility really means and what the key elements are that make a sustainable transformation to Agile. Quincy and Dan share how Agile works when an organization is true to its principles, follows its manifesto, and embraces its mindset.

Key Takeaways

• Agile impasse point:
• • People are trying to decide whether Agile works or is it just smoke and mirrors.
  • Agile has proven outcomes with many successes across different organizations.
  • Those who truly embrace Agile (its principles, manifesto, and mindset) have reached success.
• Transformation sustainability:
• • Some organizations have undergone a transformation, but without thinking about how things will change due to it.
  • Agile does not work as software you can install.
  • Agile is not cookie-cutter.
• Agile requires collaboration and is also time sensitive.
• • Every generation decides which practices are going to be continued and embraced and which aren’t.
• What happens when people are being “forced” into Agile?
• • The outcome will change according to the environment. Is it a supportive Agile ecosystem?
  • The collaboration of every member is needed for Agile to be successful.
• Some organizations are going to differentiate themselves as a result of Agile really working for them.
• • People realize that Scrum is Agile, but Agile isn’t Scrum. Scrum is just one way, not the only way.
• What does fully Agile actually mean?
• • It is probably just an expression, but it could either follow practices without following the true Agile meaning or without embracing the cultural aspect or behavioral changes.
  • Always keep an iterative approach: Stop and reflect: What type of things do we need to change? What are the tools that could be used that were never tried before? It is essential to keep the retrospect in the Agile transformation, to actually retrospect on the Agile Journey.
• Some collateral Agile benefits:
• • Noticing you have significantly fewer problems than the organization used to have.
  • Noticing there are fewer struggles when people are coming back from vacation.

Mentioned in this Episode:

Coaching for Performance: The Principles and Practice of Coaching and Leadership, by Sir John Whitmore

The Fifth Discipline: The Art & Practice of The Learning Organization, by Peter Senge

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!

View Details

This week’s Trainer Talk is with Olatunde, SAFe Program Consultant (SPC). A student asked about the importance of psychological safety in a scaled agile environment.

If you are interested in attending a training class, please view a list of our public SAFe training classes.

Key Takeaways

So, someone asked me recently, “why do you believe in psychological safety? Why is it important when you're working in an enterprise and have teams of teams?”

My answer is a simple one. Anytime you cannot bring yourself to work and be part of the team, you don't belong in that organization. Anytime your words are not valued, or your feedback is devalued, you have outgrown the organization. The organization might be operating in its winter season while you are operating in your summer season. Or, you might be in the winter season, and the organization is operating in the summer season. Did you get my gist?

Psychological safety means the ability for me to bring myself to work and add value to the organization as the organization adds value to my life. Without psychological safety, there's no trust. Without sociological safety, there's no passion. When you lose passion for what you do, when you lose passion for where you are, it means the organization does not have safety dealing with you. And, you as well don't have the safety to deal with the organization.

However, when you have psychological safety, the passion it brings with it brings innovation. Innovation brings new ideas. Where there are new ideas, it brings growth. Where there is growth, you bring multiple clients.

Psychological safety is important when you're working in an enterprise. When you come to any of my SAFe training, I always take half a day, maybe three hours, to talk about the importance of psychological safety, respect for people, and respect for cultures.

Related to this Episode:

A complete list of the current Agile Training by AgileThought.

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!

View Details

This week, Dan Neumann is joined by his colleague Mike Guiler

In this episode, they answer a listener's question about how they might approach joining a new company. Times of change are exciting and create new possibilities. The next question is: "how might I approach it?"

Mentioned in this Episode:

Team Topologies: Organizing Business and Technology Teams for Fast Flow 

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!

View Details

In this episode, Eric Landes addresses the challenge of getting team members who are inclined to be quiet, reserved, or “introverted” to collaborate for the betterment of the team and the product.

Check out our public Scrum training courses if you want to attend Scrum training.

Key Takeaways:

In the software development world, you may have noticed that many coders tend to be more introverted. If your Scrum team includes many of these personality types, your Scrum events might be quiet.

The Scrum guide does not specifically have anything to say about personality types in the Developer accountability. However, it does say - "The specific skills needed by the Developers are often broad … Developers are always accountable for:

• Creating a plan for the Sprint, the Sprint Backlog;
• Instilling quality by adhering to a Definition of Done;
• Adapting their plan each day toward the Sprint Goal; and,
• Holding each other accountable as professionals."

The fact that developers are accountable for the Sprint plan, and quality speaks to the need for good collaboration. Also, adapting the plan means teammates must speak up when something changes. I believe that good collaboration is needed in Scrum, so I recommend that Scrum masters help self-organizing teams ensure that all voices are heard.

If you have an introverted team, here are some suggestions for helping team members' voices be heard. Use anonymous methods. For instance, have team members use whiteboards to place post-it notes on a board, then read through them. Virtually this could be using a Miro board for a retrospective. Give team members a fixed time to post their notes, then ask for feedback and explanations when needed.

This helps voices be heard, even when they refuse to speak to their own notes. Another method is to have a one-on-one with all team members on a regular basis. Make sure to bring up any items mentioned in the one-on-one in an anonymous way at the appropriate Scrum event.

How do you encourage team members to find their voice in collaboration?

Related to this Episode:

A complete list of the current Scrum Training by AgileThought.

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!

View Details

This week, Dan Neumann is joined by his colleague Andrea Floyd, who is about to start her retirement journey and today is sharing her excitement about this new stage in her life. In this episode, Andrea talks about the many ways in which her life was improved by Agile principles and the framework it provides to face different life scenarios and overcome obstacles.

Key Takeaways

• Different phases of life involve different goals.
• • We wait for different stages in life with different plans.
  • We collect different tools that we expect will be useful in the new phase.
• Don’t forget to show up with curiosity!
• • Ask questions; get inquisitive and curious.
  • Avoid taking things for granted or making assumptions.
• An organization is a living entity that needs to change and adapt.
• • Agile is a more flexible framework that allows learning, pivoting, and adapting without breaking.
• Some scenarios need to be repeated for consistent outcomes, keep in mind the Agile value behind each scenario.
• Change doesn’t have to be a reason not to move forward.
• • Agile offers safety to explore, inviting people to experiment to go through a learning experience, knowing that it is OK not to know everything.
  • Take a moment to inspect a situation and learn from it.

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!

View Details

In this episode, Eric Landes addresses a question he received while training: “How many times should I refine a Product Backlog Item before it’s ready for a Sprint?”

If you are interested in attending Scrum training, check out our public Scrum training courses.

Key Takeaways:

How many times should a team refine a PBI before it is ready for the sprint? The scrum guide talks about refining as an activity and ongoing. So, the answer is that a team should refine backlog items enough so that they understand the item. It is ready when the team says it is, and the PBI can be completed within a sprint.

Here are some activities a scrum team might undertake to refine their backlog item to ready. Your team may have better ways for you. Remember the ongoing activity, but these are some ways to get started.

First, the Product Owner refines the item when first getting the PBI. Whether the PO entered the item or someone else did, some initial details can be entered. The Product Owner talks to people to help clarify what this is solving.

Sometimes this looks like a Product Owner having a feature that is broad in scope. She then decomposes the feature into multiple stories that she thinks solves the problem.

Second, the Product Owner runs the new PBI by the team in a refinement meeting. Giving the rest of the team some information about this new PBI, and getting feedback on their understanding of what is needed. If the team is satisfied with the answers, they might estimate the PBI during this refinement session. But if more clarification is needed, the Product Owner might elect to get more information.

Third, if the Product Owner needs more clarification, they get it, maybe doing research, talking to customers, or whatever is needed to clarify the PBI. After enough gathering enough information -

Fourth - The Product Owner brings refined PBI to the refinement meeting and the team asks any more questions. Hopefully, the team is confident the PBI can be completed within a sprint, and they estimate.

Now the PBI is ready for the sprint.

View Details

This week, Dan Neumann is joined by ChatGPT, a large language model developed by open AI. An AI language model, I'm designed to understand natural language and generate human-like responses to questions and prompts, trained on a vast amount of text data, and have knowledge of a wide range of topics including software development project management and Agile methodology.

ChatGPT shares his expertise and insights with Agile Coaches’ Corner listeners in this episode.

Key Takeaways

● ChatGPT shares what is most valuable for an Agile practitioner.

○ The most valuable thing for an agile practitioner is to embrace the agile mindset, which emphasizes the importance of collaboration, continuous Improvement, and flexibility.

○ Understanding Scrum and Kanban is crucial for Agile practitioners.

○ Ongoing learning is essential for Agile practitioners to stay current on techniques.

● Why can it be difficult for people to adopt an Agile mindset?

○ The agile mindset requires individuals to be open to change and embrace a culture of continuous improvement this means being willing to experiment, take risks and learn from failure.

○ Individuals are required to communicate effectively with others and be willing to share knowledge and expertise; for people who are used to working independently or in silence, this can be a challenging adjustment.

○ It requires focusing on bringing value to the customer/end-user and pivoting quickly in response to changes in requirements.

○ Adopting an Agile Mindset requires self-awareness and a willingness to be open to feedback and critique.

● The fixed mindset trap happens when individuals and organizations focus on what has worked in the past and show resistance to change.

○ To overcome this, people must be ready to look for new ways of thinking and working, willing to take risks, and learn from failure.

● Does science back up the growth mindset?

○ Some argue that the growth mindset concept oversimplifies the complex factors contributing to success. The emphasis on individual effort and motivation may overlook the role of systemic factors, such as social inequality and structural barriers.

○ Despite criticisms, many practitioners and organizations find value in the growth mindset concept as a way to promote learning collaboration and a focus on continuous improvement.

● How can leaders start to embrace the uncertainty that goes into important moments like budgeting, release cycles, and communication?

○ It is essential for leaders to recognize that uncertainty is a natural part of any complex project.

○ Rigid expectations can be counterproductive.

○ Leaders can shift the focus from fixing deliveries to outcomes.

○ A Leader can create a culture of psychological safety and experimentation where Teams can feel confident in taking risks.

● Why does ChatGPT name Scrum as a methodology?

○ Scrum is indeed a framework rather than a methodology.

● Can a Chatbot take the work of humans?

○ ChatGPT cannot fully replace a human since it doesn’t have human experience, empathy, and intuition that a human coach has.

○ Agile requires knowledge of human behavior, group dynamics, and organizational culture.

● Agile is a mindset and a way of thinking about work, it is about embracing uncertainty, continuously learning and improving, and collaborating with others to deliver value to customers.

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!

View Details

This week’s Trainer Talk is with Olatunde, SAFe Program Consultant (SPC). Tunde shares some reflections on how to merge the best of Kanban with the best of Scrum in an approach called “Scrumban.”

Key Takeaways:

Somebody asked me a question. The question was, “why do you need to Implement Scrumban?” First, I always ask, “what do you know about Scrumban?” They think it's a buzzword, a nice-sounding framework. But to answer their question, I've always encouraged them: What do you like about Kanban? They said they loved the transparency. Fantastic. They said they love the implementation of the WIP limits. They love the fact that they can see throughput. Throughput is the amount of work they have completed based on past data. What don't you like about Kanban? They will say, “we don't like that you don't have immediate benefit realization.” Their releases are two months. They don't like the fact that it doesn't have defined roles. They don't like that it is the delivery team, the Kanban team, and then the product owner. Then I pivot. What do you like about Scrum? Well, now they say they like the defined three roles. The Product Owner, the Scrum Master, and the Delivery team, the Scrum Team. They also like transparency and accountability. Well, if you like the best things that you love about Scrum added to the best thing that you love about Kanban, then merge them. Now you have Scrumban.

How do you implement it? Scrum always talks about early validation of working software as our greatest priority. That's principle number one behind the Agile Manifesto. So, for early validation, instead of three months in Kanban, move it to two weeks. Instead of two weeks, move it to three weeks. Instead of three weeks, you can move it to a month. Thirty days. That's it. And then you have backlog refinement. So, practice continuous refinement of your backlog and its priorities. Keep the WIP limit. Keep it. Do you like the Retrospective? Let's add it. You have daily stand-up, which creates daily accountability in Scrumban. You have backlog refinement and continuous refining of the product backlog. You have retrospectives, you'll always find other ways that we can get better. And once a month, always do a demo. Always do a demo to leaders. Always do a demo to stakeholders. And that is some of the biggest benefits of Scrumban. This is the way to go any time you want to merge the benefits of Scrum, plus the transparency and the continuous work-in-process of Kanban. Merge them, then you have Scrumban.

Related to this Episode:

A complete list of the current SAFe Training by AgileThought.

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!

View Details

This week, Dan Neumann is joined by a long-time acquaintance and friend, Tricia Broderick, a leadership advisor and co-author of Lead Without Blame with Diana Larsen.

In this episode, Tricia talks about the book she wrote with Diana, their mission, and the most important messages that are carried in it, such as the true meaning of a Team, the relevancy of collaboration and connection, autonomy, metrics, and much more!

Key Takeaways

• What makes a Team resilient?
• • Collaboration and connection are the foundations of an authentic Agile Team.
  • Online work does not make connecting to others any easier.
• Do the leader’s team connections need to be cared for differently than the lateral connections between team members?
• • Power dynamics don’t have to be formal, it could be someone who the leader greatly respects or who has an influential power.
  • A psychologically safe environment welcomes everyone to express their true selves, even though it is impossible to assure emotional safety for everyone at all times since each Team member is unique.
  • Are you showing up with compassion?
• Bounded autonomy:
• • You cannot empower someone to do something if they don’t have the knowledge or the skills.
  • Trust is required in both directions.
• Information radiators and appropriate use of metrics are the right way of seeing trends.
• • Sometimes metrics are misused; they need to be used carefully.
  • Metrics need to help the team collaborate towards problem-solving and not as weapons.
• A Team doesn’t become one only because it is named that way.
• • A group is not a Team, cooperation isn’t the same as collaboration.
• You are a better leader because you are not perfect, own your mistakes and growth, since they have brought you to the point where you are today.
• • The only way it is impossible is if you stop trying.

Mentioned in this Episode:

Lead without Blame: Building Resilient Learning Teams, by Diana Larsen and Tricia Broderick

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!

View Details

In this episode, Eric Landes addresses a question he received while training: “Should we have more than one ‘Definition of Done?’”

If you are interested in attending Scrum training, check out our public Scrum training courses.

Key Takeaways:

This week, let's talk about the Definition of Done. In one of our classes, we had a question about the Definition of Done. Specifically, how many Definitions of Done can a Scrum Team have? So, I went to the Scrum Guide, and here is what that says:

"The moment a Product Backlog item meets the Definition of Done, an Increment is born."

The guide does not say it meets the sprints Definition of Done or the potentially shippable definition of done. Instead, it states, "the Definition of Done," implying, in my mind, that there is one Definition of Done.

In class, we discussed whether there should be a definition of done for releases, for instance. When some organizations release the software, users need to be trained. Marketing materials might need updating, etc. And I understand that these things need to happen.

Having one DoD would reduce friction for releasing. No waiting for another team to complete work. The Scrum team controls when they can release. High-maturity teams and organizations are designed this way.

But not all organizations are in a place where we can have the Scrum team do everything necessary for release. So the team may have to grow into it. That is ok. Remember where you are headed and make improvements every sprint to put everything necessary for done into your definition.

Related to this Episode:

A complete list of the current Scrum Training by AgileThought.

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!

View Details

This week, Dan Neumann is joined by Ola Tunde, AgileThought’s practice Lead for Agile Transformation and Coaching in Mexico and Costa Rica.

In this episode, Tunde shares his insights about the power of SAFe training. He describes various available courses and the outcomes attendees get SAFe Training.

Key Takeaways

• ● SAFe Training: What is it like?

  • ○ When you assist with SAFe training, there should be three outcomes:
  • 1. Knowledge of real-life applications, 2. You will hear success and failure stories, and 3. Enthusiasm.

  • ● People who attend training often assume that their trainer is the best in the world and knows everything.

  • ○ When people come together, they all learn from each other; the trainer learns from the class, and the participants learn from each other.

  • ● What can a Product Owner expect from a SAFe class?

  • ○ The Product Owner changes its value according to which one has it.

  • ○ If a Product Owner attends a POPM class, they will leave the class knowing how to understand the market. The Product Owner will know the market's strengths, the competitors' strengths, threats, opportunities, and weaknesses (SWOT).
  • ○ We empower Product Owners to understand the market.
  • ○ It is a psychologically safe environment where Product Owners can learn.

  • ● SAFe Advanced Scrum Master Class:

  • ○ This class trains and empowers Scrum Masters to be a master in the market and with their clients, implement change within an enterprise, and collaborate with others at program and team levels.

  • ● Tools a SAFe Scrum Master would learn differently from the tools acquired at a Team Level.

  • ○ SAFe Scrum Master can influence change in an organization.

  • ○ RTE cannot be with the Teams at all times, coaching Product Owners and stakeholders to devise a plan of intent that is reasonable, delivers incremental value, does not constitute a risk, handles the technical data, and dictates what will not be done.
  • ○ PR planning needs the Scrum Master’s help (especially in large organizations).

  • ● Leading SAFe:

  • ○ When attendees leave the class, they should be able to influence their Teams to do backlog refinement by understanding the definition and estimates of the backlog.

  • ○ All SAFe classes include PI planning scenarios with them; they go from training to workshop.

  • ● Virtual classes:

  • ○ Everyone with internet service and a computer should be able to receive the class.

  • ○ Interaction between colleagues during classes is an excellent source of learning.
  • ○ Come hungry and open-hearted to the classes. A closed mouth is not fed.
  • Mentioned in this Episode:
  • Agile Thought Training and Certifications
  • The Leader Who Had No Title: A Modern Fable on Real Success in Business and in Life, by Robin Sharma
  • Want to Learn More or Get in Touch?
  • Visit the website and catch up with all the episodes on AgileThought.com!
  • Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

This week’s Trainer Talk is with Tunde, SAFe Program Consultant (SPC). Tunde shares factors to consider when you are trying to decide if the Scaled Agile Framework is right for your business need.

Key Takeaways:

As a trainer, many people reach out to me and say, “Olatunde, why would you suggest SAFe?” Well, it’s easy:

• Any time you are trying to deliver a large quantity of software into the market
• You need the teams to synchronize and align on what they are delivering
• You want your organization to gain an edge over the competitors in the market!

Finally, if you want your organization to understand the concept of “personas.” In the market that simply means “whom we are building this software for? What are their likes? What are their dislikes? Also, when you have competitors, you know what some of their strengths are, what are some of their weaknesses, what are some of the opportunities and what are some of the threats.

When you have all these criteria in mind, then I would suggest that you go SAFe. SAFe is not for every organization. And every organization is not for SAFe. Nonetheless, I will always suggest SAFe whenever you meet those criteria.

The best time to start your implementation of SAFe in your organization is now! There will never be a perfect time. There will never be a perfect season. You know there will not be. There will never be a perfect budget. Just start. And as you evolve, as you get better, you will start noticing that SAFe has a lot of potentials and a lot of benefits for your organization. So, when in the market, SAFe also has all the benefits that help you gain an edge over the competitors in the market.

Related to this Episode:

A complete list of the current SAFe Training by AgileThought.

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!

View Details

This week, Dan Neumann is joined by an internal colleague, Eric Landes, Professional Scrum Trainer and DevOps Coach at Agile Thought, and Brian Wawok, CEO and Co-founder at Listing Mirror, a multichannel e-commerce management platform.

In this episode, they get together to address a question posted by Brian. Brian has been working with Kanban with his team, they are looking to embrace the Scrum framework and are wondering how this transition would impact the CD.

Key Takeaways

• Brian explains what Listing Mirror is and who its customers are. He shares the reasons why they are trying to transition to the Scrum framework.
• • CD was instrumental in the success of the company.
  • Brian explains the two environments they work with at Listing Mirror (development and production).
  • They started differently, thinking in the minimum amount of process to get the best results.
  • Brian explains why they will never have a QA Team.
• Continuous Delivering in the Scrum framework happens at least once a Sprint.
• • Brian explains how he has been tracking metrics in his company.
  • Brian exemplifies their work at a Sprint review.
• Does doing Scrum means having more meetings?
• • Avoid meeting fatigue by reducing them as much as possible and making them shorter than 30 minutes.

Mentioned in this Episode:

Build: An Unorthodox Guide to Making Things Worth Making, by Tony Fadell

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!

View Details

In this episode, Eric Landes addresses a question about how the Definition of Done impacts Release Planning.

If you are interested in attending Scrum training, check out our public Scrum training courses.

Does the Definition of Done help the PO in Release planning? In a recent class, the idea of how the Definition of Done (DoD) affects a release plan and the Product Owner came up! So, I wanted to walk through what the Scrum Guide says, and impart some practical advice about planning with the DoD.

The scrum guide states that "The moment a Product Backlog item meets the Definition of Done, an Increment is born". Couple this with the Increment guidance, "an increment must be usable", this helps the Product Owner in forecasting when the increment gets in customers’ hands.

The Product Owner uses the team's throughput, or whatever complimentary metric they prefer in their forecasting. Then during Sprint reviews, the Product Owner shows stakeholders forecasts of when features and functionality can be delivered to customers. The Product Owner adjusts forecasts as more learning occurs through each Sprint.

The Definition of Done impacts the Product Owner's forecasts when it does not include quality steps to get the increment to that usable state. Product Owners want actual feedback from customers using the software in the wild, to help guide their goals. The transparency of the Definition of Done can be used by the Product Owner to help move toward a usable Increment.

For instance, if the team needs a compliance review before something can go to production, the Product Owner should ask how the team can include this in the DoD. The Developers might suggest collaborating with the compliance group on automated solutions. This might add some items to the Backlog to get that automation included in the team’s delivery automation. Now that this is in the Definition of Done the Scrum Team is in control of getting the Increment in front of the customer. This is one example of how the Product Owner can use the transparency of the Definition of Done to improve the value they deliver.

Want to Learn More or Get in Touch? I’d love to hear what you think. If you have a question or a comment, please email us at podcast@agilethought.com.

For more information on AgileThought's available courses, go to agilethought.com/services/training-certifications. This information is also available on the page of this podcast. Thanks for listening!

View Details

This week, Dan Neumann is joined by his colleague Quincy Jordan. In today’s episode, they address a fascinating topic: the relationship between Communities of Practice (CoP) and Agile Transformations in an Agile Journey. Quincy shares the components of the typical structure for CoP and its crucial value in an Agile Organization, especially when trying to introduce new ideas and encouraging people to experiment. Dan and Quincy also dive deep into the leadership role in supporting CoP.

Key Takeaways

• An Agile transformation needs to have a level of sustainability to it.
• • Communities of Practice are vital for installing and sustaining an Agile Transformation.
  • A CoP needs to be a structured and intentional group. It needs to be part of the strategy throughout the organization, a mechanism needs to be in place.
• Separate or general communities?
• • It depends on how large the organization is and in which aspect of the Agile Journey each particular organization is.
• How to persuade an organization to invest in a CoP.
• • Sometimes a CoP can be seen as another meeting (on top of many others), which can be a reason for resisting it.
  • Leadership needs to be on board for a successful CoP. A leader has to advocate for the Community of Practice and also has to give permission for people to attend. Leaders must show interest in what happens at the CoP, what people are learning, and how they are experiencing them.
  • A CoP must be a psychologically safe environment.
• What is a typical structure for CoP?
• • Forums: A forum is an event that happens every six weeks.
  • In each Forum, two to three concepts are introduced for people to get familiar with them and understand their benefits and risks. These forums are more of a lecture than a dialogue.
  • In between Forums, there are Core Practice Talks that occur every two to three weeks.
  • Core Practice Talks are a deeper dive into the concepts introduced in the Forums. The Core Practice Talk is where the dialogue takes place, it is a hands-on learning experience.
• CoP are great places to introduce new ideas.
• • A CoP is an excellent place to encourage people to experiment.

Mentioned in this Episode:

Listen to “Communities of Practice with Quincy Jordan” and “Exploring an Experimental Mindset with Adam Ulery”

The Fifth Discipline: The Art & Practice of The Learning Organization, Peter M. Senge

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!

View Details

This week, Dan Neumann is joined by his colleague Eric Landes. Eric is a Professional Scrum Trainer through Scrum.Org.

In this episode, Eric and Dan talk about how Scrum.Org is approaching training. They also dive deep into the classes Agile Thought is offering for Developers, Scrum Teams, Scrum Masters, Product Owners, and Developers to help them improve their skills at the Scrum level.

Key Takeaways

• What does a Scrum.org class look like?
• • Scrum.org offers training thought for adults.
  • While learning the fundamentals of Scrum, the trainees go through an experience.
  • During the exercises, you get to practice Scrum processes.
• Applying professional Scrum for software developers:
• • Scrum for Software developers helps them use their engineering skills in a Scrum framework.
  • Not everyone participating in these classes has technical expertise (but many do).
• APS or Applying Professional Scrum for Software Development?
• • If you are trying to decide between one of these classes, you should first identify your goal.
  • APS will be your best choice if you want to find how a Team works well using Scrum.
  • If you want to know how Scrum uses technical practices in the framework, then the APS-SD is the most suitable option.
• Professional Scrum with Kanban (PSK):
• • Professional Scrum with Kanban is great for Teams who feel stuck.
  • You can try Kanban within the Scrum framework to get your Team to flow and become more predictable.
  • Kanban is a practice that helps bring flow to Scrum Teams.
  • If you are experienced, feel comfortable with Scrum, and have already taken Scrum training, PSK is your recommended training.
• Who would benefit from Scrum.Org training?
• • New people to Scrum should consider APS training as a great place to start to help Teams operate with Scrum.
  • If you are learning independently, this training is a great way to professionalize what you are doing.
• Why should someone consider a Scrum.Org class?
• • Taking courses is the way for most people to learn and get feedback.
  • The insights you can get into training from an experienced instructor are invaluable.
• What does Scrum Training look like?
• • Whiteboard software is used where the Team collaborates.
  • There are both remote and online training.
• Certifications:
• • APS certification qualifies for Professional Scrum Master 1.
  • APS-SD gives you a voucher to take the Professional Scrum Developer 1 Certification.
  • PSK gives you a voucher to take the PSK1 Certification.

Mentioned in this Episode:

Learn more about Agile Thought Training Services

Scrum.Org

Find more about the On-site training in Tampa, Florida, April 25‒26 for APS and 27‒28 for PSK

Industrial DevOps: Nine Principles to Build Better Systems Faster, by Dr. Suzette Johnson and Robin Yeman

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!

View Details

In this episode, Eric Landes addresses a question he received while delivering a class on Applying Professional Scrum. The student was a security specialist and was trying to figure out how Scrum teams handle the work needed to maintain security and compliance.

If you are interested in attending Scrum training, check out our public Scrum training courses.

How Does Security Fit into a Scrum Team? When conducting Scrum training, teams ask about different roles and how they fit on a team that only has developer, Scrum Master, and Product Owner accountabilities. It is a valid question, when I introduce the Scrum framework, it can be confusing how current jobs fit into the Scrum framework accountability.

The good news is that the Scrum framework talks about accountabilities, not job descriptions. So, the writers of the Scrum guide understand that existing job roles are not necessarily supplanted by the accountability. But Scrum does say that your Scrum team needs to be able to complete their work to make it potentially shippable. A student asked how it could be shippable without their security group, InfoSec approving this. This specific organization, had to have a security review before any release could make it to production.

How does the Scrum framework handle these organizational constraints? The Scrum guide says "Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint." And the Scrum team self-manages to make sure they have the right capabilities for the team.

The Scrum guide is lightweight and not very prescriptive as you have probably noticed. I would answer that question using my experience, letting your team self-manage with this information. Practically speaking here are four ways your team could practice that self-management to help with this question:

1. Add someone with security expertise to your team - The team would coordinate with the folks in charge of security to add that skill set to the team. This would involve coordinating when that person would be needed.
2. Have someone knowledge transfer with security people - Similar to number one, by having a security expert work with the team for a sprint or two, knowledge transfer can happen. A team member volunteers to learn, the security folks agree on when this can be done, and now your team has someone with the skills to get those security policies implemented. The security Infosec team can now work with other Scrum teams to help them add these skillsets.
3. Add security policies to your definition of done - Adding security checks to a team’s Definition of Done might help the team by providing guidance as to what can be done. In combination with 4, this might have the least amount of time spent learning for the team.
4. Security gives teams automation to do security checks. - If your security organization is creating automation to validate security issues, your team should use this. So, a conversation or two or more, with the security folks is needed to validate what tools are available for your team. This could be the least intrusive option for your team.

These are 4 options that your team may want to adopt to help with Infosec or security requirements on a Scrum team. Your team may self-manage to a better option for your organization. Discussing what can be done within the team is a great first step!

Want to Learn More or Get in Touch? I’d love to hear what you think. If you have a question or a comment, please email us at podcast@agilethought.com.

For more information on AgileThought's available courses, go to agilethought.com/services/training-certifications. This information is also available on the page of this podcast. Thanks for listening!

From

View Details

This week, Dan Neumann is joined by his colleague and repeated guest, Adam Ulery.

In this episode, Dan and Adam are exploring the true meaning of being Agile, which is often a subject of discussion. Dan recently found the work of two researchers named Corey Baham and Rudy Hirschheim on the theoretical cores of Agile which provides valuable information about the identity of Agile.

Key Takeaways

• What does Agile mean?
• • The four cores of the Theoretical model on Agility in the mentioned research are validity, inspection and adaptation, working collaboratively, and continuous customer involvement.
• Going superficially vs. deeply into Agile:
• • A superficial approach is when people go through the motions or practice Agile behaviors and activities, maybe not fully understanding the reason why they are doing what they are doing or the benefits implied.
  • Going deeper into Agile means seeking a better understanding of the reasons behind your behavior.
• Agility at the Team level:
• • An example of a superficial approach to Agile can be when a person is named the product owner, then he/she gets a list of tasks to do, and maybe even is required to check before doing anything. There are cases when the new product owner also takes on the new role on top of a previous list of accountabilities, resulting in a very superficial approach to the functions.
  • Not going beyond the functions of your role can also be a superficial way to execute a role.
  • A deep way to develop the role is to begin to understand its true purpose and to remove the barriers preventing the achievement of those goals.
  • The whole Team must be aligned when the priorities change.
  • The environment has to add value to the Scrum framework.
  • A tight partner of alignment is discipline; the team has to say no to the things they shouldn’t be working on.
• At the leadership level, the Scrum values have to be deeply understood.
• • Superficially, a leader has a general understanding of Agile, more in terms of a process, another way to manage projects.
  • An Agile Leader has an understanding of Agile as an effective tool to help the organization to achieve the outcomes it wants.
  • An Agile Leader removes the impediments for the Team to exercise the Agile values.
  • The whole Team must be aligned when the priorities change.
• Change isn’t easy.
• • The whole Team must be aligned when the priorities change.
  • To experience great rewards you have to put in the effort and go through the pain.

Mentioned in this Episode:

“Issues, challenges, and a proposed theoretical core of Agile Software Development Research,” by Corey Baham and Rudy Hirschheim

Lead from the Future: How to Turn Visionary Thinking Into Breakthrough Growth, by Mark W. Johnson and Josh Suskewicz

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!

View Details

This week, Dan Neumann is joined by Adam Ulery for the first episode of 2023.

In this episode, they are talking about new beginnings and how they are the perfect opportunity to plan forward and set intentions for the future. Adam and Dan dive deep into the importance of goal setting and how to do it in the most effective way possible.

Key Takeaways

• Goal setting:
• • It is important to set and reset goals when one cycle ends and another begins.
  • Sometimes New Year’s resolutions don’t last long.
  • A key element to achieving goals and being happy with your performance is just being intentional.
  • Even if you don’t achieve the goal, the benefit is the learning opportunities you found through the process.
  • Most of the time, preparing for goal setting is about taking the time to reflect and process your thoughts about what it is that you are trying to achieve.
  • Take action!
  • SMART goals: Specific, Measurable, Achievable, Relevant, and Time-Bound.
• When does a goal need to be reset?
• • Reassess your goals at the end of each cycle.
  • Measure along the way so you know where you are. These metrics are fundamental to knowing where your performance is around the goal.
• How Teams and Individuals can be more effective in reaching their goals:
• • Allocate capacities for each goal.
  • Remember to be intentional about your goals.
  • Team members have to hold each other mutually accountable.
  • Surround yourself with high performers and your performance will elevate as well.

Mentioned in this Episode:

The Way of a Pilgrim and A Pilgrim Continues His Way, Olga Savin

“How agile software development methods reduce work exhaustion: Insights on role perceptions and organizational skills”, Viswanath Venkatesh, James Y. L. Thong, Frank K. Y. Chan, Hartmut Hoehle, and Kai Spohrer

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!

View Details

This week, Dan Neumann is joined by Michael O’Reilly, SVP in IT within the financial services industry.

In this episode, Michael, an avid board game player, shares the similarities between Dungeons and Dragons and potentially the Scrum Framework. Michael and Dan explore this interesting analogy. The entertainment world is huge and very profitable; it is a serious business for a lot of people who are employed in this field. Also, some fun games make work much more entertaining and the learning experience easier.

Key Takeaways

• Scrum has a framework and Dungeons and Dragons has rules and infinite possibilities to take.
• Session Zero in Scrum can have a bad reputation due to how it is characterized. In gaming, it also has similar features.
• • Session zero is showing what we need to do before trying to do it, is this planning step really needed?
• Everyone wants everybody to be successful, but there is this expectation of the role each one plays, the abilities, and how each member contributes. A session in DandD is like the increments of value in Scrum.
• Transparency is always valued in Scrum as well as in any “good” constructed game.
• House rules work for games and Scrum:
• • If you don’t follow certain rules, you are not doing Scrum.
  • Table rules and house rules are like the Team’s working agreements.
• The Dungeon Master has a role that goes beyond the fun and the profits; his role is to arbitrate the rules and facilitate the adventure. What role is that in Scrum?
• • The Scrum Master could be the one facilitating the Scrum values on the Team but it is not quite the same as what a Dungeon Master does.
  • What does it take for a Game master to create a sense of agency? Michael explains how.
• How do you plan for your session/sprint?
• • If you are the Game master, you need to make sure you have the characters there that will be introduced or met.
  • Players can prepare ahead for a game; oftentimes there is homework.
  • Everybody could decide to go one way and then change their minds.
• Safety tools:
• • A lot of games provide safety tools for people to check in with their players while they are going.
  • In Scrum, a Team activity is about sharing what each member can offer and what they need, which is an effective way to clarify what each can bring to the Agile Team and in exchange ask for what is needed.
  • In the game, you attack the problem, not the people. In Scrum it is the same, you address a problem together as a Team to solve the challenges in the way to achieve the goal.
• Fun activities are valuable opportunities to learn.

Mentioned in this Episode:

Improv for Gamers, by Karen Twelves

The Art of Agile Development, by James Shore

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!

View Details

This week, Dan Neumann is joined by Tarik Smajic from Machine Learning Team and by Justin Thatil, an Agile colleague. Justin and Tarik are both Scrum Masters but Tarik’s work is in Artificial Intelligence or Machine learning. In this episode, they explore together with Dan, the differences and similarities between Scrum and AI as well as how they complement each other by sharing valuable case examples.

Key Takeaways

• What makes AI Teams different from the Scrum framework?
• • Scrum helps to reduce complexity, and certainly, machine learning is a very complex subject.
  • Scrum is a way to start establishing norms in AI teams.
  • In the traditional software development life cycle, there are established phases in order to build software and this includes an exploratory aspect.
• It is more than data.
• • We give the client for free only the data that we are willing to give them, but there is even more data that you can think about that in the past was considered waste data.
  • There are patterns that can be found in data, that is why it is called predictive data.
  • We used to want all the data available but we started to figure out that not all that data is needed, and in case it is necessary to synthesize data that has any predictive implication.
• The beautiful dance Scrum proposes:
• • Scrum works by just enabling the particular accountabilities to do their thing, to be empowered to shine in their field of action.
  • Once you stop trying to solve problems using predictive and prescriptive analytics and start understanding where the value lies and where models need to be built.
• Case: A Team faces a product challenge.
• • Let the Team have the time to research (but it can’t be forever).
  • The Team needs to go through one cycle to establish a baseline.
  • It is better if you adopt Scrum, starting from scratch.
• Sprint reviews in AI:
• • The race to the minimum viable product can look like looking at your data asset and learning from it.
  • Tarik shares several examples.
• It is important to establish what the development phases look like while the ideation and intake Team handles the values assessments and figures out what use cases there are; prioritizing them is the product management Team’s work. Then the research aspects follow; you want the engineers to build the pipelines and then do the testing.
• Scrum of Scrums:
• • Tarik shares how they use one Scrum of Scrums on a weekly basis that only lasts 15 minutes.
  • A necessary question to ask during a Scrum of Scrums meeting is: Am I putting anything in anybody elses’ duties?
  • How realistic are the expectations? The meeting produces a forecast of what can happen.
• Application of Scrum in the AI and ML worlds:
• • Tarik shares his experience.
  • Everything in Scrum is iterative.
  • There are three phases of learning something. It takes a while to master things; patience is required.
  • It is OK to bend the rules, you don’t have to do it all by the book.

Mentioned in this Episode:

Link to a previous episode

Getting Things Done: The Art of Stress-Free Productivity, by David Allen

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!

View Details

This week, Agile Santa (Dan Neumann) is the host of the Christmas Special Episode and he is accompanied by a special Elf (Misi Eyetsemitan) and by a fun group of Agile colleagues: Andrea Floyd, Kristan Chavious, Phillip Lisenba, Justin Thatil, Giovani Botarelli, and Olu Soyele.

In this episode, they are making profound Agile wishes for us all.

Key Takeaways

● Misi wishes organizations to find that the answers they are seeking have always been within them.

● Andrea wishes for curiosity for everyone on her Team, a curious perspective promotes learning and growth.

● Olu appreciates the blessings of this year; he shares his gratitude and he wishes his Team to keep on with their continuous learning and expand even more their Agile mindset.

● Kris hopes for everyone to have the courage to be more transparent about what they think without fearing the repercussions that might follow.

○ Experimentation is a better way to encourage people to innovate instead of telling them to do something different.

○ To be innovative you have to be courageous.

○ Innovation grows in a safe environment.

● Philip is thankful for his family and their health, for his work at Agile Thought, and for the opportunities to continuously improve.

○ Philip wishes for more people to adopt Agile Methodologies across the board, not just in their work but also in their personal lives.

● Giovani asks Agile Santa to replace the command and control mindset with a more Agile mindset.

○ Effective communication is the way to spread the Agile way.

● Justin has two wishes, one is for Agilists to be the source of change and growth and for everyone to keep gratitude always in mind.

○ Gratitude changes attitude.

○ As global citizens, we need to be conscious and aware of the impact that social media has on our society and how our view of reality is being altered by it.

Mentioned in this Episode:

How to Stand Up to a Dictator: The Fight for Our Future, Maria Ressa | CEO of Rappler

The age of surveillance capitalism: The Fight for a Human Future at the New Frontier of Power: Barack Obama’s Books of 2019, by Shoshana Zuboff | American author, Harvard professor

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!

View Details

This week, Dan Neumann is joined by Diana Larsen, who has made amazing contributions to the Agile community. She is also the author of Agile Retrospectives: How to Make Good Teams Great and recently published a book called Lead Without Blame: Building Resilient Learning Teams.

In this episode, Diana is talking about leadership, not only in the Agile community but also in the general community. Diana talks about how leaders come in different shapes and sizes and how they can avoid blame and shame in the workplace to reach better efficiency.

Key Takeaways

● Diana talks about Lead Without Blame: Building Resilient Learning Teams.

○ This book is directed not only at the Agile community but at the general public.

○ The mission of this book is to think about how we can improve our systems rather than pointing fingers at Teams or Leaders.

○ This book is meant to be useful (not theoretical) and to help anyone in their day-to-day struggles.

● Leaders come in many shapes.

○ Whatever kind of leadership role someone is filling, there are certain things that need to be understood in order to avoid blame and judgment and ultimately to aim for everybody to be more effective.

● Shame and blame in the workplace:

○ If people see blame happening anywhere, they will spend time trying to prevent being the one that takes the blame, deflecting that energy somewhere else.

○ If people internalize the blame in the workplace then shame follows.

○ We tend to look for people making mistakes instead of trying to find where they are doing well.

● What are some alternatives to the blaming and shaming approach? Purpose, autonomy, and co-intelligence.

○ Leaders can help people learn and develop better skills in blocking blame.

○ Diana talks about the difference in motivation between Teams and individuals

○ Understand why we are doing what we are doing. Does everybody understand the same purpose?

○ Preserve Team autonomy.

○ Co-intelligence: Together as a Team, collectively, we have the skillsets that the Team needs. Lots of leadership and tactical skills are needed in a Team in order for it to be successful.

● How do Retrospectives help to build resiliency in a Team?

○ There are many ways for supporting retrospectives; Diana describes some of them.

Mentioned in this Episode:

Agile Retrospectives: Making Good Teams Great, by Diana Larsen and Esther Derby

Lead Without Blame: Building Resilient Learning Teams, by Diana Larsen and Tricia Broderick

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!

View Details

This week, Dan Neumann is delighted to be joined by a new guest, James Shore, the author of The Art of Agile Development and co-creator of the Agile Fluency Project with Diana Larsen. His contribution is invaluable to the Agile field.

In this episode, James talks about the second edition of The Art of Agile Development, which was published in 2021. This edition is a fully rewritten version that shows the influence of the Agile Fluency Model, including the different zones Agile Teams can occupy, such as Focusing, Delivering, Optimizing, and Strengthening, and practices for Teams to become fluent in each area.

Key Takeaways

● James rewrote The Art of Agile Development for its second edition.

○ He rewrote the book around the ideas of the Agile Fluency Model.

○ It includes updated practices.

○ In the book, you can find out how to influence people to make a change, to try Agile ideas, and even advice when you are in a situation where you are not very Agile.

● What is the Agile Fluency Model?

○ There are four different zones that teams or organizations can occupy: Focusing, Delivering, Optimizing, and Strengthening. A Team can exhibit fluency in any of these zones.

○ A behavior is fluent when you can perform it unconsciously, naturally, as a default behavior.

○ A Team can demonstrate fluency but only the Organization can make it possible.

○ It is not a maturity model, you can be fluent in one of the zones and not the others.

● The Agile Goal:

○ For many organizations, it may be Focusing plus Delivering together.

● James talks about the structure of the book.

○ The first part of the book is about how to introduce Agile ideas.

○ Most of the book is about the practices for the Focus and the Delivery zone.

○ Alternatives and experiences can be found at the end of every practice.

● Learn the rules, break the rules, and then, ignore the rules.

○ After learning the rules you have to experiment because every Agile Team goes through a unique situation and process.

● How long does it take to achieve a level of fluency?

○ It takes time to become fluent.

○ In general, it takes two to six months to reach Focusing fluency. Have under consideration that there is a one-to-four-month period of decrease in performance while people learn.

○ During two to six months, performance will be affected while trying to reach fluency in Delivering in an expected period from three to 20 months.

○ When Optimizing fluency it takes one to two months of performance affectedness and three to nine months for reaching fluency in this area.

○ It takes one or two years to deliver reliably.

○ All these time frames overlap.

Mentioned in this Episode:

Follow James Shore.

Check the second edition of The Art of Agile Development.

Agile Fluency Project

FAST Agile

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!

View Details

This week, Dan Neumann is joined by two of his colleagues, Mike Guiler and Eric Landes,

In this episode, they are answering a listener’s question: Senior Leaders want to measure how Agile they are, which will allow them to demonstrate if they are becoming more Agile. These Leaders are looking for metrics they can use that can show release frequency, show how responsive they are, and allow them to show or measure if what they are releasing is valuable to the customers. They would love to have numbers that they can update at the end of every month if possible. To summarize, this listener wants to know how leaders can explore their agility and see how it changes every month; listen to this episode and find out what Dan, Mike, and Eric have to say.

Key Takeaways

• Metrics and statistics could be made the same.
• • Let’s not try to measure Agile.
  • An Agile transformation is hard work, are you achieving your goals? Measuring things appropriately can be challenging.
  • If the organization identifies a target but there is a lack of safety, those metrics can become manipulated and consequently unreliable.
• Let Teams come up with the right metrics for them.
• How can metrics be useful?
• • A Team wants to move at the speed of its customers, so why not get feedback from customers to know how the Team is doing?
  • Does the Agile transformation have the customer and his needs as a priority? The Team should seek transformation because they want to make the customer’s life better.
• Deployment frequency metrics are necessary.
• DevOps research and assessment metrics:
• • Deployment Frequency: How often an organization successfully releases to production.
  • Lead Time for Changes: The amount of time it takes a commitment to get into production.
  • Change Failure Rate: The percentage of deployments causing a failure in production.
  • Time to Restore Service: How long it takes an organization to recover from a failure in production.
  • Reliability.
• A committed vs an inspirational OKR
• • OKR is a popular management strategy, it defines objectives and tracks results while assisting to create alignment and engagement around measurable goals.
  • For the organization at the Team level, it is important to have OKRs that communicate what we are looking for at a higher level.
• Once a Team starts measuring a thing, do they continue measuring it forever?
• • Is it useful? If it is not, there is no reason for continuing to measure.

Mentioned in this Episode:

Industrial DevOps

Consulting to Team-Based Organizations: An Organizational Design and Learning Approach, by Kay F. Quam

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!

View Details

This week, Dan Neumann is joined by Adam Ulery, Eric Landes, Andrea Floyd, Erica Menendez, and Kris Chavious. In this episode, they are celebrating Thanksgiving by sharing what they are thankful for from an Agile Perspective.

Key Takeaways

• Adam is thankful for the great people he met in the Agile Community and for Dan for making this podcast!
• Andrea is reflecting on the previous year and shows her appreciation for those who show up with curiosity.
• Eric is thankful for being able to coach with two special colleagues.
• Kris stops to appreciate his Agile colleagues, their unique perspectives, and how they teach each other while respecting each other’s opinions.
• Erica is thankful for the Scrum Values, to have them, and to be able to use them in everyday life.

Mentioned in this Episode:

No: The Only Negotiating System You Need for Work and Home, by Jim Camp

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!

View Details

This week, Dan Neumann is joined by his co-worker Ola Tunde. In this episode, Dan and Tunde are addressing a most important topic, which is the matter of learning to ask and identify powerful questions. Knowing how to frame a question correctly can lead to better outcomes; a leader needs to know how to make inspirational questions that will encourage paradigm shifts.

Key Takeaways

• Framing a question correctly can deliver an outcome in three stages: curiosity, discovery, and introspection.
• How can you tell apart a regular and a powerful question?
• • The right question will promote a paradigm shift.
  • Lead by asking inspirational questions to help you reach your goal.
  • Move away from tactical questions and ask inspirational ones, a leader inspires the workers.
  • A powerful question can be the seed to help a worker grow, or reach a discovery from a place of curiosity and knowledge.
• How is a powerful question constructed?
• • Intent, outcome, and empathy should be involved in the act of asking a powerful question.
• Be aware of assumptions that can sneak into the questions that are being asked.
• Remember to test your question first.
• • How would you feel if you were asked the same question?
  • Why are you asking the question? A powerful question is constructed from the heart; ask it because you really care.

Mentioned in this Episode:

Lead Without Blame: Building Resilient Learning Teams, by Diana Larsen and Tricia Broderick

Tunde’s PDF with examples of powerful questions

The Art of Agile Development second edition, by James Shore

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!

View Details

This week, Dan Neumann is joined by Sam Falco to celebrate four years of podcasts. In this episode, Sam, who was a co-founder of the Agile Coach’s Corner Podcast, is talking about some of his experiences throughout his professional journey; he dives deep into various lessons learned and the challenges overcame.

Key Takeaways

• Sam shares the ups and downs in his professional journey:
• • Sam learned not to interfere, but instead to listen and observe.
  • Keeping a curious perspective is always positive.
  • Learn how Teams operate; please avoid jumping in and telling them what “needs to be done.”
  • Learn, as a Scrum Master, how you can affect your Team.
• In a “remote” world, we miss running into somebody.
• • “Can I reach out to you again?” is a good way of staying in touch with people and following up on various topics.
• Some programs are teaching Scrum in a bad way.
• • Scrum Masters should watch and learn from Teams, it takes a lot to be able to be silent.
  • Access your ignorance, you don’t know what the Team has been going through.

Mentioned in this Episode:

Lakota America: A New History of Indigenous Power (The Lamar Series in Western History), Pekka Hamalainen

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!

View Details

This week, Dan Neumann is joined by Sam Falco to celebrate four years of podcasts. In this episode, Sam, who was a co-founder of the Agile Coach’s Corner Podcast, is talking about some of his experiences throughout his professional journey; he dives deep into various lessons learned and the challenges overcame.

Key Takeaways

• Sam shares the ups and downs in his professional journey:
• • Sam learned not to interfere, but instead to listen and observe.
  • Keeping a curious perspective is always positive.
  • Learn how Teams operate; please avoid jumping in and telling them what “needs to be done.”
  • Learn, as a Scrum Master, how you can affect your Team.
• In a “remote” world, we miss running into somebody.
• • “Can I reach out to you again?” is a good way of staying in touch with people and following up on various topics.
• Some programs are teaching Scrum in a bad way.
• • Scrum Masters should watch and learn from Teams, it takes a lot to be able to be silent.
  • Access your ignorance, you don’t know what the Team has been going through.

Mentioned in this Episode:

Lakota America: A New History of Indigenous Power (The Lamar Series in Western History), Pekka Hamalainen

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!

View Details

This week, Dan Neumann is joined by Eric Landes, Andrea Floyd, Alba Uribe, Erica Menendez, and Justin Thatil. In today’s episode, they are celebrating Halloween by talking about some scary good Agile Stories, unlike previous Halloween episodes where the lessons learned after challenges and difficulties were addressed, this time, you will hear about crazy great Agile experiences that are worth sharing.

Key Takeaways

• Do you want to hear something scary? Doing Agile without digital tools!

  • Feel the transformation.
  • Don’t forget what Agile looks like from the interpersonal relationship aspect.
  • Focus on the toolset that you have and your perspective will get wider.
  • Sometimes taking a small step into something that you are uncomfortable with is the beginning of growth.

  • The failing product story:

  • Justin tells the story when after a long time working trying to get a product right and being at the point of almost reaching the so-wanted outcome, the executive Team decides to cancel the project.

  • A Scrum-But Situation:

  • The state of the Team was the scariest at the beginning, there were problems releasing, and they were not finishing on time. This Team was doing Scrum, but poorly. Eric and Dan were part of the engagement part of this Team, they talked with the client, and the outcome was good. The client went beyond what was suggested and better Scrum was starting to happen.

  • When Agility sneaks up on you!

  • Andrea was working with a client, and there was a pause when she stepped away for the client to continue the journey alone, but then she was invited back. When she resumed work with the client she found that a reset had happened; she was asked very basic questions and even doubted if it was Agile that they were really doing. Andrea decided to stay curious and realized the Team was doing great things respecting the principles and practices of Agile, which are very foundational. They were, in fact, mastering Agile!

  • The Team start to self-identify Agile improvements by looking for the what and the why behind what they were doing and the outcomes.

  • Enabling communication and transparency can create a scary amazing effect on a Team.

  • There was an organization that went 100% into Agile, it covered the organization, the Team, and also the physical location. Everything the Team needed was in place, they even have an additional TV to track progress on releases. They worked on the proof of concepts.

  • Scary good collaboration!

  • No one is taking the lead and everyone knows what they need to do. The lead is there to answer questions, it is so scary good when the leader does not know what to do because everyone is doing so great!

Mentioned in this Episode:

Lead without Blame: Building Resilient Learning Teams, Diane Larsen and Tricia Broderick

Agile Retrospectives: Making Good Teams Great, Diane Larsen

The Art of Agile Development, James Shore and Shane Warden

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!

View Details

This week, Dan Neumann is joined by his colleagues Mike Guiler and Justin Thatil to talk about the dopamine and satisfaction that follow after accomplishing a goal; reaching a purpose is very satisfying and can be conquered in and out of the work environment.

In this episode, Dan, Mike, and Justin explore the process of identifying the goal that you want to achieve from a behavioral and an outcome perspective, followed by working towards the objective, to finally arriving at the conquering of the goal and experiencing that rush of excitement we all enjoy so much.

Key Takeaways

• Reaching a goal is a dopamine booster.
• • Firstly, the goal needs to be identified. What are you trying to achieve?
  • Secondly, chose the priorities: what has the most value?
  • Thirdly, you can start working towards achieving that goal. Seeking the next win can be addictive.
• It is important to take a moment to celebrate your victories (even the small wins)!
• • Try to avoid falling into the habit of always looking at what comes next.
  • Reaching a business outcome is a result of the internal satisfaction of a Team that was working towards that goal.
• Seek the satisfaction of the Team; happier people do better work, are more productive, and stick with the organization longer.
• • Happier Team members make customers happier, it just becomes a self-fulfilling loop.
  • If a Team is overworking it will eventually start working less effectively.
• Measure your achievements.
• • Did your plan turn out as expected? Measure that process so you can reproduce that expected outcome.

Mentioned in this Episode:

Sir Arthur Conan Doyle: Complete Works

The Spirit of Kaizen: Creating Lasting Excellence One Small Step at a Time, by Robert Maurer

Agile + DevOps East Conference, November 6-11, 2022. It’s OK to be UnSAFe – Scale Without Using Someone Else’s Framework. Dan Neumann, AgileThought

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!

View Details

This week, Dan Neumann is joined by his colleagues Mike Guiler and Justin Thatil to talk about the dopamine and satisfaction that follow after accomplishing a goal; reaching a purpose is very satisfying and can be conquered in and out of the work environment.

In this episode, Dan, Mike, and Justin explore the process of identifying the goal that you want to achieve from a behavioral and an outcome perspective, followed by working towards the objective, to finally arriving at the conquering of the goal and experiencing that rush of excitement we all enjoy so much.

Key Takeaways

• Reaching a goal is a dopamine booster.
• • Firstly, the goal needs to be identified. What are you trying to achieve?
  • Secondly, chose the priorities: what has the most value?
  • Thirdly, you can start working towards achieving that goal. Seeking the next win can be addictive.
• It is important to take a moment to celebrate your victories (even the small wins)!
• • Try to avoid falling into the habit of always looking at what comes next.
  • Reaching a business outcome is a result of the internal satisfaction of a Team that was working towards that goal.
• Seek the satisfaction of the Team; happier people do better work, are more productive, and stick with the organization longer.
• • Happier Team members make customers happier, it just becomes a self-fulfilling loop.
  • If a Team is overworking it will eventually start working less effectively.
• Measure your achievements.
• • Did your plan turn out as expected? Measure that process so you can reproduce that expected outcome.

Mentioned in this Episode:

Sir Arthur Conan Doyle: Complete Works

The Spirit of Kaizen: Creating Lasting Excellence One Small Step at a Time, by Robert Maurer

Agile + DevOps East Conference, November 6-11, 2022. It’s OK to be UnSAFe – Scale Without Using Someone Else’s Framework. Dan Neumann, AgileThought

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!

View Details

This week, Dan Neumann is talking about the frequent topic that when addressing Agile and Waterfall sometimes seems that it is used as a weapon to keep people away, and to advocate for the usage of one way (Agile or Waterfall) against the other.

In this episode, Dan will explore how to begin a constructive conversation regarding moving forward using Agile or Waterfall when facing a challenge that needs to be overcome.

Key Takeaways

• Agile vs Waterfall
• • When deciding which approach to use, think about what the goals are, and then decide what tactics you will apply.
  • In a complex domain, where is a lot of uncertainty, and collaboration and exploration are needed, Agile will be the most suitable approach.
  • If you need to repeatedly deliver a consistent product, Waterfall is the most efficient approach.
• What is the distinction between project management through an Agile and a Waterfall perspective?
• • Project management has a place in Agile delivery even though in the Scrum framework there is no room for a project manager.
  • Companies have budgets and need the ability to forecast; they need to be able to adjust as learning happens, so thinking about how a project gets managed in an Agile ROAM is relevant. Don’t fall into thinking that project management is only a Waterfall approach.
• Situations where coaches and Scrum Masters enter into an organization.
• • Check where people are before trying to “fix them.”
  • Try to understand what is happening in the environment first.
  • Be curious about the structure and how effective it is.

Mentioned in this Episode:

Release Train Engineer

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!

View Details

This week, Dan Neumann is talking about the frequent topic that when addressing Agile and Waterfall sometimes seems that it is used as a weapon to keep people away, and to advocate for the usage of one way (Agile or Waterfall) against the other.

In this episode, Dan will explore how to begin a constructive conversation regarding moving forward using Agile or Waterfall when facing a challenge that needs to be overcome.

Key Takeaways

• Agile vs Waterfall
• • When deciding which approach to use, think about what the goals are, and then decide what tactics you will apply.
  • In a complex domain, where is a lot of uncertainty, and collaboration and exploration are needed, Agile will be the most suitable approach.
  • If you need to repeatedly deliver a consistent product, Waterfall is the most efficient approach.
• What is the distinction between project management through an Agile and a Waterfall perspective?
• • Project management has a place in Agile delivery even though in the Scrum framework there is no room for a project manager.
  • Companies have budgets and need the ability to forecast; they need to be able to adjust as learning happens, so thinking about how a project gets managed in an Agile ROAM is relevant. Don’t fall into thinking that project management is only a Waterfall approach.
• Situations where coaches and Scrum Masters enter into an organization.
• • Check where people are before trying to “fix them.”
  • Try to understand what is happening in the environment first.
  • Be curious about the structure and how effective it is.

Mentioned in this Episode:

Release Train Engineer

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!

View Details

This week, Dan Neumann is joined by Adam Ulery to discuss the topic of accountability. In this episode, they address the concept of accountability that could sometimes be misunderstood and even carries some misconceptions.

Adam and Dan talk today about how leaders can foster accountability in organizations and which practices are the most effective to support this work. During this insightful conversation, they dive deep into the meaning and extends of ownership, setting clear expectations, and the value of honoring vulnerability as a necessary exercise to avoid the fear of making mistakes.

Key Takeaways

• Is accountability negative?
• • Many people treat the concept of accountability as if it is negative, but it actually is very positive, once it is experienced in a high-performing Team.
  • Accountability can be disguised in blame in some unhealthy Team environments.
  • Fear in an organization makes it hard for it to foster accountability.
  • Fearing failure is counterproductive since making mistakes is the way for humans to grow.
  • Making a good decision doesn’t necessarily lead to a good outcome and sometimes bad decisions end up in a good result.
• Accountability is ownership.
• • Owning your decisions and part in the decision-making is showing accountability.
  • Accountability is to be willing to face the consequences that come with the outcome, success or failure.
  • Accountability is also doing what you said you would do.
• Leaders must model accountability.
• • Leaders must be honest with themselves and be vulnerable in order to encourage those behaviors in others.
  • Leaders can increase the level of accountability in an organization by empowering people to succeed, giving them the resources they need, expecting them to take action, and then making it safe for them to make mistakes.
• Can people negotiate what can they be accountable for?
• • It is important to communicate expectations clearly in order to align people with them.
  • Open communication is vital since it allows a mutual understanding of where ownership begins and where it ends.
• The SBI Model is great to build accountability.
• • The SBI model is one of the most effective to provide positive and negative feedback.
  • Saying how something made you feel is a way of modeling vulnerability.

Mentioned in this Episode:

Thinking in Bets: Making Smarter Decisions When You Don’t Have All the Facts, by Annie Duke

SBI Model

Listen to Episode 35 for more about the SBI Model

Leading Change, John P. Kotter

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!

View Details

This week, Dan Neumann is joined by Adam Ulery to discuss the topic of accountability. In this episode, they address the concept of accountability that could sometimes be misunderstood and even carries some misconceptions.

Adam and Dan talk today about how leaders can foster accountability in organizations and which practices are the most effective to support this work. During this insightful conversation, they dive deep into the meaning and extends of ownership, setting clear expectations, and the value of honoring vulnerability as a necessary exercise to avoid the fear of making mistakes.

Key Takeaways

• Is accountability negative?
• • Many people treat the concept of accountability as if it is negative, but it actually is very positive, once it is experienced in a high-performing Team.
  • Accountability can be disguised in blame in some unhealthy Team environments.
  • Fear in an organization makes it hard for it to foster accountability.
  • Fearing failure is counterproductive since making mistakes is the way for humans to grow.
  • Making a good decision doesn’t necessarily lead to a good outcome and sometimes bad decisions end up in a good result.
• Accountability is ownership.
• • Owning your decisions and part in the decision-making is showing accountability.
  • Accountability is to be willing to face the consequences that come with the outcome, success or failure.
  • Accountability is also doing what you said you would do.
• Leaders must model accountability.
• • Leaders must be honest with themselves and be vulnerable in order to encourage those behaviors in others.
  • Leaders can increase the level of accountability in an organization by empowering people to succeed, giving them the resources they need, expecting them to take action, and then making it safe for them to make mistakes.
• Can people negotiate what can they be accountable for?
• • It is important to communicate expectations clearly in order to align people with them.
  • Open communication is vital since it allows a mutual understanding of where ownership begins and where it ends.
• The SBI Model is great to build accountability.
• • The SBI model is one of the most effective to provide positive and negative feedback.
  • Saying how something made you feel is a way of modeling vulnerability.

Mentioned in this Episode:

Thinking in Bets: Making Smarter Decisions When You Don’t Have All the Facts, by Annie Duke

SBI Model

Listen to Episode 35 for more about the SBI Model

Leading Change, John P. Kotter

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!

View Details

This week, Dan Neumann is joined by two of his colleagues, Erica Menendez and Justin Thatil, to talk about the intersection between Professional and Agile Coaching as well as their differences and similarities.

In this episode, Justin shares his knowledge that comes from his own experience in the field of Professional Coaching that started 10 years ago. Dan, Erika, and Justin also explore the particularities of each role, the Agile and the Professional Coach, while exploring real-life scenarios and sharing powerful examples to illustrate both roles.

Key Takeaways

• Professional Coaching:
• • It is about guiding someone towards the results they are looking for by asking powerful questions.
  • The coachee's agenda must be the single guiding light of the coaching relationship. The coach’s experience has to stay aside (this is one of the biggest differences between an Agile and a Professional Coach).
  • The coachees need to be inspired to take the next step and be accountable for that move.
  • The arc of a conversation has a beginning, a middle, and an end. The beginning is to identify who you are going to be coaching, and then identify the subject that will be addressed. After that, the situation must be examined and explored (this takes place in the middle of the conversation). Towards the end of the conversation, the coachee must commit to taking a step and become accountable for what is going to happen next.
• Agile Coaching:
• • The coach’s agenda must be laid to guide the coachee to use Agile well.
  • Facilitation comes along with a Scrum Master’s work.
  • As an Agile Coach there are numerous stances that you can take: the consultant, coach, counselor, change agent, facilitator, trainer, lean leader, and mentor.
  • An Agile Coach is an expert in Agility, not in the coachee’s domain.

Mentioned in this Episode:

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, by Lyssa Adkins

What is an Agile Coach?

Powerful Questions

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!

View Details

This week, Dan Neumann is joined by two of his colleagues, Erica Menendez and Justin Thatil, to talk about the intersection between Professional and Agile Coaching as well as their differences and similarities.

In this episode, Justin shares his knowledge that comes from his own experience in the field of Professional Coaching that started 10 years ago. Dan, Erika, and Justin also explore the particularities of each role, the Agile and the Professional Coach, while exploring real-life scenarios and sharing powerful examples to illustrate both roles.

Key Takeaways

• Professional Coaching:
• • It is about guiding someone towards the results they are looking for by asking powerful questions.
  • The coachee's agenda must be the single guiding light of the coaching relationship. The coach’s experience has to stay aside (this is one of the biggest differences between an Agile and a Professional Coach).
  • The coachees need to be inspired to take the next step and be accountable for that move.
  • The arc of a conversation has a beginning, a middle, and an end. The beginning is to identify who you are going to be coaching, and then identify the subject that will be addressed. After that, the situation must be examined and explored (this takes place in the middle of the conversation). Towards the end of the conversation, the coachee must commit to taking a step and become accountable for what is going to happen next.
• Agile Coaching:
• • The coach’s agenda must be laid to guide the coachee to use Agile well.
  • Facilitation comes along with a Scrum Master’s work.
  • As an Agile Coach there are numerous stances that you can take: the consultant, coach, counselor, change agent, facilitator, trainer, lean leader, and mentor.
  • An Agile Coach is an expert in Agility, not in the coachee’s domain.

Mentioned in this Episode:

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, by Lyssa Adkins

What is an Agile Coach?

Powerful Questions

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!

View Details

This week, Dan Neumann is joined by Patricia Kong in today’s episode. Patricia is the Product Owner, Enterprise Agility, and Learning Enablement for Scrum.Org.

In this episode, Dan and Patricia are exploring a new training class Scrum is offering called Professional Scrum Facilitation Skills Training which is directed not just to Scrum Masters but for all levels including all leaders and Team members too.

Key Takeaways

• What is Learning Enablement?
• • It is the place to improve your profile and skills by learning from the experiences of the individuals who are actually doing the work.
  • Learning enablement is directed at people who are really looking to develop people and Teams, specifically improving some of their own skills so they can help others.
• What is the Professional Scrum Facilitation Skills Training about?
• • Professional Scrum Facilitation Skills is an interactive course designed to help Scrum practitioners develop a facilitator’s mindset and proficiency in facilitation skills, and learn when and how to select effective techniques for various circumstances.
  • This class takes all real-life scenarios to help Scrum Masters facilitate the solutions that Teams need to get to agreements.
  • This course includes the five principles for facilitation.
  • The target of this course is for individuals on a Scrum Team but it could be great also for people in management roles.
  • The training takes one day (equivalent to 8 hours) which includes some in-person and some virtual experiences.
• The matter of meetings...
• • Most leaders think their meetings are great (when they are not).
  • The purpose of the meeting needs to be clear, and the meeting should be avoided if the content could be in an email or a video.
  • Facilitation skills are useful when nobody is providing feedback or they don’t even show up to the meeting.
• Conflict isn’t bad!
• • If you are in a creative space, there will be conflict, since different members will come up with different ideas.

Mentioned in this Episode:

Scrum.Org

Professional Scrum Facilitation Skills™

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!

View Details

This week, Dan Neumann is joined by Patricia Kong in today’s episode. Patricia is the Product Owner, Enterprise Agility, and Learning Enablement for Scrum.Org.

In this episode, Dan and Patricia are exploring a new training class Scrum is offering called Professional Scrum Facilitation Skills Training which is directed not just to Scrum Masters but for all levels including all leaders and Team members too.

Key Takeaways

• What is Learning Enablement?
• • It is the place to improve your profile and skills by learning from the experiences of the individuals who are actually doing the work.
  • Learning enablement is directed at people who are really looking to develop people and Teams, specifically improving some of their own skills so they can help others.
• What is the Professional Scrum Facilitation Skills Training about?
• • Professional Scrum Facilitation Skills is an interactive course designed to help Scrum practitioners develop a facilitator’s mindset and proficiency in facilitation skills, and learn when and how to select effective techniques for various circumstances.
  • This class takes all real-life scenarios to help Scrum Masters facilitate the solutions that Teams need to get to agreements.
  • This course includes the five principles for facilitation.
  • The target of this course is for individuals on a Scrum Team but it could be great also for people in management roles.
  • The training takes one day (equivalent to 8 hours) which includes some in-person and some virtual experiences.
• The matter of meetings...
• • Most leaders think their meetings are great (when they are not).
  • The purpose of the meeting needs to be clear, and the meeting should be avoided if the content could be in an email or a video.
  • Facilitation skills are useful when nobody is providing feedback or they don’t even show up to the meeting.
• Conflict isn’t bad!
• • If you are in a creative space, there will be conflict, since different members will come up with different ideas.

Mentioned in this Episode:

Scrum.Org

Professional Scrum Facilitation Skills™

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!

View Details

This week, Dan Neumann is joined by two of his colleagues Erica Menendez and Justin Thatil to today’s episode.

This time, they are exploring the scenario when Scrum Masters enter a New Team, an event that Dan, Erica, and Justin know by experience. Listen to this episode to hear valuable real-life examples of how a Scrum Master can successfully transition into a new Team.

Key Takeaways

• Duties that a Scrum Master needs to attend to when entering a new Team:

  • A Scrum Master must establish his credibility, meet the Team, and create relationships with its members.
  • Entering a new Team is different every time.
  • A Scrum Master should observe and learn about the new Team he is joining, before attempting to start dictating. How much do Team members know about Scrum and Agile?
  • Understand why the organization wants you on that Team.
  • After knowing the Team, the Scrum Master needs to devise a plan to tackle the Team’s needs.
  • Stay curious (rather than judgemental).

  • What does improvement look like for the organization?

  • A Scrum Master needs to explore communication styles within the new Team and identify the organization’s expectations not only about the Scrum Master’s performance but also about the Team.

  • Is it helpful to have someone helping the Scrum Master transition to a new Team?

  • Everyone is different, someone might notice aspects that another person didn’t.

  • Sometimes it is better not to be influenced by someone else’s experiences or understanding of a particular member or a Team’s dynamics; a new approach brings a new perspective that can be beneficial for the Team.

Mentioned in this Episode:

The Scrum Fieldbook: A Master Class on Accelerating Performance, Getting Results, and Defining the Future, by J.J. Sutherland

Man Enough: Undefining My Masculinity, by Justin Baldoni

The Wayback Machine

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!

View Details

This week, Dan Neumann is joined by two of his colleagues Erica Menendez and Justin Thatil to today’s episode.

This time, they are exploring the scenario when Scrum Masters enter a New Team, an event that Dan, Erica, and Justin know by experience. Listen to this episode to hear valuable real-life examples of how a Scrum Master can successfully transition into a new Team.

Key Takeaways

• Duties that a Scrum Master needs to attend to when entering a new Team:

  • A Scrum Master must establish his credibility, meet the Team, and create relationships with its members.
  • Entering a new Team is different every time.
  • A Scrum Master should observe and learn about the new Team he is joining, before attempting to start dictating. How much do Team members know about Scrum and Agile?
  • Understand why the organization wants you on that Team.
  • After knowing the Team, the Scrum Master needs to devise a plan to tackle the Team’s needs.
  • Stay curious (rather than judgemental).

  • What does improvement look like for the organization?

  • A Scrum Master needs to explore communication styles within the new Team and identify the organization’s expectations not only about the Scrum Master’s performance but also about the Team.

  • Is it helpful to have someone helping the Scrum Master transition to a new Team?

  • Everyone is different, someone might notice aspects that another person didn’t.

  • Sometimes it is better not to be influenced by someone else’s experiences or understanding of a particular member or a Team’s dynamics; a new approach brings a new perspective that can be beneficial for the Team.

Mentioned in this Episode:

The Scrum Fieldbook: A Master Class on Accelerating Performance, Getting Results, and Defining the Future, by J.J. Sutherland

Man Enough: Undefining My Masculinity, by Justin Baldoni

The Wayback Machine

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!

View Details

This week, Dan Neumann welcomes you to celebrate episode number 200! The Agile Coaches’ Corner Podcast began back in 2018 and the journey continues! During these years there were many guests, an increasing amount of listeners, and numerous Agile topics were explored. Thank you for being part of these first 200 shows!

In this episode, Dan is exploring a typical situation: Trying to explain the benefits of the Agile ways to someone who is not immersed in the Agile field. Referring to the Agile principles, values, or even the Agile Manifesto won’t help stakeholders. Listen to this episode and learn to communicate how Agile can help an organization to meet its needs (without mentioning the word Agile!)

Key Takeaways

• It can be challenging to communicate the benefits of using Agile to stakeholders not referring to Agile.
• If you are operating in an area of high uncertainty (or a complex environment) Scrum is the answer.
• • The Scrum framework works to deliver increments every sprint, and by receiving feedback to make sure the product developed works and meets the definition of done. This helps to have more certainty and get closer to a solution for the customer.
  • The Scrum Framework is a great assistance in reducing risks.
• When working with an organization in helping them to be more effective, you need to understand what “effective” looks like for them.
• • First, you need to know what is valuable for the organization in order to help them along the journey of becoming more effective.
  • Beginning with the end in mind helps you learn what is important and form tactics and strategies needed to assist an organization in a better way.
• Dan talks about the presentation he will do at The Agile + DevOps East Festival: It is OK to be unsafe: Scaling without using somebody else’s framework.
• • Dan will talk in this presentation about what needs to be explored in order to help an organization meet its needs, and choose the strategies and tactics that make more sense in that specific context (Scrum is a great framework but it might not be the right for everyone).

Mentioned in this Episode:

Listen to Agile Coaches’ Corner’s most popular show: What is Agile?

No: The Only Negotiating System You Need for Work and Home, by Jim Camp

Begin With the End in Mind: Habit 2 of The 7 Habits of Highly Effective People, by Stephen Covey

Find more about The Agile + DevOps East Festival

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!

Contact Dan Neumann on Twitter.

View Details

This week, Dan Neumann welcomes you to celebrate episode number 200! The Agile Coaches’ Corner Podcast began back in 2018 and the journey continues! During these years there were many guests, an increasing amount of listeners, and numerous Agile topics were explored. Thank you for being part of these first 200 shows!

In this episode, Dan is exploring a typical situation: Trying to explain the benefits of the Agile ways to someone who is not immersed in the Agile field. Referring to the Agile principles, values, or even the Agile Manifesto won’t help stakeholders. Listen to this episode and learn to communicate how Agile can help an organization to meet its needs (without mentioning the word Agile!)

Key Takeaways

• It can be challenging to communicate the benefits of using Agile to stakeholders not referring to Agile.
• If you are operating in an area of high uncertainty (or a complex environment) Scrum is the answer.
• • The Scrum framework works to deliver increments every sprint, and by receiving feedback to make sure the product developed works and meets the definition of done. This helps to have more certainty and get closer to a solution for the customer.
  • The Scrum Framework is a great assistance in reducing risks.
• When working with an organization in helping them to be more effective, you need to understand what “effective” looks like for them.
• • First, you need to know what is valuable for the organization in order to help them along the journey of becoming more effective.
  • Beginning with the end in mind helps you learn what is important and form tactics and strategies needed to assist an organization in a better way.
• Dan talks about the presentation he will do at The Agile + DevOps East Festival: It is OK to be unsafe: Scaling without using somebody else’s framework.
• • Dan will talk in this presentation about what needs to be explored in order to help an organization meet its needs, and choose the strategies and tactics that make more sense in that specific context (Scrum is a great framework but it might not be the right for everyone).

Mentioned in this Episode:

Listen to Agile Coaches’ Corner’s most popular show: What is Agile?

No: The Only Negotiating System You Need for Work and Home, by Jim Camp

Begin With the End in Mind: Habit 2 of The 7 Habits of Highly Effective People, by Stephen Covey

Find more about The Agile + DevOps East Festival

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!

Contact Dan Neumann on Twitter.

View Details

This week, Dan Neumann welcomes his colleague Michael Guiler to today’s episode.

In this episode, they will be answering questions regarding several Agile topics, such as leadership, effective communication, Team readiness, best practices, motivation, and transparency, among others. Join this fun and insightful conversation with Dan and Mike!

Key Takeaways

• What is a good-to-go technique to help leadership transition from being tactical to being more servant leaders?
• • Enable people who are closer to the work to make decisions in their field.
  • Ask questions instead of giving directions.
  • Rewire the communication path to be more practical and direct rather than following a hierarchy where there are chances of getting “lost in translation.”
• What does a Team that is ready look like?
• • A Team that is ready is open to a conversation, they have an Agile Mindset where they know they need help, and they are open to discussing it.
  • An Agile Mindset is keeping the curiosity high at all times and the readiness to run an experiment.
• What are best practices for?
• • Best practices are just resources but certainly not “the way” of doing things correctly.
  • Best practices are ways that have been used successfully in the past, and when used again they are not assuring their efficacy; a Team needs to test them to see if they apply to that particular situation.
• What does it take to help leadership transitioning to the model of motivation that Daniel H. Pink proposes in his book Drive?
• • Daniel H. Pink proposes three pillars for motivation: autonomy, mastery, and purpose. He also addresses the distractions to motivation that organizations can fall into.
  • Know your purpose at all times.
• Is there such a thing as “too much transparency”?
• • There is no such thing as too much transparency; be open, get to know the people, share, and then you can moderate.
  • Make sure that you are sharing information with people who can handle it.

Mentioned in this Episode:

Drive: The Surprising Truth About What Motivates Us, by Daniel H. Pink

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!

View Details

This week, Dan Neumann welcomes his colleague Michael Guiler to today’s episode.

In this episode, they will be answering questions regarding several Agile topics, such as leadership, effective communication, Team readiness, best practices, motivation, and transparency, among others. Join this fun and insightful conversation with Dan and Mike!

Key Takeaways

• What is a good-to-go technique to help leadership transition from being tactical to being more servant leaders?
• • Enable people who are closer to the work to make decisions in their field.
  • Ask questions instead of giving directions.
  • Rewire the communication path to be more practical and direct rather than following a hierarchy where there are chances of getting “lost in translation.”
• What does a Team that is ready look like?
• • A Team that is ready is open to a conversation, they have an Agile Mindset where they know they need help, and they are open to discussing it.
  • An Agile Mindset is keeping the curiosity high at all times and the readiness to run an experiment.
• What are best practices for?
• • Best practices are just resources but certainly not “the way” of doing things correctly.
  • Best practices are ways that have been used successfully in the past, and when used again they are not assuring their efficacy; a Team needs to test them to see if they apply to that particular situation.
• What does it take to help leadership transitioning to the model of motivation that Daniel H. Pink proposes in his book Drive?
• • Daniel H. Pink proposes three pillars for motivation: autonomy, mastery, and purpose. He also addresses the distractions to motivation that organizations can fall into.
  • Know your purpose at all times.
• Is there such a thing as “too much transparency”?
• • There is no such thing as too much transparency; be open, get to know the people, share, and then you can moderate.
  • Make sure that you are sharing information with people who can handle it.

Mentioned in this Episode:

Drive: The Surprising Truth About What Motivates Us, by Daniel H. Pink

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!

View Details

This week, Dan Neumann is joined by Phillip Lisenba, who recently joined the Agile Thought Team.

In this episode, Dan and Phillip are exploring how Agile ways could be applied to the home setting. The heart and soul of Agile can be used to achieve goals efficiently not only on a professional level but also at home in our personal lives. Listen to this episode to find many tips to reach your personal objectives with less effort!

Key Takeaways

• First, make a list (without the things you do on daily basis).
• • Include the small, medium, and bigger things that you need to do.
  • Keep it simple! You can do it on paper or digitally, and get creative in finding something that works for you.
  • Organize your tasks by priority, what creates more value for your family should go first. Everybody’s list is going to be different.

• Top ten tips to make your list:

• Create a list of things to do.

• Prioritize them.
• Break large projects into small tasks.
• Create a sense of urgency.
• Do something every day.
• Set a timebox for the work.
• Review the master list daily and reprioritize.
• Review your process and change as needed.
• Have fun with the work and process.

• Reward yourself.

• Eight Agile Tips to use at home:

• Tell yourself you can do hard things.

• Don't schedule regular daily activities unless you are creating a daily habit.
• After 30 days, once the daily habit is a habit, you can stop scheduling it.
• Take a break when frustration starts.
• Keep a record of what you have accomplished.
• Reward yourself for each day's accomplishments.
• Reward yourself for large accomplishments.

• Make the most important thing the most important thing!

• Remember to be flexible’ sometimes you have to pivot when challenges appear in order to keep moving forward. Consider changing your methods when they are no longer effective.

Mentioned in this Episode:

The 5 Second Rule: Transform your Life, Work, and Confidence with Everyday Courage, by Mel Robbins

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!

View Details

This week, Dan Neumann is joined by Phillip Lisenba, who recently joined the Agile Thought Team.

In this episode, Dan and Phillip are exploring how Agile ways could be applied to the home setting. The heart and soul of Agile can be used to achieve goals efficiently not only on a professional level but also at home in our personal lives. Listen to this episode to find many tips to reach your personal objectives with less effort!

Key Takeaways

• First, make a list (without the things you do on daily basis).
• • Include the small, medium, and bigger things that you need to do.
  • Keep it simple! You can do it on paper or digitally, and get creative in finding something that works for you.
  • Organize your tasks by priority, what creates more value for your family should go first. Everybody’s list is going to be different.

• Top ten tips to make your list:

• Create a list of things to do.

• Prioritize them.
• Break large projects into small tasks.
• Create a sense of urgency.
• Do something every day.
• Set a timebox for the work.
• Review the master list daily and reprioritize.
• Review your process and change as needed.
• Have fun with the work and process.

• Reward yourself.

• Eight Agile Tips to use at home:

• Tell yourself you can do hard things.

• Don't schedule regular daily activities unless you are creating a daily habit.
• After 30 days, once the daily habit is a habit, you can stop scheduling it.
• Take a break when frustration starts.
• Keep a record of what you have accomplished.
• Reward yourself for each day's accomplishments.
• Reward yourself for large accomplishments.

• Make the most important thing the most important thing!

• Remember to be flexible’ sometimes you have to pivot when challenges appear in order to keep moving forward. Consider changing your methods when they are no longer effective.

Mentioned in this Episode:

The 5 Second Rule: Transform your Life, Work, and Confidence with Everyday Courage, by Mel Robbins

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!

View Details

This week, Dan Neumann is joined by Justin Thatil and Erica Menendez. In this episode, they are discussing the fun topic of vacations and how their planning and unfolding can be done in an Agile way. Dan, Erica, and Justin highlight the importance of always keeping your goals in mind, and considering the expectations of everyone involved in the plan. Listen to this episode and find out how following different Agile Principles can help you plan and enjoy your time off!

Key Takeaways

• Have a goal for your vacations.
• • Even if a proposed vacation looks exciting, don’t forget to check in with your goals to make sure they are aligned with the vacation plan.
  • Brainstorming ideas is a great way to find your ideal vacation destination, to later analyze the particular characteristics of each option to make sure it is congruent with the family goals.
• The product owner role is played by the one organizing the vacation.
• • Doing the research is key to planning a successful trip that meets everyone’s expectations.
  • There might be a lot of ideas about things that want to be done on a vacation, but being realistic and selective is crucial to managing expectations.
  • Remember, flexibility is crucial, changes might be implemented at the last moment in order to make the best out of the experience.
• What can you learn along the way as you are taking the vacations?
• • There are many learning experiences waiting to happen on your vacation plans.
  • Learning and discovering are tasks that you will embrace better after practicing them several times.
  • Remember the maturity of the tool is not the same everywhere you go. (Justin shares his own example while traveling with his wife through Puerto Rico.)
  • Experimentation is necessary in order to take the best out of each situation.
• Your Daily Scrum can be breakfast.
• • The first mealtime of the day can be a great time for planning the activities.
• Retrospectives can be done along the way.
• • What goes good and what goes bad can be taken into consideration for planning the next activity or vacation.
• Don’t forget to embrace the new experience you are living with excitement.

Mentioned in this Episode:

The Scrum Fieldbook: A Master Class on Accelerating Performance, Getting Results, and Defining the Future, by J.J. Sutherland

Professional Coaching for Agilists: Accelerating Agile Adoption, by Damon Poole

No: The Only Negotiating System You Need for Work and Home, by Jim Camp

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!

View Details

This week, Dan Neumann is joined by Andrea Floyd to explore the concept of change.

In this episode, Andrea and Dan talk about the critical importance of change, since as an Agilist, what needs to be embraced as always present is change. Change is involved in every part of an Agile journey, it is a way of working and a way of dealing with people. They also address the significance of being mindful of the impact change can have on people and the organization.

Key Takeaways

• Change is constant, make it accessible.
• • Change doesn’t have to feel threatening, instead, it needs to invite curiosity and engagement.
  • If you are considering change, think about how you are presenting the topic so you are inviting people in, rather than making them want to run from the conversation.
  • First, it is important to set a safe environment to start the dialogue, then invite diverse ideas and thought.
  • Explore your today before trying to think in a different future.
  • Incremental change is a way to make people comfortable with the change they are making.
  • Understanding the intention behind the change is a key part of its success.
• Change is hard.
• • While you are changing, life doesn’t stop, the train is still moving down the track.
  • Keep in mind that every person reacts to change differently.
  • Inspection and adaption are critical. Start with small changes!
  • Keep your goal in mind and come up with a road map for the change you are looking for.
  • Don’t forget to celebrate the achievements and the people who contribute to making that change possible.
• Once a change is going, how do you prevent people from reverting?
• • An organization needs people who offer support and reinforcement when things are chaotic.

Mentioned in this Episode:

Agile Alliance 2022, Nashville, Tennessee

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!

View Details

This week, Dan Neumann is joined by Jim Beale and Gerardo de la Fuente to follow up on a conversation started in a previous episode where the constitution of a high-performing team was addressed and its direct relation with following the Scrum Values.

In this episode, Jim, Gerardo, and Dan explore the importance of trust, and how it can only be encouraged by the presence and exercise of the Scrum Values in a Team.

Key Takeaways

• What does the Scrum Guide say about trust?
• • Trust is just an outcome of living the Scrum Values that are reflected on the Team.
  • When someone starts working with a Team, it starts as a stranger, and what helps build that trust is not only sharing the Scrum Values but also being an example by practicing them.
• How can a Scrum Master help to build trust in a Team?
• • Have one-to-one sessions with each Team member, holding an open conversation about themselves and how they feel about the work.
  • Building trust requires time and consistency.
  • A Scrum Master must be honest in admitting when he had failed to follow the Scrum Values.
• How to overcome the first dysfunction of a Team?
• • Absence of trust is the first dysfunction to address, none of the other four (inattention to results, avoidance of accountability, lack of commitment, fear of conflict) can be managed until trust is recovered.
• Examples of the absence of trust:
• • A Team member avoids sharing an issue as a consequence of fearing being judged.
  • When there isn’t trust, a lot of personal conflict arises in Team meetings.
  • Backchannel conversations appear often as a result of a lack of trust.
  • People take feedback in a personal way.
• Other tactics to encourage trust-building in a Team:
• • Motivate people to be open and to make questions.
  • A Scrum Master needs to be willing to share that he does not know everything.
  • Avoid asking people why did they do something, which tends to create defensiveness, and instead be curious about what they found interesting in the decision they made.
  • Ice breakers help build trust.
  • Share the prime directive in the retrospectives.
  • Assume everyone is doing their best possible in the situation at hand, this is a way to avoid being judgmental.
  • What is celebrated is repeated, so taking the time to highlight when Scrum Values are practiced is a good way of promoting them even more.
  • Opening the cameras when meeting virtually.

Mentioned in this Episode:

Listen to “What Does a High-Performing Scrum Team Look Like?” with Erica Menendez and Justin Thatil

Overcoming the Five Dysfunctions of a Team, by Patrick Lencioni

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, by Lisa Adkins

Fixing Your Scrum: Practical Solutions to Common Scrum Problems, by Ryan Ripley

Scrum Mastery: Agile Leadership to Take Your Team’s Performance From Good to Great, by Jeff Cohn

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

This week, Dan Neumann is joined by Christine Bush, a brand new Agile thinker.

In this episode, Dan and Christine are discussing Agile Transformations. As Lyssa Adkins describes, an Agile Coach is someone who has seen lots of different success and failure patterns over time. Change is never easy, and that is the reason why Dan And Christine are diving deep into the necessary features of a well-conducted Agile transformation.

Key Takeaways

• What is important when an organization is looking for an Agile Transformation?
• • Transformations have to come from the top and leadership has to be committed to them.
  • The leadership has to be ready to invest in education for the Team members of the organization and to guide them through the Transformation.
  • Transformation cannot be an option.
  • Middle-level managers are key to a successful Transformation, they need to be trained and guided in the process.
• What is next after the training is over?
• • Agile Coaches are crucial in this stage since the application is a whole different story.
• Change can be scary.
• • Let’s experiment, instead of thinking about it in terms of winning or losing.
  • Keep your eyes on the goal.
• Are some other roles instrumental when transitioning?
• • There could be a lack of clarity on some roles at the beginning.
  • All Team members are working together to deliver outcomes in short cycles with rapid feedback loops.
  • The business stakeholders help with the requirements but sometimes they get confused by the new events.

• “Don’t just give them the title, buy them the tool, and expect the Agile process to work.”

• Organizations want to be Agile but they don’t give them the necessary coaching and facilitation that people need to be successful.

• Providing support is what enables Teams to become self-organizing and successful.
• Be patient; small victories can get a long way.

Mentioned in this Episode:

“What is Agile Coaching?” by Lyssa Adkins

Scrum: The Art of Doing Twice the Work in Half the Time, by Jeff Sutherland

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

This week, Dan Neumann is joined by Michael Cooper, Agile Thought’s Chief Architect.

In this episode, Dan and Mike explore the topic resulting from the previous conversation they had regarding technical debt, which is, once you identify the debt, what do you do about it? Michael presents three possible strategies: the most common, the undesired, and lastly, the pragmatic and practical solution.

Key Takeaways

• In response to technical debt, the first thing you can do is nothing.
• • Not doing anything about technical debt is the path chosen by many people.
  • Doing nothing is a pragmatic approach, but only works if you are planning to do nothing with the product.
• Often a complete replacement is the way chosen to respond to technical debt.
• • This could be considered a relatively undesirable strategy since it is an extremely risky approach.
  • What if the developers that wrote the code are dead? How can you know what was in the original product?
• Coming up with a completely new product (not a duplication) could be a response to technical debt.
• • This is a safe alternative but depends on whether the stakeholders will accept it.
  • It should not be just a replacement strategy but a comprehensive innovative solution, a game-change strategy.
  • This strategy would cost about twice the budget.
• The practical solution: Slowly strangling the product.
• • This is a long and pragmatic process, where you may decide to leave parts of the system.
  • This strategy will preserve the functionality of the system and produce the expected result over time.
• What is the cost to change?
• • It is very difficult to anticipate the costs.
• How do you train the Team to approach technical debt?
• • The Team makes the decision whether they are capable or not to take the task.

Mentioned in this Episode:

Listen to What is Technical Debt? With Michael Cooper

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

This week, Dan Neumann is joined by two colleagues, Hal Hogue and Misi Eyetsemitan.

In this episode, they explore a question that came up in a Coaches’ practice recently that was about the differences between a Product Owner and a Business Analyst. Are both the same? Do they have different business accountabilities? How do both enter the big picture?

Key Takeaways

● Product Owner and a Business Analyst are totally two different roles.

○ They vary by responsibility and by definition of functions; they are two entirely different roles.

○ Both roles can help in the accountabilities of Scrum.

○ Exploring the history, we traditionally had Business Analysts and Project Managers. The Scrum Framework does not have either of these titles. this

○ The Product Owner focuses on the vision and the profitability/marketability of the product (all about value).

○ The Scrum Master is all about the framework.

○ The Development Team has the accountability to develop the product and the process that will ensure that the product or task is addressed in an achievable way.

○ Business Analysts can help the Scrum Team by making sure that the backlog is representative of the vision of the product and the input of the users, stakeholders, and the Developers.

● Business Analysts are valuable when there is a scale in Agile.

○ When there is a robust product that has multiple Teams working on it, a BA is valuable.

● Is the need product- or experience-driven?

○ The answer may depend on the organization and on how Teams are set up. If the organization already has the operational role of a BA embedded within the Scrum Team, you can’t ignore it, it is part of the structure of that Team.

● Exploring each Team member’s accountabilities and responsibilities is a great way to prevent problems and safely scale. The Herculean Doughnut is an effective practice to determine roles and their reaches.

Mentioned in this Episode:

Learn more about the Herculean Doughnut

Zombie Scrum Survival Guide, by Christiaan Verwijs

Find what Dan Harmon’s Story Circle is about.

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

This week, Dan Neumann is joined by two guests, Mariano Oliveti, and Hal Hogue to talk about a topic that was inspired by a listener who recently was in a meeting where this question came up: What does a Scrum Master do with a Team that is very mature?

In this episode, Dan, Mariano, and Hal explore the concept of the maturity of a Team; does the continuous learning journey ever reach an end? Can Scrum Masters fully accomplish their work? Listen to this episode to find the answers to these very thought-provoking questions.

Key Takeaways

• What does a Mature Team look like?
• • A mature Team has a growth mindset, members are always trying to improve.
  • A mature Team fails occasionally, they learn from these experiences and are not afraid of failure.
  • Members of a mature Team often actively listen to each other, they have healthy conflict, and they are not competing against each other.
  • Mature Teams focus on the outcome of what they are doing.
• Can a Scrum Master still provide value to a very mature Team?
• • A Team might be great, but it will never be perfect; there is always an opportunity for continuous improvement.
  • If the Scrum Master is achieving a point where he believes there is nothing more to contribute to a Team, maybe he is confronted with his own fixed mindset; did this Scrum Master lose his curiosity?
  • A Scrum Master is part of the Team; he needs to self-reflect on his role constantly in order to do things differently and better for the entire Team.
  • Inviting a third party to facilitate activities for the Team and give an outside perspective is very valuable.
• A Scrum Master must nurture an experimental mindset in their Team.
• • Trying something different is always an enriching experience.
  • A Scrum Master must provide a safe environment where Team members are not afraid of failure.

Mentioned in this Episode:

Learn more about Agile2022, Nashville

The Agile Mindset — and Beyond, Linda Rising

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

This week, Dan Neumann is joined by Agile’s Thought Chief Architect, Michael Cooper to explore the topic of Technical Debt.

In this episode, Dan and Mike share how Technical Debt has become a dirty term among technical and non-technical people, where it can be considered to be a waste of time and money. Mike is here to demystify Tech Debt and talk about the necessary steps to take when encountering it, like finding its root cause and advancing a strategy to address it.

Key Takeaways

• ● What can be some indications that technical debt is present?

  • ○ The first sign is that things are not going right, people can be unhappy about some aspect of the platform, system, or project.
  • ○ One indicator is that the velocity is slowing down.
  • ○ When decisions are procrastinated we accumulate tech debt... is this a deliberate choice? Not really, but we still refuse to make decisions to address it.
  • ○ Stress is an indicator of Tech Debt.
  • ○ The passage of time will create Tech Debt.
  • ○ When defect rates get to a point that they are no longer tolerable or acceptable, you have to consider the decisions that were put off in order to reach that state.

  • ● How to avoid technical debt:

  • ○ Automated Testing

  • ○ Unit Tests for capturing the developer’s intent
  • ○ Static Code Analysis tools (such as SonarQube) for generating metrics about code complexity.

  • ● Most code in the world has high-tech debt. However, it is not an issue because people don’t need to change it.

  • ○ Software becomes “hard” when it gets enough tech debt.

  • ○ The most used strategy is to do nothing when encountering tech debt, and if you are not making changes to the code, it is an acceptable and reasonable approach.
  • ○ The highest reach approach is trying to change and rewrite the entire codebase. You are likely to lose the functionality that you originally had.
  • ○ One way of approaching tech debt is to make slow changes only when you hit that piece of code again.
  • Mentioned in this Episode:
  • What is technical debt? By Chris Cairns and Sarah Allen
  • Applied Software Measurement: Assuring Productivity and Quality, by Capers Jones.
  • Agile Estimating and Planning, by Mike Cohn
  • Want to Learn More or Get in Touch?
  • Visit the website and catch up with all the episodes on AgileThought.com!
  • Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

This week, Dan Neumann is joined by his friend and co-worker Ola Tunde.

In this episode, Dan and Tunde are exploring the matter of burnout, which sometimes is not that noticeable, and as a consequence, can pass unnoticed among co-workers. Burnout can result from many personal issues combined with the pressure of working in a small or big organization, and it can translate into a general loss of interest and motivation. Listen to this episode to find the difference between stress and burnout, and how to invest in yourself in order to rescue yourself from burnout.

Key Takeaways

• How can you tell if you are feeling burnout?
• • Burnout is physical, emotional, or mental exhaustion, accompanied by decreased motivation, lower performance, and a bad attitude towards oneself and others.
  • Burnout is different from depression.
  • Burnout results from prolonged exposure to stress. It is a chronic state, a place of exhaustion.
• There are three negative psychological impacts that burnout has on a person’s life:
• • Depersonalization.
  • Emotional exhaustion.
  • Lack of personal achievement.
• There is a close relationship between stress and burnout.
• • When you are under stress you can still control the situation, but when you experience burnout you don’t have the energy to even address certain circumstances.
  • There is a healthy type of stress that promotes getting closer to solving a situation.
• Leaders need to identify and understand those employees who are feeling burnout.
• • Good leaders (not managers) approach those who are acting differently and showing signs of burnout to find how they could be assisted, starting by giving them the chance to take a break.
• We are our worst critics, we need to learn to prioritize our needs, and take care of ourselves.
• • Stop for a moment and set the goal of being kind to yourself, shift your mindset.
  • Take care of yourself: workout, take a break to go for a walk, take two days out of work, and take more time off!.
  • Do what relaxes you.
  • Seek help.
  • Leadership needs to create autonomy and empowerment; that is the reason why leaders need to encourage Team members to let their voices be heard.

Mentioned in this Episode:

Read more about burnout in this Psychology Today article.

The Leader Who Had No Title: A Modern Fable on Real Success in Business and in Life, Robin Sharma

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

This week, Dan Neumann is joined by two Agile colleagues: Erica Menendez and Justin Thatil.

In this episode, they discuss the features of a high-performing Scrum Team and how this closely interacts with following and honoring the Scrum Values of openness, commitment, focus, courage, and respect. Dan, Erica, and Justin share valuable examples of their own Agile Journeys to define the main characteristics of a mature Scrum Team.

Key Takeaways

• A great Scrum Team:
• • Follows Scrum values: openness, commitment, focus, courage, and respect.
  • Knows how to focus.
  • Identifies the goal to be achieved and works in a self-organized way in that direction.
  • Is about having the psychological safety to be open about feelings, difficult circumstances, and even celebrations.
• Social time at the Daily Scrum is up to each Team to determine.
• The Team must volunteer to take action.
• • Scrum Team members must be able to recognize each other’s strengths.
  • Team Members can help each other with their personal goals.
• How does a mature Scrum Team behaves when things don’t go well?
• • Courage and respect are needed to face the problem.
  • Team members know how to respectfully disagree.
  • Identify what is going to be improved, changed, and done differently.
  • A Scrum Team must be willing to try something different, experimenting together.
• A Scrum Team is committed to working together in all of the different Agile values.
• • A Scrum Team is also willing to fail when trying to solve a problem with an innovative approach.
• Trust lives in a Scrum Team.

Mentioned in this Episode:

Agile Selling: Get Up to Speed Quickly in Today's Ever-Changing Sales World, by Jill Konrath

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

This week, Dan Neumann is joined by Gerardo De La Fuente to talk about Agile and what it looks like to really embrace this Agile methods.

In this episode, Dan and Gerardo discuss those cases when Agile seems to be assumed but actually, it turns out to be just a shallow performance. Are people just showing up or joining with heart and soul in the Agile ways? Listen to this episode for a great synopsis of what truly is to embrace Agile.

Key Takeaways

● Showing up vs Embracing Agile

○ Agility for a Scrum team requires an understanding of all of the different roles in order to have the right expectations. Everyone has different accountabilities!

• When Teams are challenged, the Scrum Master might be tempted to provide solutions, but that does not help in the long run. Teams should come to their own conclusions.

• A Scrum Master has to know how to facilitate and listen, as well as to make the right questions.

• A Scrum Master does not have the leading role in the play, the star is the Team. A Scrum Master needs to embrace the role of a Servant Leader.

● Teams need to understand the purpose of Scrum, its values, and its pillars (transparency, inspection, and adaptation) in order to fully realize the benefits of this Agile method.

● Scrum Masters find a valuable resource in collaborating and sharing situations and ideas.

○ Receiving feedback is crucial!

○ There needs to be psychological safety on the Team so people can be open to feedback.

○ In a Team, all members are peers collaborating with each other.

○ Collaboration also takes place with the Product Owner.

● Admitting you don’t know is tough.

○ It takes courage to provide insides about aspects that are not understood or are being done incorrectly. Being open from the beginning saves a lot of trouble.

○ When there is a knowledge or skill gap, it is helpful to reach out to someone else in the organization for help.

● Agile Teams commit to delivering value

○ The entire Team works together and contributes towards reaching the goal.

Mentioned in this Episode:

The Leader Who Had No Title: A Modern Fable on Real Success in Business and in Life, Robin Sharma

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

This week, Dan Neumann, your host, is answering a very common question: Why would an organization use Kanban or Scrum?


In this episode, he explains the benefits of both approaches, describing each of them and identifying which of them is more suitable for an organization.

Key Takeaways

• ● The kind of work an organization is doing will define the methodologies or approaches to take.

  • ○ Scrum is an excellent framework for organizations that are doing complex work, as it is creating software.
  • ○ If you are in conditions of uncertainty, you want to deliver value frequently, and de-risk your approach, a Scrum framework is the most applicable.
  • ○ The Kanban method is more thana board with signs and signals.
  • ○ The Kansan method is a disciplined approach. It includes making status clear, articulating clear policies, set work in process limits, measuring and manage flow, and then make incremental improvements over time.

  • ● Scrum or Kanban: A false choice.

  • ○ Both can complement.

  • ● Why Scrum?

  • ○ It works!

  • ○ Scrum is clearer than Kanban about rolls, events, and artifacts.
  • ○ Be cautious, there are people using Scrum immaturely and not to its fullest benefit.
  • ○ It is much easier to find employees using the titles in the Scrum framework.

  • ● Why Kanban?

  • ○ With Kanban, organizations start where they are.

  • ○ The Kanban method is great for creating transparency and supporting experiments for how you want to improve the flow of work.
  • ○ The Kanban method can be applied at many different levels and related to other groups within the organization.

  • ● How long can your organization maintain focus?

  • ○ Kanban fits better for organizations that are doing work that is frequently changing priorities.

  • ○ Scrum looks to support a product goal, and focus is maintained for longer periods (three to four weeks sometimes).
  • Want to Learn More or Get in Touch?
  • Visit the website and catch up with all the episodes on AgileThought.com!
  • Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

This week, Dan Neumann is joined by Eric Landes to answer a listener’s question about development. Our listener asked: How can a non-technical Scrum Master or a Scrum Master introduce technical skills and practices to strongly opinionated engineers?

In this episode, Dan and Eric are sharing how to shift the mindset from wanting to know it all about the design to one where emergence is embraced. They share practical tips and examples of real Agile scenarios to make change easier and lessen its costs.

Key Takeaways

● How to help engineers to embrace emergence:

○ Model the behavior and examples.

○ Go on a learning journey together. Invite them to join the process if they have some technical knowledge.

○ What is in it for them? They don’t have to spend time on a design to release that later could not scale as expected, or didn't address the customer’s needs.

● How to make change easy?

○ Eric shares how he started his Agile journey by creating an application that received a lot of resistance from the management.

● Emerging design is critical.

○ The design is fundamental to the core functionality, but the architecture is probably going to fall over in an unexpected way, even with experts things don’t always get exactly right. Testing rapidly is the way of finding what is wrong earlier.

○ Make critical architectural decisions first, instead of waiting until the last possible moment.

● What are the things people need to get right in the first Sprint?

○ Chose at least one programming language to use.

○ Identify the tools that are going to be used and where are you going to deploy the first iteration.

○ Let’s experiment with the architecture.

● The cost of change in the development is still present.

○ Take it to the Team: How can we lower the cost of change? How can we make architectural change easier?

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

Dan Neumann, your host, has been reviewing the history of the Agile Coaches Corner Podcast and encountered the most popular show among these 184 episodes, it is titled “What is Agile?” and was hosted by himself and Sam Falco.

In this episode, you will get the chance to listen again to the most listened episode so far, which explores the foundations of Agility and the history of the Agile Manifesto,

Key Takeaways

• Why was it important 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 bad 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 very difficult 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” which 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.
• What is the Agile Manifesto?
• • It’s the thing we point to when someone says, “What is agile?”
  • 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.
  • If you’re asking if something is agile, you can reference the manifesto’s values and principles.
• What is Agile?
• • It’s creating a competitive advantage and being a 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 deliberately respond to change and demand; 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:

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

View Details

This week, Dan Neumann is joined by Hal Hogue to talk about the Daily Scrum event. Dan and Hal are assessing this topic again after two years, a particular couple of years since much has changed due to the strike of the COVID-19 pandemic, especially in regards to the workplace, making most of the work to be remote.

In today’s episode, Hal and Dan are talking about the ways in which the Daily Scrum can be more effective by fostering transparency and flow to promote simplicity and focus. They also dive deep into the struggles brought by remote working and the many alternatives to tackle this issue.

Key Takeaways

● What makes the Daily Scrum effective?

○ Understand the purpose of the Daily Scrum: What are we trying to accomplish with it?

○ The Daily Scrum is a perfect place for reflecting on how the plans are going; it is a reliable time and place to focus on refining the plan and thinking about what the next steps will be.

○ The Daily Scrum can be used to avoid misunderstandings.

● How to best avoid misunderstandings about information going back and forth among the Scrum Team members:

○ The Daily Scrum is an opportunity to inspect and adapt our plans and goals.

○ Establish transparency: Make sure things are visible, well understood, and agreed upon by all the Scrum Team members.

○ The purpose of the Daily Scrum is the opportunity for the Developers collaborate to achieve the Sprint Goal.

○ Be aware of “meeting fatigue”; people tend to have a lot of meetings and that can affect the predisposition to misunderstandings.

● Different ways in which a Scrum Master can foster transparency:

○ Give the Developers a chance to evaluate how confident they are about achieving the Sprint Goal by the end of the Sprint.

○ Developers can be encouraged to reflect on the current progress.

○ Transparency and flow need to go along with simplicity and 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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

This week, Dan Neumann is joined by three of his Agile colleagues, Erik Lindgren, Hal Hogue, and Adam Ulery.

In this episode, they discuss a common question with respect to Teams: Should we choose long-running Teams or dynamically formed ones? These four Agile colleagues share today valuable examples on how to form Teams and practical ways to help Teams succeed at delivering high-value products.

Key Takeaways

• Advantages of long-lived cross-functional Teams:

  • Teams get to know each other better and build relationships.
  • Teams have working agreements that make them more effective.
  • Stability!
  • Much less coordination is needed.

  • Cons of long-lived Teams:

  • There is not much flexibility.

  • There is the risk of losing alignment with the rest of the organization.

  • What to do when someone’s professional goals push them in a different direction?

  • A Team could be kept together as long as possible but eventually, changes will happen.

  • We always need to look for ways for people to grow professionally.

  • What to consider when Teams are changing.

  • Keep the Team involved with the decisions that are being made.

  • When Teams change, the Team might be needing a skill that isn’t available.
  • Change is inevitable, be prepared for them.

  • What are the Team creation methods that work best?

  • A formal Team-forming workshop sets up Teams nicely for success, developing shared values.

  • Having a clear understanding of the type of work that the Team will be going after and based on that, finding the matched skills and competencies to that type of work.
  • Allow self-organization to happen.
  • Establish what is going to be created first in order to set up a Team; those Teams tend to grow organically.
  • Choosing a Team’s name can help people feel they belong and gives them the ability to become part of something bigger than themselves.

  • Why not both long-run and dynamically formed Teams?

  • Decide with your colleagues what can work better, encouraging self-organized Teams, since it is always positive to decide how the Team wants to be organized for the task in question.

  • The core of Agility is focusing on individuals and interactions.

  • When to form a new Team?

  • If you have some special project or initiative that may require deep specialties in an area.

  • Some Teams can come together to innovate in a particular area.

Mentioned in this Episode:

Listen to “Podcast Ep. 5: Exploring an Experimental Mindset with Adam Ulery”

Team of Teams: New Rules of Engagement for a Complex World, by Gen. Stanley McChrystal, Tantum Collins, David Silverman, and Chris Fussell

Netflix Documentary, The Last Dance

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!

View Details

This week, Dan Neumann is joined by two colleagues, Alba Uribe and Hal Hogue. In this episode, they are discussing what a Scrum Master does outside of the Scrum Team bubble. They dive deep into the roles of a Scrum Master as a teacher, coach, facilitator, and also as an impediment remover. Listen to this thoughtful conversation and find meaningful examples and valuable and applicable suggestions to live the Agile principles and promote their right implementation throughout your organization.

Key Takeaways

• What does a Scrum Master do outside of the Scrum Team bubble?

  • A Scrum Master is an impediment remover. Hal shares an example of a Team that was just exhausted from the number of meetings they meant to attend.
  • The Scrum Master can help with external Teams that are dependent on services or any kind of other development. Teams can cooperate with each other. If there is dependency among Teams, what can be done to remove them? When dependencies are removed or minimized, Teams can be in control of their own destinies.

  • A Scrum Master teaches, coaches, and facilitates.

  • A Scrum Master must look for opportunities to teach and coach while having conversations with the people in the organization to find those teachable moments.

  • A Scrum Master must teach the Agile concepts at all levels as well as coach and mentor constantly. A Scrum Master has to show people the benefits of following Agile Principles and tell them how they can experience those benefits.
  • A Scrum Master must help employees and stakeholders understand and enact an empirical approach to complex work.
  • A Scrum Master can also support innovation and creativity.
  • Scrum Masters can work with other Scrum Masters in the organization and other coaches to make sure there is an alignment among them and also be aware of what each other is doing.

  • What can you do as a Scrum Master to find other people who are participating in the Scrum Journey with you? How can they be engaged?

  • Get out there, communicate and bounce ideas with others. Build that culture and get those allies together.

  • A Scrum Master can enable conversations with other departments.
  • A Scrum Master should be the management ally.

Mentioned in this Episode:

Start with Why: How Great Leaders Inspire Everyone to Take Action, by Simon Sinek

The Zombie Scrum Survival Guide, by Christiaan Verwijs, Johannes Schartau, and Barry Overeem

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, by Lyssa Adkins

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!

View Details

This week, Dan Neumann is joined by two of his Agile Thought colleagues, Hal Hogue and Mike Guiler to discuss a very particular question: What does a Scrum Master actually do all day?

In this episode, Dan, Hal, and Mike start by exploring what a Scrum Master does not do, then they discuss the many hats a Scrum Master wears, and how these several duties impact a Team’s performance. A Scrum Master provides tools and autonomy and makes sure that each Team member knows their accountabilities and the reasons behind the work they do.

Key Takeaways

• What doesn’t a Scrum Master do all day?
• • A Scrum Master is not a calendar manager type person.
  • A Scrum Master does not keep visualization tools updated.
  • A Scrum Master is not the one updating the Sprint backlog.
  • A Scrum master does not take notes in meetings nor collect the status of people.
• The many roles of a Scrum Master:
• • A Scrum Master needs to guide the Team for them to be in control of their own destiny.
  • Helping everyone inside and outside of the Scrum Team understand who is accountable for what.
  • A Scrum master does not need to schedule all the events, but he needs to focus on how every member of the Team gets the maximum possible amount of value from each of the events, and that takes time and preparation. Mike, Dan, and Hal dive deep into the example of Retrospective Meetings.
  • A Scrum Master needs to be a teacher and help the Scrum Team understand why they are doing what they are doing.
• A Scrum Master is a facilitator and teacher and also a coach.
• • Helping unlock the potential in others, assisting the Team members by learning from their own experiences.
  • A Scrum Master needs to help the Team to become self-managed and understand how the company functions.
• A Scrum Master should foster transparency.
• • A safe environment needs to be nurtured in the first place in order for transparency to be welcomed.
  • The Team has to know why being transparent is actually helpful.
  • Scrum has artifacts to increase transparency.

Mentioned in this Episode:

• The Zombie Scrum Surviving Guide, by Christiaan Verwijs, Johannes Schartau, and Barry Overeem
• Lean Enterprise: How High Performance Organizations Innovate at Scale, by Jez Humble, Joanne Molesky, and Barry O’Reilly
• Listen to “Episode 178: Socio-Economic Approach to Management (SEAM) with Sarah Skillman and Mary Demain”

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!

View Details

This week, Dan Neumann is joined by two of his colleagues, Rosemary Atanga and Quincy Jordan. In this episode, they explore the answer to a very common question: How many teams can or should a Scrum Master Support? Dan, Rosemary, and Quincy talk about the role of a Scrum Master and how it is affected by supporting one, two, or even more Teams. They dive deep into many examples of when different ratios could work keeping effectiveness and a healthy environment as priorities.

Key Takeaways

• How many teams can or should a Scrum Master support?
• • Sometimes supporting too many teams is a matter of budget and financing.
  • Effectiveness is different than being busy, someone can be busy doing nothing. Having one Scrum Master working with multiple Teams can really affect the effectiveness of his work.
  • There must be a process for a Scrum Master to take the lead of a second Team, making sure first this Team is stable and understands all the Agile principles.
  • Are you setting the Team up for success or failure? Are you wearing out your Scrum Master? Even if it works, it is not sustainable.
• The role of a scrum master:
• • The Scrum Master needs to be an Agile Champion and to become the coach for his Team; it is crucial that every member knows about the accountabilities in order to grow into maturity.
  • The Scrum Master is there to coach and mentor the Team on best practices to really see the best benefits of Agile.
  • A Scrum Master has to foster a healthy Scrum environment.
• One Scrum Master for one Team:
• • This is a healthy ratio, it is a very good starting point for a Team that is at the beginning of its Agile Journey.
  • If the Scrum Master is supporting a very mature Team, they will be less dependent, and then it is more suitable for the Scrum Master to think to take a second Team.
• One Scrum Master for two Teams:
• • A one-to-two ratio is really ideal; in general, it works better this way.
  • The ratio usually depends on the projects, especially if a Team is taking more than one project at a time.
• One Scrum Master for three or more Teams:
• • If the Scrum Master has two Teams that are pretty mature, and one that needs more help, it might be possible to be the support for the three Teams.
  • If it is only very temporary a Scrum Master could take more than three Teams; it will be very wearing on the Scrum Master, it is not a healthy situation but is something that could be done if there are strategic reasons to do so.
  • It is not a recommended scenario.
• What can go wrong if the Scrum Master is overloaded?
• • Lack of focus. Every Team has different needs, so it will be hard to balance and give the same attention to all Teams.
  • The Scrum Master’s morale can be affected.
  • The health of the Team can be affected since they are not getting the support they need.

Mentioned in this Episode:

“The Scrum Master Checklist,” by Michael James.

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!

View Details

This week, Dan Neumann is joined by two external guests today: Sarah Skillman and Mary Demain, both SEAM experts and Agile practitioners.

In this episode, Dan, Sarah, and Mary are talking about SEAM (Socio-Economic Approach to Management) and how leadership is the key to Agility. Sarah and Mary share their extensive knowledge and experience working with SEAM, helping organizations identify the dysfunctions that are causing problems in their systems, and guiding them towards more efficient ways of operating, considering the social and financial aspects involved as both crucial and interconnected.

Key Takeaways

• What is SEAM and how is it different from other approaches?
• • SEAM is a different way to lead and manage organizations.
  • Other approaches follow paradigms that are more than 100 years old.
  • “Socio-economic” means that these aspects are considered as a priority, neither of them exists without the other.
  • SEAM works starting from the management system and follows with the other sectors of the organization. The process begins by identifying the hidden causes and what needs to be improved.
• SEAM focuses on outcomes and cost savings.
• • Sarah shares an example of a company that was wasting a lot of time and effort without knowing they could negotiate the process and obtain more benefit for the company and its people.
  • Remember that people want to help and collaborate; they just need an opportunity.
  • SEAM pays attention to cultural norms.
• How does SEAM approach culture change and transformation?
• • SEAM aims to remove the dysfunctions that slow people down in a company.
  • SEAM is an approach, not a quick fix.
• What is the liminal space?
• • The liminal space is where people are when they are changing from one place to another. It is certainly an uncomfortable place to be, but also inevitable when intended to grow, since it is where human potential is realized.
  • People first experience the liminal space individually and then do it collectively.
• SEAM starts at the top since only leaders can model the behavior they want to see in others.
• Every person is part of a system. How does SEAM help people appreciate the complexity of the system?
• • Agility is a wholeness to change and SEAM is a whole system changed.
  • Every time you change the system, dysfunctions are created, and for every dysfunction, there is a cause.
  • Six tasks every company has to tackle:
  • • Working conditions.
    • Work organization.
    • Time management
    • Collaborate, communicate, and cooperate.
    • Integrative training.
    • Implementation of strategy.
  • During the SEAM process, people are asked about what is not going well in each of these areas, and later the root causes are identified. After this first stage, the future is assessed while looking for possible solutions to those dysfunctions.
• Sarah and Mary address the “frozen middle.”
• • Everybody involved in the organizational change needs to know about the purpose of that change.
  • Interventions, training, and coaching are parts of the SEAM process.

Mentioned in this Episode:

The Reengineering Alternative, by William Schneider

The SEAM Institute

Socio-Economic Approach to Management: Steering Organizations into the Future, by Alla Heorhiadi and John Conbere

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!

View Details

This week, Dan Neumann is joined by Adam Ulery to explore the topic of scaled approaches independent of embracing an industry framework. In this episode, Dan and Adam are discussing scaling without adopting an Agile framework like SAFe. They share the reasons organizations use industry frameworks to scale, dive deep into the characteristics of SAFe and other frameworks, and describe the principles that need to be prioritized while scaling, such as Clarity of Vision, Goal Alignment, Frequent Delivery of Value, Planning and Coordination, and Transparency.

Key Takeaways

• SAFe is the most popular Agile framework for leading enterprises because it works; it's trusted, customizable, and sustainable.
• Why do people want to use an industry framework to start with?
• • People choose an industry framework to start with because they recognize and feel familiar with something that is out there in the market.
  • There is a script to follow, so people don’t have to think about the complicated parts; it is already done for them.
• When to look for another scaling framework that is not SAFe?
• • When the scaling framework doesn’t work for the client, based on where they are at the moment.
  • Dan and Adam share an example to describe the situation where certain frameworks would not be of use.
  • The model can’t be against the organizational structure.
• Principles around how an organization can scale:
• • Clarity of Vision: Make sure there is a good vision for the groups that are involved in the change, clearly expressing the purpose and goal behind the everyday work.
  • Goal Alignment: Capture the vision and create an alignment of goals that promotes it.
  • Aligning strategy to execution is an enormous tool.
  • Frequent Delivery of Value: Teams learn by delivering value and receiving feedback, which helps coordinating and planning the next step.
  • Transparency: Practicing transparency is key in a scaling process, especially when things get more complicated.
  • Technologies involved in scaling must be aligned; coherence is crucial.

Mentioned in this Episode:

Back Mechanic, by Dr. Stuart McGill

Thinking Orthodox: Understanding and Acquiring the Orthodox Christian Mind, Eugenia Scarvelis Constantinou

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!

View Details

This week, Dan Neumann is diving deep into the topic of psychological safety, inspired by a couple of articles that got his special attention (references below). Dan is sharing in today’s episode the definition of psychological safety, its link to diversity in Teams and innovation, as well as some specific ways to foster psychological safety as the number one prerequisite for a successful Team.

Key Takeaways

• What is psychological safety?
• • Psychological safety is a shared belief that the members of a team won’t be rejected or embarrassed for speaking up with their ideas, questions, or concerns.
• Bresman and Edmondson present research that supports that diversity on a team is linked to a better outcome.
• • This research explores the bond between diversity and psychological safety, implying that more diverse teams are going to have better ideas and outcomes than teams that are less diverse.
  • From the research, they found that diverse teams tend to be a little lower on performance than more homogeneous teams.
  • They also differentiated from highly diverse teams that had high psychological safety and those that did not have it. This first group outperformed by a meaningful degree both the diverse teams that didn’t have psychological safety and also low diversity to homogeneous teams.
  • Meeting with the purpose of finding root causes can feel a lot like blame, and blame is one of the behaviors that destroy psychological safety. Transform meetings into opportunities to share information.
  • Seek information! Don’t assume you know. Choose open versus closed-ended questions.
• In his article, Timothy Clark uses the term dialogic process to explore how Teams harness intellectual friction and navigate their interdepending work.
• • If there is a lack of psychological safety, individuals are going to censor each other or result in self-censoring behavior which prevents a highly collaborative atmosphere in a Team.
  • High psychological safety promotes innovation as a goal while a lack of it produces fear as a response and survival as the goal.
  • Clark frames Agile as a culture implementation, bringing the Agile values into practice.
  • Small and seemingly insignificant acts of disrespect, indifference, and rudeness can push a Team back into withdrawal and personal risk management.
  • Clark also shares four steps to work in a Scrum Team to continue to foster psychological safety.
• Ways to promote psychological safety at work:
• • Google has identified five dynamics in successful Teams and the number one prerequisite is psychological safety. The second is dependability, in third place are structure and clarity, fourth is the meaning of the work, and lastly, the members of the Team have to fundamentally believe that the work they do matters.

Mentioned in this Episode:

“Exploring Psychological Safety and Danger with Ola Tunde”

“Agile Doesn’t Work Without Psychological Safety,” by Timothy R. Clark

“Research: To Excel, Diverse Teams Need Psychological Safety,” Henrik Bresman and Amy C. Edmondson

“The five keys to a successful Google team,” by Julia Rozovsky

“8 ways to create psychological safety in the workplace,” by Greg Barnett, Ph.D.

Switch: How to Change Things When Change Is Hard, by Chip Heath

Crucial Conversations: Tools for Talking When Stakes Are High, by Joseph Grenny, Ron McMillan, Al Switzler, and Kerry Patterson

Multiple Explanation: A Consider-an-Alternative Strategy for Debiasing Judgments, Edward R. Hirt and Keith D. Markman

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!

View Details

This week, Dan Neumann, your host, is sharing what he has learned from his continuous learning journey that brought him to acting classes several months ago and that now involves him getting a part as an actor in a play. Dan learned from his acting classes a lot of wisdom that can also be applied to Agility and in the delivery of value to the organization and he is sharing it in today’s episode.

Key Takeaways

● Role clarity is crucial.

○ Expectations are related to the role you are playing.

○ Not every decision has to be made by consensus. Not everyone on the Team must agree.

○ There’s a time and a place for people to share ideas.

○ Ask permission to share feedback, and make sure you are invited in.

● Embrace the fact that estimations and plans will change.

○ Your estimate is always going to be wrong.

● What can you do to make sure you are prepared to bring your whole self to the work?

○ How does your individual performance affect the whole team?

● Personal accountability:

○ Who is responsible for what?

○ Know your part but also don’t ignore the others’ accountabilities

• Ask questions if you need clarification.

○ Advocate for your own needs: What do you need to be successful?

● Transitions:

○ Reflect and think through the transitions to improve them.

○ What are the triggers for change?

● Risk assessing:

○ How can you forecast risks? You can’t eliminate risk. Things will go wrong, and you will need to adjust in time.

● Take care of people.

○ People are not resources; we are complicated and our emotional and physical needs have to be contemplated.

○ Let people know what is coming; uncertainty is uncomfortable.

○ Be clear about starting with an ending in mind.

○ Reach out to your people, be supportive, check how they are doing.

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

View Details

This week, Dan Neumann is joined by Kristan Chavious and Quincy Jordan, two returning guests and colleagues.

In this episode, they are discussing the very special topic of empathy and how it can be a challenge to practice it in fast-paced settings; it can be tough to reconcile empathy with moving fast but there is a significant value in it.

Key Takeaways

• Different ways to bring empathy into an Agile Team:
• • Empathy is known as the ability to understand and share the feelings of another person.
  • Empathy is also being able to understand someone else’s values.
  • Get outside of your personal experience to see it through the eyes of others and connect with their emotional and psychological response to an event.
• Leading Agile Teams is different than leading traditional teams.
• • An Agile Team is self-organized but a leader needs to support the decisions that the Team members make versus telling them what to do.
  • Displaying a level of empathy allows the Team to grow; no Team starts as a high-performance Team, it evolves into one.
  • In traditional teams, the work done is prioritized: “Just get it done.”
• Empathy in Self-managed Teams:
• • Expectations must be addressed, especially in regard to job descriptions.
  • Team members have to know that they have permission to make certain decisions.
  • The culture needs to be shifted from fearing failure to celebrating it. Leaders must be able to support their teams in their failures.
• Empathy should be demonstrated top-down and bottom-up.
• Participating in meetings, turning on cameras, and really being present are crucially important to foster empathy and better communication.
• • Assume a good intent, “You know they mean well,” even in the most tense scenarios.
  • When you realize someone is having a bad day, try to adjust and to help who is in need at that particular moment (if it is an ongoing attitude, that is simply abuse).

Mentioned in this Episode:

Do Nothing: How to Break Away from Overworking, Overdoing, and Underliving, by Celeste Headlee

The Ruthless Elimination of Hurry: How to Stay Emotionally Healthy and Spiritually Alive in the Chaos of the Modern World, by John Mark Comer

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!

View Details

This week, Dan Neumann is joined by three colleagues Alba Uribe, Quincy Jordan, and Justin Thatil, to have a second conversation about vulnerability, especially about the patterns Teams can fall into that are a threat to vulnerability and the overall safety of the work environment.

In this episode, they explore these dangerous antipatterns and how to prevent them.

Key Takeaways

• Avoiding the Antipatterns:
• • If you “Bring your whole self to work” you are able to be vulnerable and propose ideas.
  • If you are making promises you can’t keep, people won’t feel trustful of the environment anymore. Trust and transparency need to be built into Teams in order for them to be effective.
  • Remote work presents challenges to building relationships that can foster vulnerability.
• How does a Scrum Master create an environment for people to allow themselves to be vulnerable?
• • A Scrum Master can show his/her own vulnerability in order to model the behavior to others (asking questions, making sure the camera is on in video calls).
  • Setting up a safe environment can require collaborating or setting expectations with those who are not on the team about the environment.
  • Vulnerability requires a lot of emotion, allowing yourself to feel and connect with others.
• Assessing the root cause of a negative emotion that can arise as a result of the process is needed in order to prevent its repetition.
• • Being neutral only exacerbates the problem instead of seeking a potential solution.
  • Know the Team Agreements or Rules of Engagement: How are we going to interact? What are we going to do when we have differences?
• Activities that numb vulnerability are a pattern to avoid.
• • Highlighting weaknesses promote a sense of fear and unsafety.
  • When some individuals disregard others’ ideas, vulnerability is at risk.
  • All questions are good questions! Promoting open communication is the best way of encouraging vulnerability.
  • A certain level of emotional intelligence is required to promote more human connection.
• Unhealthy comparisons are vulnerability destroyers.
• • Don’t compare Teams’ performance, it is just not effective.
  • Looking back to a different Team composition and comparing past results to today’s is not useful.
• Favoritism is also an antipattern.

Mentioned in this Episode:

Listen to Ep. 171: Fostering Vulnerability in Agile Teams

Positive Intelligence

Positive Intelligence: Why Only 20% of Teams and Individuals Achieve Their True Potential and How You Can Achieve Yours, by Shirzad Chamine

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!

View Details

This week, Dan Neumann is joined by his colleague Misi Eyetsemitan and together they are exploring the value of Empiricism beyond the Scrum Team.

In this episode, Dan and Misi dive deep into the meaning of Empiricism and how it contributes to a Scrum Team predictability. Empiricism leads to more effective decision-making and is considered a powerful tool to manage expectations within an organization; you can’t miss this episode for a thoughtful discussion of its extent.

Key Takeaways

• What is Empiricism?
• • Empiricism is knowledge from experience and using that knowledge in decision-making while ensuring we are eliminating risks.
  • In a Scrum Team, empiricism is at the core of the work.
  • Empiricism helps to build some level of predictability to the goals a Scrum Team has.
• Empiricism from an Organizational point of view:
• • Each Sprint is an experiment, each idea is a proposal to experiment.
  • The first step is going out, using the available data to make informed decisions, and testing the existing hypothesis in order to validate that data.
  • From the moment a concept comes up, those who are going to be building it need to provide feedback to formulate an early hypothesis.
• Budgeting within the Agile Space:
• • After developing a concept and a way of materializing it, the following step is funding. These questions proceed: What is sustainable and what is not? What is emerging?
  • How we use the empirical data that we have to find what is emerging is what really provides the most value.
  • Misi explains how the concepts of profit and value have evolved over time.
  • A budget needs to support what is bringing the most value.
• Empirical data shows in many ways in decision making, going beyond the day-to-day of a Scrum Team.
• How can we use empiricism to help us better manage expectations?
• • Empiricism is key to setting goals, road-mapping, and validating MVP.
  • Evaluating success is a challenging task.
  • Organizations use different tools to measure success but the primary measure is how much value is being provided to customers.
• The vision must always be present as the main driver of an organization.
• • It all starts with a vision.
  • Our vision shapes what we want to be seeing.
• In order to share empirical data, a safe environment is required.
• • Empirical data within is very tricky, people in the organization need to be empowered to share that information, and that only happens in a psychologically safe environment.

Mentioned in this Episode:

Positive Intelligence

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!

View Details

This week, Dan Neumann is joined by three of his colleagues Alba Uribe, Quincy Jordan, and Justin Thatil. In today’s episode, they are exploring the concept of vulnerability as it is introduced by Brené Brown and its meaning for Scrum Masters and Agile Coaches who are seeking to foster a safe environment where vulnerability is welcomed and celebrated.

Key Takeaways

• What is vulnerability?
• • According to Brené Brown, vulnerability is the emotional experience during times of uncertainty, risk, and emotional exposure.
  • Vulnerability is related to having courage regardless of the circumstances.
• There are different phases of vulnerability: on an individual and a collective level.
• • You succeed and fail as a team; it is not about each person’s performance but the collective execution.
  • Teams need to trust and work together as a unit, as a collective.
• What techniques can a Scrum Master use when having a new team and trying to create some of the safety that can host vulnerability?
• • A Scrum Master should first show and model vulnerability and then ask the team what they need in order to feel safe.
  • To establish safety.
  • To open up to team members about the importance of fostering vulnerability.
  • A team has to be aware of the responsibility implied in fostering a safe environment where vulnerability can take place.
• Human connection is the catalyst to establish vulnerability.
• Myths about vulnerability:
• • Vulnerability is disclosure: There have to be boundaries to what you share; vulnerability shows that there is trust and safety about what is appropriate to share at the right moment.
  • Vulnerability is weakness.
• Techniques to encourage vulnerability:
• • Intentionally expose your troubles for others to see that you are willing to be transparent; vulnerability is contagious.
  • Establish what is OK in the team setting.

Mentioned in this Episode:

The Seat of the Soul, by Gary Zukav

Positive Intelligence

Positive Intelligence: Why Only 20% of Teams and Individuals Achieve Their True Potential and How You Can Achieve Yours, by Shirzad Chamine

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!

View Details

This week, Dan Neumann is joined by two of his colleagues, Adam Ulery and Kris Chavious.

In this episode, Dan, Adam, and Kris are answering a listener who asked about the Dos and Don’ts of a Scrum Master. They cover topics such as culture, how to handle time boxes, meetings, and the challenging role of a Scrum Master removing impediments, among others.

Key Takeaways

● Dos for a Scrum Master:

○ As a Scrum Master, you bring the culture to the team. People share more when they are comfortable; a light and energetic atmosphere is important.

○ Get to know the people on your team.

○ A Scrum Master needs to be the positive force to the team.

○ Joke around! Make work fun.

○ How do you level down the stress in teams? Incorporate personal stories to lighten things up or play music (instrumental if there are activities to be done).

● Dos and Don’ts related to time boxes:

○ Some people may not understand what that means.

○ Time boxes are a maximum point but if you finish earlier it’s just fine.

○ Don’t be authoritarian about the time box.

○ Be mindful of the time box, but make sure to leave some time for people to share if something is pending or needs to be addressed in a future meeting.

● The Role of a Scrum Master removing impediments:

○ Enabling and facilitating are roles of the Scrum Master but he is not responsible for solving all the problems.

○ A Scrum Master needs to bring thinking tools to the team and know how to ask questions in order to achieve a solution.

● Don’t unnecessarily schedule meetings!

● Scrum Masters shouldn’t be an extreme micromanager.

○ You don’t have to be on your team every day, we are all professionals. There are mechanisms set to see the progress of the work every day.

● As a Scrum Master, you sometimes have to have uncomfortable conversations.

○ Don’t tolerate damaging behavior, address it right away!

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!

View Details

This week, Dan Neumann is joined by two of his Agile Coach’s colleagues, Andrea Floyd and Adam Ulery.

In this episode, Dan, Andrea, and Adam are answering a listener’s question who is just entering the role of a Scrum Master in the organization he works for and realized that it’s going through the consequences of a lack of the application of the ADKAR model. This listener asks for help in order to prevent his team from completely crashing and burning with the adoption of the SAFe methodology tasked by the leadership.

Key Takeaways

• A safe Scaled Agile framework.
• • When looking for a safe way to scale, visit Scaled Agile Framework where you can find lots of information and an implementation road map for different organizations to implement.
  • Change will affect everyone on the Team.
  • Training is necessary for all individuals to understand how change is going to impact them.
  • SAFe is a framework; there are other tools to complement it.
  • Look for opportunities to create organic learning groups.
• What is the tiebreaker between the roles of a Scrum Master, Product Owner, and Engineering?
• • Engage the community to have a collaborative conversation about what will make the best impact for the desired outcome.
  • Who has the tiebreaker? That depends on the topic of the change involved, it could be the Scrum Master or the Product Owner.
  • The Scrum Master needs to help in guiding the practices and the processes around Scrum.
  • It is crucial to have working agreements and an explicit understanding of who is responsible for what domain and area.
  • To script the opening move is one strategy to making changes.
  • Understanding accountabilities for each role is key for a successful change.
• Is there a change management plan template or some best practices to show the “why” for the process? How do you make people want to change?
• • Create excitement by helping people understand how the change benefits them and why change is happening.
  • The implementation roadmap at Scaled Agile Framework is a very useful resource, all needed modifications can be done to fit your organization’s needs.
  • Visit LACE to learn how to create a Lean-Agile Center of Excellence.
• Tips for change agents to help them build some transparency:
• • Always come from a place of humbleness and curiosity in the way you are approaching change.
  • Empathy is a needed skill when confronting change.
  • When you first start something it always feels a little chaotic and the human normal reaction is to go back to what is familiar; use empathy to understand this feeling; just be human.

Mentioned in this Episode:

Scaled Agile Framework

LACE

Positive Intelligence: Why Only 20% of Teams and Individuals Achieve Their True Potential and How You Can Achieve Yours, by Shirzad Chamine

Scrum Guide

Kanban: Successful Evolutionary Change for Your Technology Business (aka “blue book”)

A Simpler Intro to Kanban

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!

View Details

This week, Dan Neumann is joined by Andrea Floyd, colleague and principal consultant at AgileThought, to discuss different ways of helping Agile Practices to take root and thrive within organizations.

In this episode, you will find an opportunity to reflect on your Agile Journey, identify the aspects where adjustments can be made, and reinforce the Agile Mindset for it to really take root, become sustainable, and have all the positive impacts possible.

Key Takeaways

● An Agile Journey needs tune-ups.

○ Taking care of things is action-oriented.

○ Taking a moment to reflect is part of practicing awareness.

● What can impede an Agile Journey to thrive?

○ Not paying attention to accountabilities across the teams. It is important to take a moment to agree on accountabilities.

● How can we create accountabilities when a gap is spotted?

○ Create a space where people can contribute.

○ Our words are important, make sure the words you choose to use are understood. Create a glossary of terms to help with that alignment.

○ Listen and observe the ways people are working together.

● Find the whys behind what is being done.

○ Forecast rather than plan.

● Tune-ups are about inspecting and adapting (and that needs to be visible).

● We don’t succeed without our people.

○ Care for your people and do no harm.

○ Focus on empathy and safety.

○ People are not hired to be a widget in a machine, a safe environment should encourage people to share their experiences and thoughts.

○ Are we incentivizing the right behaviors and the mindsets that support them?

● Business Agility is linked to Influential Leaders.

○ Agile Journeys have more opportunities to succeed if we have engaged leaders.

○ Andrea and Dan talk about the difference between engagement and support.

○ An inspiring leader creates communities to promote Agility.

Mentioned in this Episode:

Positive Intelligence: Why Only 20% of Teams and Individuals Achieve Their True Potential and How You Can Achieve Yours, Shirzard Chamine

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!

Share These Tweets!

“Taking care of things is action-oriented “ — Andrea Floyd

“Our words are impactful, make sure the words you choose to use are understood.” — Andrea Floyd

“Create safety for people to bring their past experiences to grow from them, people are not hired to be a widget in a machine.” — Dan Neumann

View Details

This week, Dan Neumann is joined by a colleague, friend, and Professional Scrum Trainer, Eric Landes.

In this episode, Dan and Eric are answering a listener’s question that arises from an episode in which Change Fatigue was discussed; the listener wants to hear more about cases observed of Change Fatigue in Teams and Organizations and how they can be dealt with. They wonder if it is ever OK for a team on the path to Agility to say: “We made a really good progress; let’s take our foot off the pedal of continuous improvement and just cruise for a while!”

Key Takeaways

● What does Change Fatigue look like?

○ One-week sprints can exhaust Teams; speed is good but the Team’s engagement is a priority.

○ The retrospective after a Sprint is designed to be a moment to take a step back and reflect, maybe celebrating what is working well as opposed to meaningful process change.

● How to avoid Change Fatigue?

○ A way of avoiding Change Fatigue is by hosting the retrospective after a Sprint in another setting where the Team can unwind.

○ Try to change the mood, promoting a fun and easy atmosphere.

○ Think of places where you can give your Team a little rest and also listen to your Team’s suggestions about where would they like to go for a little relaxation.

○ The change might be needing to pause on changing.

● There is a potential of doing Change wrong.

○ Change is done wrong when you’ve lost the ability to deliver.

○ In Scrum, when you bring changes on they can only be one or two into a Sprint.

○ Ask yourself: Is this change effective?

● Apply, reflect, and adjust.

○ You not only have to be constantly doing!

○ It is OK to rest (by the way, it is needed!)

○ Every task is in a series; just work on one at a time. Don’t worry about the whole thing, just about the next thing.

Mentioned in this Episode:

Listen to Episode 53: “Why Should Scrum Teams Continually Improve” where Change Fatigue was first discussed

Agile Retrospective: Making Good Teams Great, by Esther Derby and Diana Larsen, with forward by Ken Schwaber

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!

View Details

This week, Dan Neumann is joined by Buyi‌ ‌Kalala‌ in today’s episode to explore the differences between Agile Missionaries and Agile Mercenaries, considering a missionary someone who is there to help and assist the team on its journey, and a mercenary, who is paid to “hit,” who can reinforce misconceptions, and even execute tasks that are not coherent with the Agile Values and Principles.

Key Takeaways

• Agile Missionaries vs. Agile Mercenaries.
• • Assist the organization in knowing what they don’t know, leading them into a new direction, a new way of operating.
  • Sometimes organizations put all the responsibility on the Agile Coach when in fact it is their transformation, not the Coaches.
• The reaction to change.
• • Planting the seed takes time, organizations need time to process and digest change.
  • Sometimes there is resistance to change and in other cases, there is change fatigue.
  • Sustainable change comes after a time-consuming process.
• Well-taken decisions will be celebrated while poor actions will also be exposed.
• • Mistakes in the Agile Journey are opportunities to pivot.
  • Sometimes it is easier to identify the “wrongful” behaviors rather than having the ability to catch the right decisions to be able to encourage them.
  • Focusing on potentials and possibilities is the way to highlight the behaviors that are aligned with the Agile Culture.
• One-on-one conversations are crucially important.
• • Introverts can have a hard time dealing with the face-to-face approach.
  • Showing interest in the other person is necessary to achieve a common goal and be successful together.
  • Think outside of the box and try to connect from the other person’s perspective.
  • Practice patience and be curious (instead of judgemental).

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!

View Details

This week, Dan Neumann is joined by a repeated guest, Quincy Jordan. Today they are talking about the vital importance of getting Agile Teams and initiatives off to a good start.

In this episode, they discuss the things that need to happen outside the Teams and that also need to involve them, what elements are required to support the Team and what to expect from them. Listen to this episode to learn more about how to support a Scrum Team to have the best start possible.

Key Takeaways

• Management should support the Team in its efforts to deliver something of value to the organization.
• • Sometimes a Team needs mentoring that comes from outside the team.
• Establishing Team working agreements.
• • Teams need to have working agreements to help establish guidelines about how to do the work and communicate as a Team.
  • Conflict will happen; that is why rules of engagement are necessary to anticipate the way in which a team will address those potential conflicts.
  • Leveraging emotions in conflict resolutions is needed; emotions cannot be removed from a human experience.
• Why do we care for getting off to a good start in the first place?
• • Awareness: A team needs to know why they are endeavoring in a particular project as well as they need to know what is the benefit and who is benefiting from the work.
  • It is important for those on the front line to really know how their work ties to the topline business objective; this is the way for them to see the value of the work that they are doing there.
  • Quincy and Dan talk about the critical aspects in launching a Team, which are covered by the methodology for change managing called ADKAR: Awareness, Desire, Knowledge, Ability, and Reinforcement.
• The facets of getting off to a good start.
• • After working on the Awareness it is necessary to make it clear how the Team is going to communicate.
  • There is a benefit to anticipating how we are going to reward behaviors that we want to perpetuate.

.

Mentioned in this Episode:

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, Lyssa Adkins

Blog post by Esther Derby: “Building Effective Teams: Miss the Start, Miss the End”

Liftoff: Launching Agile Teams & Projects, Diana Larsen and Ainsley Niles

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!

View Details

This week, Dan Neumann is joined by Adam Ulery to continue the conversation in regard to Organizational Change. In the previous episode, they discussed the first two steps proposed by the ADKAR Model for Change Management (Awareness and Desire), and today they follow with Knowledge, Ability, and Reinforcement.

Key Takeaways

• What does Knowledge Building look like?
• • Training and education are needed to help people get the knowledge they are going to need to be successful in this change.
  • The mindset component is a major part of an Agile Transformation; this mindset involves a different way to approach business and the delivery of a product.
• Dan and Adam talk about the “Follow the rules” approach.
• • There has to be some knowledge acquisition before “learning by doing.”
  • Formal training is very helpful (videos, books, classroom training).
  • A potential pitful is not giving adequate time or resources to allow the knowledge acquisition to really take place.
• See one, do one, teach one.
• • When someone teaches others they start to learn what they are teaching in a better way.
• Knowledge and Ability are tied together.
• • Knowing something needs to go along with being able to do it.
  • Acquiring more knowledge and improving abilities grow together.
  • Feedback is crucial to increasing someone’s ability to solve a problem.
  • Failing safely is part of learning.
  • Adam and Dan share on gradually increasing knowledge and ability from an enterprise perspective within a safe environment that fosters change.
• The Reinforcement piece.
• • Celebrate examples of the change.
  • Be happy and excited about the change.
  • By reinforcing you are creating more awareness!
  • Rewarding people is necessary. (Bonuses matter!)
  • Public celebrations and peer-to-peer recognition are effective ways of reinforcement.

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!

View Details

This week, Dan Neumann is joined by Adam Ulery to accompany you on Christmas Eve in an Agile way. This time of the year is for reflection, to be grateful about the blessing of the year as well as a time to think about what wants to be changed and improved.

This episode is the first of two where Adam and Dan talk about organizational change management and present the steps involved in the ADKAR Method: Awareness, Desire, Knowledge, Ability, and Reinforcement as they dive deep into the first two steps: Awareness and Desire.

Key Takeaways

• Annual goals or New Year’s resolutions?
• • Time for reflection and forward planning.
  • New Year’s resolutions tend to be pleading kinds of decisions and they tend to be abandoned during the year.
• Organizational Change Management.
• • Real change management is needed to achieve effective change.
  • ADKAR Method: Awareness, Desire, Knowledge, Ability, and Reinforcement.
• Waterfall Project Management.
• • If you don’t understand the change or the need for it, you won’t support it.
  • What is the nature of the change?
  • People really need to understand why the change is necessary (Awareness).
  • Top leadership needs to communicate how the change is aligned with the direction and the strategy of the company.
• What are some ways of building Awareness?
• • There needs to be Awareness of the nature of the change.
  • Marketing people can be in charge of the communication of the change as well as HR.
  • In-person events are important to communicate change.
• Awareness building even before there is a brand to build.
• • One-on-one conversations are useful to anticipate the change coming.
  • Awareness is the key first step (and it’s surprising how often this step is skipped).
• Desire: Why should I change the tasks that I do on an everyday basis?
• • Dan tells a professional experience about change, awareness, and desire.
  • Long feedback loops are obstacles and cause struggle; shortening them provides tremendous value.
  • How can you build desire for people “in the middle”? Help them think about their personal goals, ambitions, and aspirations and explain some of the benefits involved in the upcoming change.

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!

View Details

This week, Agile Santa (Dan Neumann), your host, is joined by Hal Hogue, Misi Eyetsemitan, Alba Uribe, Rosemary Atanga, and Jesus Gerardo de la Fuente Garcia in this very special Christmas Special. Agile Santa is taking some Christmas requests from these very special coaches as well as listening to what they are grateful for about this year’s work.

Key Takeaways

● Gerardo tells Agile Santa his favorite part of this year’s work and what is on his Agile Santa list.

○ Having a global and multicultural team.

○ Team members have served their stakeholders, delivering value and outcomes, and also used the Sprint Reviews to showcase their work.

○ Gerardo wishes to be better at story mapping.

● Hal talks to Agile Santa.

○ Hal is grateful for working with people, getting involved with Agile teams, helping them understand the way behind the tasks they are working on, and growing as individuals, as teams, and even helping entire organizations with their own Agile Transformation.

○ Hal confesses that he struggles sometimes with being judgmental, so he has been reminding himself to be curious instead.

○ Hal wishes he could know his clients and coworkers personally, on a more human level.

● Elf Misi presents Coach Alba who shares her wishes with Agile Santa.

○ Alba wishes to have organizations embrace an Agile Mindset, understanding all the value that Agile can bring.

● Elf Misi introduces Rosemary to Agile Santa and she shares her Christmas wishes with him.

○ Rosemary has been a good coach, looking after everybody on her team, making sure they are doing what they are supposed to do, and giving them the support that they needed.

○ Rosemary wishes Agile Santa makes real all the outstanding things Agile Teams are waiting to happen.

○ Rosemary asks for consistent encouragement and motivation.

Mentioned in this Episode:

Agile Team Building Activity

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!

View Details

This week, Dan Neumann is joined by Ola Tunde to talk about Agile Leadership; this is certainly a recurrent topic, but a needed one, since it is easy not to really have leadership in place as part of an Agile Journey or even some organizations’ leaders don’t really know how to contribute.

In this episode, Ola and Dan share the differences between a manager and a leader, and the features that define a great leader, as the necessary piece for an organization to really thrive.

Key Takeaways

• Managers are not necessarily leaders.
• • A leader draws people, a manager forces them.
• Agility is a better way of doing what you have been already been doing.
• • A good leader is the picture of Agility within the organization that the people can follow. A leader must model the behavior wanted in the organization, exhibiting principles and values that others should follow, too.
  • A Leader is the one who knows, goes, and shows the way.
  • Without a great leader, an organization can not thrive.
• A leader must always pay attention to the human factor.
• • It is the responsibility of a leader to attract, retain, and even develop new talent that will fulfill the organization’s vision.
  • Not everyone would be the right fit for an organization.
  • Leaders who are emotional and who are not fully devoted to the people they are serving will cause the organization nothing but commotion.
  • Sometimes a leader must be ready to adjust the ways to maintain the vision when it is needed.
  • People are not resources.
• The three things leaders focus on:
• • Setting direction.
  • Inspiring commitment.
  • Building capacity.

Mentioned in this Episode:

The 21 Irrefutable Laws of Leadership: Follow Them and People Will Follow You, by John C. Maxwell

Agile Marketing: From Waterfall to Water Flow, by Konstantinos Giamalis

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!

View Details

This week, Dan Neumann is joined by the AgileThought colleague Jesus Gerardo De La Fuente Garcia to continue the conversation started in Episode 159 about the many hats of a Scrum Master. In the previous episode, they dove deep into the role of a Scrum Master as a teacher and today you will hear their discussion about the roles of mentor and Coach.

In this episode, Gerardo outlines the differences between mentoring and coaching, explaining the various functions a Scrum Master assumes in each of these roles.

Key Takeaways

• What does a Scrum Master’s coaching position look like?
• • Coaching begins when the team understands the why and the what, behind their everyday practices.
  • A Scrum Master as a Coach opens space for his/her team to experiment, he/she shows new perspectives and possibilities, but before these are possible, there needs to be a relationship based on trust.
  • A Scrum Master needs to stimulate a culture of continuous improvement as well as to support the team in problem-solving and conflict resolution.
  • A Coach helps to change attitudes, mindsets, and behaviors that restrict the team to perform in the best way possible.
  • Giving open and honest feedback is also the chore of a Coach.
  • A Scrum Master should support and encourage collaboration with the Scrum Teams.
• A Scrum Master as a Mentor
• • The team has a full understanding of the values and principles, and in a way, they have the same knowledge as a Coach.
  • A mentor is an inspiration to others and guides people to personal and professional growth.
  • A mentor needs to be ready to serve others before his or herself.
  • A mentor helps the team to become more and more resilient.
  • A Scrum Master as a mentor finds what motivates each member of the team and helps them to identify their own goals.
  • A Mentor promotes these three habits: Thinking, Feeling, and Executing.

Mentioned in this Episode:

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, by Lyssa Adkins

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!

View Details

This week, Dan Neumann is joined by a first-time guest and AgileThought colleague Jesus Gerardo De La Fuente Garcia. Thanksgiving is here, and a lot of what Coaches and Scrum Masters do is about giving.

In this episode, Dan and Gerardo dive deep into the role of a Scrum Master as a teacher, leaving for a future episode the two other roles, being one as a coach and the other as a mentor. They explain the meaning of a team, the values implied in it, and how a Scrum Master can foster a safe environment for a team to thrive.

Key Takeaways

• How is giving perceived by a Scrum Master?
• • Scrum Masters are in a great position to help others to be successful.
  • A Scrum Master can cover three important positions: Coach, Teacher, and Mentor.
• What does it mean to be a team?
• • Clear is kind: It is a great way to start to clarify the principles and values of the Scrum Framework for the team to know, not only what they are doing, but why they are doing it. Then they can start to share identity as team members.
  • Working in collaboration to achieve a shared goal effectively.
  • Listening to other team members.
  • Taking everybody’s ideas under consideration.
  • Accountability and candid respect need to be present at all times among team members.
  • Sharing best practices as well as the bad habits that need to be avoided.
  • A team needs to be taught how to be self-organized and be able to make decisions when needed.
• A gift that a Scrum Master can give to a team is having fun!
• • Strengthening collaboration bonds and enhancing the team spirit.
  • Using mindful techniques and games can help to bring a team together.
  • Every member is a crucial part of the team.
• Thankfulness
• • Nothing is for granted; gratefulness needs to be practiced at all times.
  • Openness and trust given by team members are well appreciated.

Mentioned in this Episode:

Scrum Mastery: From Good to Great Servant-Leadership, by Geoff Watts

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!

View Details

This week, the United States will be celebrating the Thanksgiving holiday. In this last installment of our Thanksgiving-related short episodes, Hal Hogue shares what he is thankful for. Have a fantastic Thanksgiving!

View Details

This week, the United States will be celebrating the Thanksgiving holiday. In this installment of our Thanksgiving episodes, Erik Lindgren shares what he is thankful for.

View Details

This week, the United States will be celebrating the Thanksgiving holiday. In this first installment of our Thanksgiving episodes, Lucy Lin shares what she is thankful for.

View Details

This week, the United States will be celebrating the Thanksgiving holiday. In this first installment of our Thanksgiving episodes, Alba Uribe shares what she is thankful for.

View Details

This week, the United States will be celebrating the Thanksgiving holiday. In this first installment of our Thanksgiving episodes, Mariano Oliveti shares what he is thankful for.

View Details

This week, Dan Neumann is joined by two AgileThought colleagues, Alba Uribe and Michael Guiler, to explore the concept of User Story Mapping.

In this episode, Dan, Alba, and Michael are diving deep into different approaches to starting backlog; they describe the benefits of story mapping and explain why it is a great tool to achieve a shared understanding throughout the whole team. Listen to this episode to achieve a comprehensive understanding of Story Mapping with various examples that will help you put this concept into practice.

Key Takeaways

● Why is Story Mapping a great way to create a product backlog?

○ All the team can see the overall vision and what is in the mind of the product owner.

○ It is a way to identify the release strategy.

○ Story Mapping can be a helpful tool when change needs to be embraced.

● Mechanics about how to create a User Story Map.

○ Who? Story Mapping starts with the user.

○ What are the goals to achieve? A journey map for the team including all pain points.

○ How? Identify how to address those pain points.

○ Organizing left to right and top to bottom.

● Examples of Story Mapping and Minimum Viable Product (MVP).

○ Alba shares how she uses Story Mapping in her work as an artist.

● Story Mapping can go wrong.

○ Not knowing how to identify your MVP.

○ Having difficulty identifying opportunities for learning.

○ The what and the why need to be addressed for Story Mapping, not just the how.

○ Having someone with experience in Story Mapping is hugely important for the process to develop the best way possible.

○ There need to be conversations about how Story Mapping will be done.

Mentioned in this Episode:

User Story Mapping: Discover the Whole Story, Build the Right Product, by Jeff Patton and Peter Economy

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, by Lyssa Adkins

Medical Medium: Cleanse to Heal, by Anthony Williams

Lean Enterprise: How High Performance Organizations Innovate at Scale, by Jez Humble, Joanne Molesky, and Barry O’Reilly

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!

View Details

This week, Dan Neumann is joined by his colleagues at AgileThought, Ola Tunde and Lucy Lin. In this episode, they explore the true meaning of Agile Leadership. They dive deep into the core of an Agile Leader, someone who can foster a safe environment where a team feels free to speak up, innovate, and take action. Dan, Ola, and Lucy discuss the value of balancing the left and the right sides of the Agile Manifesto, as well as providing strategies for leaders to become more Agile. This episode contains lots of great analogies, real examples, and valuable book recommendations in the field of Agile Leadership.

Key Takeaways

• Agile thinking needs to pursue the understanding of what motivates individuals.
• • A team must deliver value together in a different way, even though each individual is motivated differently.
  • Motivate people prioritizing autonomy, mastery, and purpose.
• Leadership is the capacity to translate vision into reality.
• • A manager drives people to deliver work with the intention of intimidating them to deliver value, on the contrary, an Agile Leader inspires people in order to deliver value.
  • Inspiration vs. drive; leaders are the ones who inspire others while managers drive people.
  • There are assumptions that consider that leaders know all the answers and that they are who give good orders, but good leaders are those who let the decisions happen where the information is.
• Centralized vs decentralized leadership.
• • There are certain practices that are better centralized, but when the practices involve creativity and innovation, decentralized leadership is of more value.
  • A centralized environment is driven by command and control, no innovation is welcomed in this kind of scenario.
  • In a decentralized environment, the team is allowed to make decisions and fosters innovation.
  • Agile Leadership happens when the leader can celebrate the work of the team.
  • An Agile Leader doesn’t blindly trust a team but encourages teams to create transparency to what is happening.
• Left and right sides of the Agile Statement: There is a need for structure but there is also a part that needs to welcome change.
• • Agile Leadership marinates both left and right together for people to be able to deliver more.
  • Embracing changes is a key aspect of an Agile Leader.
• How can leaders foster an environment where teams feel free to speak up?
• • A safe environment is where people can be free to speak up and discuss and they won’t be punished or criticized for their opinions.
  • A leader must be able to bring people from opposite views together, always manifesting being open to opposing views.
• How do you know if you are an Agile Leader?
• • You are not the boss, you are the servant.
  • A leader must be ready to sacrifice for the team.
  • An Agile Leader is humble, coachable, teachable, and has the ability to inspire others to action.

Mentioned in this Episode:

Drive: The Surprising Truth About What Motivates Us, by Daniel H. Pink

Servant Leadership: A Journey into the Nature of Legitimate Power and Greatness, by Robert K. Greenleaf

Turn the Ship Around!: A True Story of Turning Followers Into Leaders, by L. David Marquet

Leaders Eat Last: Why Some Teams Pull Together and Others Don’t, by Simon Sinek

Mastering Marketing Agility: Transform Your Marketing Teams and Evolve Your Organization, by Andrea Fryrear

HBR Harvard Business Review: “For an Agile Transformation, Choose the Right People:

Identify Your ‘Hidden Stars’ and Other Vital Players”, by Rob Cross, Heidi K. Gardner, and Alia Crocker

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!

View Details

This week, Dan Neumann is joined by six collaborators to this very special episode in which the third year anniversary of the Agile Coaches’ Corner is being celebrated!

In this episode, Ola Tunde, Steve Sladoje, Adam Ulery, Erica Menendez, Andrea Floyd, and Quincy Jordan are sharing their experiences during this last year, they are talking about the challenges and discoveries of working remotely, and how the future looks like now that we all find ourselves living a “new normal” as a result of the COVID 19 pandemic. Special thanks and appreciation to all listeners and collaborators who have been following and allowing Agile Coaches’ Corner to turn three years of age!

Key Takeaways

● Thoughts about remote working.

○ We lived in a virtual world that now is turning hybrid.

○ Sometimes pivoting and changing can be challenging, but the faster you adapt to the changes, the better.

○ There is no replacement for in-person interactions, but seeing people on camera is better than just voice.

● Is the remote nature impeding Agility principles?

○ Face-to-face interaction also includes video.

○ You can still be engaged with customers and stakeholders by being visible and present, they need to know that your productivity hasn’t declined.

● What does trust look like in a remote work situation?

○ Being trusted in remote working is directly related to how you manage expectations.

○ To promote trust increase communication and make sure that your calendar matches it too.

○ Forge relationships with people.

○ Trust is an essential foundation for enabling teams to be self-organizing and self-managing.

● The Agile Manifesto states that the most effective communications are the ones that happen face-to-face, how has this changed in our current reality?

○ Nothing beats the richness of communicating face-to-face, but effective communication can be achieved if we are flexible.

○ There is a need to relook at ways of successful communication, we need to use preexisting enablers and get more creative.

● How have videos helped to enable better communication?

○ Not everyone can use video and still effective communication can be reached.

○ The constant use of screens can challenge our abilities to stay focused and really be present.

● Finding the right place to work remotely can be a challenge.

○ Everyone should have their own designated space to work.

● Where can things go from here? Are we going back to the “traditional” collaboration tools?

○ The technology that was developed and put into practice during the pandemic can be incorporated into the work back at the office.

● How can leadership embrace the “new normal”?

○ We should not hurry into going back to the office since there are plenty of advantages in remote working; communication, collaboration, and effectiveness are reached without the costs, risks, and expenses of working from the office.

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!

View Details

This week, Dan Neumann is joined by Hal Hogue and Erica Menendez, colleagues and consultants at AgileThought.

In this episode, they are delivering a Scary Stand Up as a special edition for Halloween. Get ready for a unique, funny, and terrifying show where they are diving deep into how frightening certain aspects of an Agile life can be, from Daily Scrum to Sprint plannings. Dan, Hal, and Erica are sharing valuable examples and giving great tips and suggestions to enhance the daily work and move towards the set goals in an authentic Agile way.

Key Takeaways

● Facilitating Daily Scrums can be scary!

○ When the Scrum Master is leading a meeting people tend to just focus on them.

○ Understanding the “why” behind the Daily Scrum is crucial.

○ The Scrum Master needs to give the team space.

○ Respecting the time box is necessary.

○ Collaboration needs to take place throughout the day, not only during Scrum meetings.

● The Chickens and Pigs metaphor is outdated, stop using it!

○ There is a danger in using the chickens and pigs metaphor since it creates walls and barriers to collaboration.

○ It has not been in the Scrum Guide for about a decade.

● Instead of too much chattering, a board can be used as a visual tool to help coordinate the plan for the next 24hrs in a Daily Scrum.

○ Remember that a board cannot replace a conversation.

● Scary Sprint Planning! Boooohhhh!

○ Stop bullying someone for a task that is carried over, it is the whole team’s responsibility in the first place.

○ The Scrum values should be embodied all the time.

○ The team is really working towards the Sprint Goal, is not a really big deal if one task is carried over.

○ Remember to define the Why, the What, and the How.

○ Being remote makes the work even more challenging.

● Sprint Reviews can be horrific!

○ A short Sprint Review does not mean it is a good one! Are you considering the reason behind it?

○ Sprint Reviews are great opportunities for feedback, don’t waste them!

○ What is the Increment like? Where does the team want to go next?

○ Everybody should be together in a Sprint Review.

● Embrace your scary stories, this is how you learn and improve!

Mentioned in this Episode:

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, Lyssa Adkins

The Scrum Fieldbook: A Master Class on Accelerating Performance, Getting Results, and Defining the Future, JJ Sutherland

The Reengineering Alternative, William Schneider

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!

View Details

This week, Dan Neumann is joined by two AgileThought colleagues, Andrea Floyd and Hal Hogue.

In this episode, Dan, Andrea, and Hal are talking about the books that have been influential to them and what they learned from them. Continuous learning is a crucial piece of the work at AgileThought, and this is why today, you are invited to this special space called The Book Club.

Key Takeaways

• Books that bring new ideas to the practice:
• • A fairly common book that you should not take for granted: Turn the Ship Around! A True Story of Turning Followers Into Leaders, written by David Marquet. This book brings a great opportunity to reflect on your own role as an Agile Coach, it also delivers an important message on leadership and serving others.
  • Another book referring to work as a servant leader is Team of Teams: New Rules of Engagement for a Complex World, by General Stanley McChrystal. This book shares crucial practices to be more effective with our teams.
  • Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, written by Gene Kim, Kevin Behr, Kim Spafford (a business fable with some great suggestions to the state of growing software companies to scale).
  • The nature of the challenges has changed over time; businesses are seeing more value in being flexible while responding to change and The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done, by Stephen Denning, is a number one must-read book for people experiencing Agile transformations, for them to be considered as holistic opportunities for an organization to create and sustain a shift in its cultures.
  • Agile Project Management with Scrum, by Ken Schwaber, is a great tool that explains the rules and practices for Scrum.
  • The Rational Unified Process: An Introduction, by Philippe Kruchten.
  • The Scrum Guide has some interesting references; this guide has been modified and updated over the years, which is the best proof of the constant need for flexibility and adaptation that lies in the core of Agile Teams.
  • Start With Why: How Great Leaders Inspire Everyone to Take Action, by Simon Sinek. This book is a great one to help teams and leaders recognize the reasons and purposes behind what they are doing.
  • Your Daily Scrum is a YouTube series where you can find (in 10 minutes or less) the answer to a question from the community related to Scrum which is the trigger for an insightful conversation about that topic.
  • Ted Lasso on Apple TV brings awesome content about leadership and humanity.

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!

View Details

This week, Dan Neumann is joined by Justin Thatil and Mariano Oliveti, both AgileThought colleagues. They are addressing today a very important topic, which is how to successfully address individual behaviors that might threaten your team’s performance.

In this episode, they dive deep into three efficiency killers: procrastination, avoidance, and delay, while providing strategies and ways to treat these individual behaviors to effectively achieve teams’ goals and objectives.

Key Takeaways

• When individual behaviors impact team delivery
• • You can’t solve individual behaviors from a team’s perspective.
  • Disruptive individual behaviors can be procrastination, avoidance, and delay.
  • Build to perfection can contribute to delays in delivery.
• How do you spot efficiency killers?
• • A procrastinator might be someone who is very busy but not with meaningful tasks that will help to achieve the sprint goal.
  • Does someone have difficulties sticking to a productivity system?
  • The daily Scrum is a useful tool to spot disruptive behaviors.
  • Make sure there is safety within the team to call on someone who is struggling.
• Which are the strategies to treat efficiency threateners?
• • Identify the root cause.
  • If your to-do list is too long, you can split it into the specific goals you want to accomplish in a day.
  • Prioritization is key! Ask yourself: Is this something I need to do right away? Can it be automated?
  • Do the hardest thing first.
• What happens when it is not clear what needs to be done or what the outcome is?
• • Not starting to work until you have an exact idea of what needs to get done could be a trigger for procrastination.
  • There are intermediate steps too; you do not have to look at the entire journey at once.
• How to seek continuous improvement?
• • True conversations have to take place, especially when there is a failure in delivery.
  • Inspect the process of the work on a continuous basis.
  • Who can solve the problems that are being encountered? Assign responsibilities.
  • Tackle the problems first.
  • The whole team has to work together.

Mentioned in this Episode:

Take the Stairs: 7 Steps to Achieving True Success, by Rory Vaden

Learn more about Life Coaching vs Agile Coaching:

“Coaching and Agile Coaching: Same Same or Different?”

“Agile Coaching vs. Professional Coaching”

“Are Agile Coaches Really 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 Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

View Details

This week, Dan Neumann is joined by Chris Pipito, Agile Coach, to talk about Scrum cling-ons and culture shift.

In this episode, Dan and Chris are talking about the aspects that cling to the Scrum framework and really impede organizations’ ability to shift cultures from where they were to a point where there are more Agile stands using the Scrum structure. Dan and Chris dive deep into the roles of Scrum, the struggles faced when trying to achieve a culture shift, the real purpose of sprint reviews, and how to narrow stories (instead of splitting them) among other valuable inputs on the matter.

Key Takeaways

● The three roles of Scrum: The Scrum Master, Developers, and the Product Owner.

○ Product and Portfolio managers do not exist in Scrum.

○ For anyone who does not fit into these three roles, there is a need to find a place in the organization where the employee’s skills can be applied and are valued.

● What is really a culture shift?

○ The team sizing is an important matter as well as not having the team departmentalized bureaucracy.

○ The necessary organization needs to be in place for different departments to work together.

○ In most organizations, people don’t even read the Scrum Guide and they work with people who don’t have the proper certifications either, then, as a result, the entire experience with Scrum and Agile is not that satisfactory.

● The cling-ons make it easier not to change behaviors.

○ Is the team clear about the reasons why they are building something? What is the goal that the team is looking to achieve? Standardized forms sometimes do not contribute to the overall goal of a project.

○ Are you talking directly with your customer?

○ What is really the point of the Sprint Review? To inspect the increment and respond to the new information.

○ Teams who work on properly-sized stories check on the customer to make sure they are on the right path; this is much better than assuming they are right.

○ Narrowing stories is different than splitting them; you need to keep the overall objective you are trying to achieve as well as all the different things that you will be able to do, then narrowing that to a “happy path” to build it, without missing the core functionality of what you are trying to reach.

● What are the challenges to be confronted in order to make a shift towards Agility in an organization?

○ Regarding departments, the teams’ sizes need to be appropriate.

○ Make sure you look for the skill sets that are needed in each team before just assigning one.

○ Assess the resource allocation fallacy: It’s not about “getting the maximum utilization out of the fungible resources”

○ Tip to try in bigger organizations: One group could be separated and treated as if it is an entire organization and show them the results of what is coming up. Sometimes this might mean keeping “management” out.

Mentioned in this Episode:

The Fifth Discipline: The Art & Practice of the Learning Organization, by Peter Senge

Mob Programming: A Whole Team Approach, by Woodie Zuill and Kevin Meadows

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!

View Details

This week, Dan Neumann is joined by two AgileThought colleagues, Andrea Floyd and Buyi Kalala, to explore the topic of diversity in teams.

In this episode, Dan, Andrea, and Buyi talk about some of the challenges they have encountered in regards to diversity, sharing their observations, and experiences in regards to how diversity can enhance the work of a team but also highlighting the real challenges that come with it.

Key Takeaways

• Diversity: benefits, challenges, and how to promote it.
• • People often make assumptions about looks, accents, and other traits, these are many times not only incorrect but can also hurt and create distance between individuals.
  • Inclusivity is showing people who belong to minorities appreciation and awareness of their unique experiences.
  • Be patient, practice active listening, and find a meaningful way to engage.
• Active listening is the key to promote diversity.
• • Do you really understand what someone just said? Did you give them the space and time to express themselves? Are you working together towards the expected outcome?
  • One trick: While listening, write down the topics you want to reply to, this way you will avoid interrupting the speaker and can also concentrate on what is being said.
  • There is a growth opportunity in highlighting the achievements (instead of focusing on what is still pending or can be improved).
• Some strategies to alleviate the concern of a team member in regards to feeling worthy (especially when belonging to a minority group)
• • Go slowly, you are unique, and your strength relies on it.
  • Every moment can be an opportunity to forge your way.
  • Be aware of where you are in your individual journey as well as in the organization and the team.
• Diversity is a catalyst for innovation.
• • Most innovation can be originated only in a safe environment.
  • People have to feel comfortable to be part of the conversation.
  • Create a pattern in the way you are communicating where people start noticing you, how you speak and engage is important.
• Techniques to create safety in the workplace
• • Make sure each person knows you care about them as human beings, not as functional resources who help to get the process going.
  • Use creativity to create a space where every “who” is valued, respected, and invited to the conversation.
  • Empower teams by encouraging them consistently.