Afleveringen

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

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

  • Zijn er afleveringen die ontbreken?

    Klik hier om de feed te vernieuwen.

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

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

  • This week, Dan Neumann and Justin Thatil are joined by an external guest, James D Murphy, a United States Air Force Veteran, F15 Fighter, and instructed pilot. James founded a company called Afterburner Inc. and is now the CEO of Afterburner Capital; he wrote seven books and is an expert on the Agile Delivery Framework.

    In this episode, they discuss the concept of flawless execution, meaning an execution that is as impeccable as possible (nothing is perfect!). James shares how he combined his military training with his work as an entrepreneur and expert in the Agile framework.

    Key Takeaways

    Flawless execution can’t be perfect; mistakes will take place.

    Start with simple frameworks that are easy and scalable.

    Find purposeful tasks and actions. Developing and effectively communicating the purpose of the Team’s job is crucially important.

    Knowing more about the context and details is essential to prioritize the purpose. Intention and vision need to stay connected.

    The Team needs to be involved in every step of the process.

    The key to flawless execution is to have a common language to get work done.

    The truth is more critical than artificial harmony.

    Teams must foster psychological safety, which means that anyone can feel safe admitting an error without fearing reprimand.

    Building a safe culture takes time.

    Flawless execution needs a systematic approach.

    The system followed must enable good execution as well as flexibility; in this matter, simplicity overpowers complexity. Complexity will decrease performance while augmenting the chance of errors.

    First is the planning phase (who is going to do what and when). Once it’s over, no more brainstorming takes place.

    After planning, the plan is briefed (repetition of what was planned and the accountabilities that come along with it).

    Execute! Don’t get off track.

    Debrief as soon as the mission is over. Debriefing is almost as important as the mission itself, leaving a lesson to the entire enterprise, not just a small Team. Is there a gap between the obtained results and what was imagined and expected from the plan? The Team should ask itself, how did the success occur? And why?

    This entire process must be leader-led. It is the leader who first has to admit his/her mistakes. This transparency and honesty create the much-needed psychological safety at the Tream.

    Learn More:

    Afterburner website Afterburner on YouTube James D. Murphy on LinkedIn

    Want to Learn More or Get in Touch?

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

    Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

  • This week, Dan Neumann and Justin Thatil, your hosts, are joined by Erica Menendez and Mariano Oliveti to discuss what it takes to deliver high-quality Agile Projects.

    In this episode, they dive deep into what a successful Agile project looks like and describe the necessary steps to be taken in order to reach it.

    Key Takeaways

    Clarify the purpose

    The company should have a purpose

    The culture you create should be in support of the purpose

    The products should align with that purpose

    Deeply understand the real needs of your users and meet those

    Adopting Agility can increase employee satisfaction

    Empower team members to take action in support of the company’s purpose

    Empowerment increases engagement

    Engaged and empowered employees tend to lead to happiness.

    Understand that the entire Team works towards a specific goal.

    Focusing on people is a crucial aspect of a successful Agile Project, optimizing the relationship with people, ensuring there is collaboration among them, and granting space for people to open up in a psychologically safe environment.

    Fear of criticism and resistance to feedback are barriers to address.

    Working in an Agile way allows more predictability.

    Agile Teams add transparency to their work and separate tasks into smaller parts, which enables them to look at things a lot more closely than traditional Waterfall.

    Transparency must appear at all organizational levels, having realistic expectations and empowering everyone to make decisions.

    Implement feedback loops. Be willing to pivot based on feedback.

    Foster continuous learning

    Embrace experimentation

    Mentioned in this Episode:

    The Coaching Trading Alliance: Life Coach Training and Certification

    Want to Learn More or Get in Touch?

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

    Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

  • This week, Dan Neumann and Justin Thatil are joined by Erik Lindgren to discuss the concepts of MVP (Minimum Viable Product) and MMP (Minimum Marketable Product) and the differences between them.

    In this episode, they explore an example of a successful brand that started the simplest way possible and became a multimillion-dollar success a decade later!

    Key Takeaways

    Erik shares the story of Honest Tea, which grew into a multimillion-dollar company. They started with the MVP (making tea at Eric’s home to sell later), and ten years later, Coca-Cola bought forty percent for forty-three million dollars.

    What is the simplest way to get to the market fast? Start with the minimum to get on the market and test your idea.

    It is crucial to shift from an existing platform to a new one with the minimum risk possible.

    What is the difference between MVP and MMP?

    MVP: We are unsure if there is a market for this product, who will buy it, and how they will respond to it; for that, you put together a business hypothesis.

    MMP: What is something that the market will really adopt broadly?

    There is a considerable risk in taking the Big Bang approach to a project.

    An integrative and incremental approach seems more effective than redoing the entire ERP system before going live. Grow a system organically instead of trying to do it all at once.

    A team must ensure they know whom they are solving a problem for to focusÂŁ on what matters most.



    Mentioned in this Episode:

    Watch Flamin’Hot Documentary

    Scrum@Scale Framework

    Want to Learn More or Get in Touch?

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

    Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

  • This week, Dan Neumann and Justin Thatil are joined by Rich Hundhausen for the second part of a deep conversation about Nexus. Rich is a software developer, Professional Scrum Trainer, and co-creator of the Nexus Framework for scaling Scrum.

    In this episode, they dive deep into how to deliver value in the form of a working integrated increment of product, the role of the Integration Team, and the characteristics of each Nexus Event. They share valuable stories exemplifying how Nexus works for an improved scaling experience.

    Key Takeaways

    Scale Scrum is still Scrum (plus additional features).

    The Nexus Integration Team is not in the original Scrum framework.

    The Integration Team is actually the Nexus’s Scrum Master. This team is responsible for ensuring that Scrum is followed as established in the Scrum Guide and that its work is effective.

    The Integration Team works in a Scrum way by coaching, facilitating, teaching, and mentoring, but not hands-on (unless absolutely necessary). The Scrum Team’s Developers do the work.

    The Integration Team does not do the integration, but it is accountable for it.

    Integration can mean lots of different things.

    Integration means solving any kind of dependency.

    The Nexus Integration Team does not have to meet daily but only when required.

    Everyone on the Integration Nexus Team has a daily job on the Scrum Teams and/or is the Product Owner, so when something does not go as planned, they bring it to the attention of the Integration Team when possible.

    The Nexus Events:

    First Event: Nexus Sprint Planning. This event aims to take another look at the upcoming work to ensure the organization of Teams and consider any last-minute changes. Big Room Planning takes place during this stage. All the planning at this moment is only for the current sprint (never beyond that). The output for the Nexus Sprint Planning is the Nexus Sprint Backlog for each Team, and the goal is to make any dependencies transparent to mitigate them daily.

    Scrum of Scrums: Scrum Team members are allowed to talk at any given moment.

    Second Event: The Nexus Daily Scrum. It is a Scrum of Scrums that occurs before the Daily Scrum. At this mandatory event, dependencies and integration issues are discussed.

    Third Event: The Nexus Sprint Review is where Stakeholders give feedback on the done increment but in a big room event. This event is the time to share feedback on potential cross-team work.

    The Last Event: The Nexus Sprint Retrospective. This event is an opportunity for the Scrum Team to inspect and adapt how they work, first through a pre-meeting with the representatives, then Teams have their individual retrospectives, and after, representatives meet again to make transparent any new experiments or improvements so the bottom-up intelligence can then be shared with the other Teams.

    There are around 60 complementary practices to Nexus (but none are new).



    Mentioned in this Episode:

    The Nexus Guide

    Listen to “Continuous Learning: Professional Scrum Facilitation Skills Training with Patricia Kong” and “The Nexus Framework for Scaling Scrum with the Scrum.org Team”

    Want to Learn More or Get in Touch?

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

    Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

  • This week, your hosts, Dan Neumann, and Justin Thatil, welcome an external guest, Rich Hundhausen, software developer, Professional Scrum Trainer, and co-creator of the Nexus Framewokr for scaling Scrum. This episode is the first of two parts, in which they discuss the features of Nexus and when and how to implement it.

    Listen to this episode for a description of Nexus, how it started, and why it was developed. Rich, Dan, and Justin also dive deep into the definition of scaling, what is considered done, and the Nexus goal. Stay tuned for part two!

    Key Takeaways

    Why do we have a Nexus Scaling Framework?

    Rich started working with Ken Schwaber, co-creator of Scrum, in 2009. Together, they created Scrum.org, “The home of professionals.” They later became interested in Scaling according to the Scale Agile framework.

    Are you really in a situation where you need to scale?

    Rule number one when scaling is “Don’t.” Let your Team tackle the problems first. Always start small and add as needed.

    What is Scaling?

    Scaling is simply one product owner and backlog and multiple Scrum Teams. Everything you learned about Scrum for a single Team still applies at Scale with the Nexus. Additional features, such as the exoskeleton, are required for scaling.

    The number one reason to build Nexus was for dependencies on different areas (not only technical). Refinement has been a proof practice at single-team Scrum, and at Nexus, it has become a required event called Cross Team Refinement.

    What is the definition of Done?

    Everyone at Nexus is a creative person, and these people are motivated when they have space to implement their creativity. All Teams should have autonomy, purpose, and the ability to master their actions. Each Scrum Team can have its definition of done, but it has to stay on top of the unified set of items that the other teams share.

    The Nexus Goal: Do everything you committed to in the product backlogs.

    Mentioned in this Episode:

    “Shu, Ha, Ri” Episode of The Agile Coaches Corner.

    Dan Pink’s books and TedTalks

    Want to Learn More or Get in Touch?

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

    Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

  • This week, Dan Neumann and Justin Thatil are joined by Erik Lindgren to discuss scope creep, a term that everyone working in software development knows well. The expression refers to adding further features or functions of a new product, requirements, or work that is not authorized.

    In this episode, they dive deep into the challenge of managing timelines and budgets and how frequently a Team can find itself off-track, which is undoubtedly an uncomfortable position. Erik, Dan, and Justin discuss the importance of prioritizing properly, including possible improvements and requirements. Scope creep can be a learning opportunity waiting to be embraced by the Team!

    Key Takeaways

    Scope Creep in an Agile environment:

    In an Agile setting, new ideas must be added to the backlog for them to be prioritized. Once in the backlog, it is necessary to decide whether it is a high priority or not.

    The stakeholder and client must know about the additional items so they can contribute to the Team in deciding what needs to be included and what can stay out. The involvement of the stakeholders can often be challenging for Agile Teams.

    What is the most valuable idea to be implemented now? The fact that some ideas are not prioritized at a particular moment does not mean they won’t ever happen; they can take place at a different time.

    Keeping open communication with stakeholders can sometimes be a challenge.

    Often, Teams don’t want to feel “exposed,” which is why they withhold certain information.

    Teams must share vital information with the customer; they can only tell what is essential for them.

    The “all or nothing” delivery threatens adequate time and budget management.

    A Team must focus on delivering new increments of value while balancing the inclusion of innovative features.

    Wanting to achieve everything on the backlog and additional items might be unrealistic; something must come out.

    Scope creep can be avoided with collaborative delivery. It can be a learning experience for the Team!

    Want to Learn More or Get in Touch?

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

    Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

  • This week, Dan Neumann and Justin Thatil discuss Agility: How do you know if you truly are in an Agile environment? In this episode, they explore the meaning of Agile and the different features that make this framework unique, including Creativity, Teamwork, Mindset, Continuous Learning, and Psychological Safety.

    Key Takeaways

    Does Scrum allow creativity?

    The Scrum framework was designed for complex situations where creativity is necessary since there is no “one right way” to solve a problem.

    What does it really mean to be Agile?

    Agile: Able to move quickly and easily. In the Agile framework, this is a constant guideline; the decisions must flow quickly and easily.

    Autonomy is crucially important. Teams need to be self-sufficient to deliver value.

    Inspecting and adapting the plan is necessary since a budget needs to be respected.

    Agile Teams deliver value throughout the process.

    Agile is about an actual team working on an actual problem (thinkers and doers are not working separately on finding solutions).

    Agile mindset vs a fixed mindset:

    Agilists learn by doing rather than over-analyzing before taking action.

    Every Agilist is part of a Team working towards a goal, not a solo player.

    By attending their daily Scrum, you can tell if a team is only Agile by name. They always work as a team rather than as individuals doing their jobs.

    Alignment! What is really the Team’s approach?

    What is the business opportunity the Team is trying to reach?

    Effectively managing budgets can enable Agility

    Continuous improvement:

    There is no lifetime commitment to a particular decision. Instead, adjustments are made according to the needs.

    Value progress over an attempt to design for perfection

    Encourage ongoing learning

    Psychological safety needs to be modeled within the Team, and a context of continuous improvement allows space for speaking up and accepting failures to readjust the course of action.

    Want to Learn More or Get in Touch?

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

    Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

  • This week, Justin Thatil is joined by two of his Agile colleagues, Mike Guiler and Mariano Oliveti, to discuss the tiredness and frustration that can sometimes be caused by following the Agile process. Some organizations can even be convinced that Agile did not work for them; how can this wound be healed?

    Key Takeaways

    Some organizations are sure that Agile didn’t work for them.

    Sometimes, these organizations tried some Agile ways but never started from the beginning.

    Was “moving faster” all the organization wanted? If you don’t adapt the values and behaviors, Agile will not be guaranteed to speed up the process. First, the organization needs to change its culture.

    These organizations might need to consider that Agile is a process, a hard process.

    Today’s transformations are different from what they were ten years ago.

    Benefits of Agile:

    Many organizations need help with accountability, while Agile proposes an excellent method to ensure it.

    Agile is a way of approaching organizations to figure out what they can do for them based on their current needs.

    Agile is the approach that assists an organization in transforming its culture into a long-lasting, durable one with self-managing teams that achieve the desired outcomes.

    Doing Agile vs. Being Agile:

    Doing Agile is about going through the motions and checking the boxes, but, for being Agile, it is critical to change the culture.

    There has to be a need for change in the Organization, otherwise, Agile would not work.

    Mentioned in this Episode:

    The Five Dysfunctions of a Team: A Leadership Fable, by Patrick Lencioni

    Overcoming the Five Dysfunctions of a Team: A Field Guide for Leaders, Managers, and Facilitators, by Patrick Lencioni

    Want to Learn More or Get in Touch?

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

    Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

  • This week, Dan Neumann and Justin Thatil are joined by an external guest called Rich Visotcky, President and Founder of Joint Insights, who is passionate about creating shared understanding. Rich is a Professional Scrum Trainer with Scrum.org.

    In this episode, they explore the topic of cultural impact on transformation. We work in and for organizations that include several different cultures; this imposes challenges, resistances, successes, and opportunities to be seized, as well as other strategies to be used for better performance and communication while on the path of transformation.

    Key Takeaways

    It is essential to know what is foundational for each company and how it has contributed to its success.

    Leadership can be the drive to success, but it is the culture that guides the Team to achieve its goals.

    The first step for transformation is to find what the organization truly values.

    Making changes doesn’t mean losing who we are.

    Sometimes, it is necessary to take risks.

    The fear of doing something wrong can keep a Team from trying new paths.

    Self-management cannot be prioritized at the expense of accountability.

    Self-management does not mean anyone can do whatever they want.

    A Team needs boundaries (but not too many).

    A Team’s success can be found in the balance between self-management, accountability, and well-executed boundaries.

    Changes need to be aligned.

    Leaders must communicate why the changes are important and back them up; they must often highlight what they are working towards. The company’s values must be used and reminded throughout the entire change path.

    There can be two or three simultaneous initiatives to avoid confusing people with many variables.

    Conflict is inherent to the process.

    Attributes for a company to be truly Agile:

    Cooperation.

    Speed of decision making.

    Engaging in Trials.

    Empowerment.

    Technology adoption.

    Simplicity.

    Knowledge sharing.

    Innovation focus.

    Want to Learn More or Get in Touch?

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

    Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

  • This week, your host, Dan Neumann, is talking about a prominent topic: are the times of remote working about to end? Today, he is solo hosting this episode to assist you in navigating this new trend and successfully surviving these changes.

    In this episode, Dan discusses hybrid work and the trend of returning to in-person work. He shares some strategies to help Teams thrive in this new work scenario. Things are changing rapidly in this evolving landscape, and several companies require their staff to return to the office; listen to this episode and get some valuable ideas on adapting and succeeding in this ever-changing world.

    Key Takeaways

    The pandemic brought the remote working environment as a solution to many problems.

    For many companies, remote working was not a choice; it was a matter of business survival.

    Some benefits of remote working are time and money savings, freedom, and flexibility. Also, companies can attract more talent remotely.

    The ability of companies to innovate was hindered by remote work.

    Tips to work better in a hybrid environment:

    The benefits of a hybrid working environment are the flexible location to perform a job and the possibility of choosing which hours someone would decide to work. These aspects imply both synchronous and asynchronous communication.

    There can be a communication barrier between the in-work and remote workers; more spontaneity occurs in the office. Lacking non-verbal cues of remote communication can affect its effectiveness (video can help, but it is undoubtedly less accurate than in-person communication).

    Remote work promotes more isolation, less communication outside of the direct work area, and fewer additions of new members to Teams.

    Being onsite increases the opportunity to connect more to people in general, including those not strictly in our areas of expertise.

    There is a need to establish explicit Team norms (Make them visible!).

    When hybrid communication occurs in a Team, you must explicitly make room for the remote worker.

    What are your Team’s agreements regarding responding to messages?

    Good calendar hygiene is a factor that enables good remote communication.

    Communicating clearly how a decision will be made can be challenging in a hybrid working environment.

    Decisions are not made arbitrarily; ensure what will be decided and how.

    Use mirroring for collaborating with the Team.

    Mentioned in this Episode:

    Business Insider: “The remote work era may be coming to an end — if companies can afford to keep their offices open”

    “How Remote Work Affects Our Communication and Collaboration”

    Want to Learn More or Get in Touch?

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

    Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

  • This week, Justin Thatil, your host, welcomes Quincy Jordan and Pamela Dukes, Olympic Athlete and Agilist, who engage in a thoughtful conversation regarding how these two areas of expertise intertwine and how the abilities applied to professional sports enhance her role as an Agilist.

    In this episode, you will learn about Pamela’s journey as a professional athlete, the lessons learned, and the challenges that brought the knowledge that enriched her experience in the Agile arena.

    Key Takeaways

    Pamela shares her most significant lessons as an Olympian and Hall of Fame athlete:

    “What got you here will keep you here.” You don’t need a Herculean effort to go on; you just have to stay consistent.

    The Team has to support each other. If you are not competing, you are busy cheering for someone else.

    Quincy, who also went through his athlete years, brings two of the most meaningful teachings he obtained from his coach:

    All the way through (you don’t stop until you are done).

    Run your race (stay away from comparisons).

    The Scrum framework mirrors the structure of College Athletics.

    The Head Coach was the Chief Product Officer, and his assistants were the product officers.

    The Scrum Master was the Team captain.

    The plans set for training could be weekly, monthly, or yearly, and once arranged, that was the guideline the athletes follow every day. Everyone knew the plan, but when circumstances changed, the plan was adjusted accordingly. These dynamics work similarly in Scrum; there are planned sprints and releases.

    At the end of each week, they would do competition drills where performance was tested (which looks like a sprints review) followed by a talk, reflecting on what could be improved (a lot like retrospectives).

    Get the lead, keep the lead.

    It is easier to do well and keep doing well than getting into a technical or cultural debt and getting out of it.

    Empower your Team:

    The success criteria should be how well you teach others.

    Practicing skill sharing is critically important.

    Leaders should walk away from the dangerous “hero complex”; a true leader teaches others how to do what they do.

    No one is particularly responsible; a Team succeeds and walks through challenges together.

    Each Team member has to do their part for the entire Team to reach the goal.

    Want to Learn More or Get in Touch?

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

    Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

  • This week, Dan Neumann and Justin Thatil are joined by Misi Eyetsemitan. In this episode, they discuss the future of Agile, the advantages and challenges they see, and how far the Agile Methodology has come in the last two decades since its origins when it was created to achieve better and more efficient software development.

    Listen to this episode and learn more about where Agile is going.

    Key Takeaways

    The Agile Manifesto was not created rigidly but was open for future updates.

    Agile evolves powered by the problems that exist today.

    The execution of Agile will remain applicable in the future.

    In the future, Agilists will have to revisit the basics of Agile.

    Future Agilists will have to know why they have chosen Agile and why they are leveraging Agile. Agile is never the solution but brings organizations to the solutions they seek.

    Agile requires to have a transformative mindset.

    What are some challenges in the future of Agile?

    It will depend on the response of the Agilists. Agile is not a one-size-fits-all kind of methodology. The principles of Agile can be applied in various ways to tackle different problems.

    Measuring the value an Agile Team delivers is still a challenge.

    The key is to keep the focus on value. There are many ways to quantify value delivery.

    It is difficult for organizations and Teams to identify the metrics to measure what success looks like.

    The future of the diversity of Agile Teams:

    Agile Teams will continue to be more diverse.

    Diversity will also be needed to solve more complex issues.

    Mentioned in this Episode:

    Learn more about Systemic Coaching

    Check the courses offered by the International Federation of Coaches

    Want to Learn More or Get in Touch?

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

    Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!

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

  • 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.

    2. Address bottlenecks.

    3. Minimize handoffs and dependencies.

    4. Get faster feedback.

    5. Work in smaller batches.

    6. Reduce queue length.

    7. Optimize time “in the zone.”

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

  • 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:

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

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

    2. Scope Management:

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

    - Six rules discussed:

    1. Everything goes in the backlog.

    2. Prioritize with the client or internal stakeholders.

    3. Provide estimates.

    4. Maintain transparency.

    5. Nurture what's not in scope.

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

    3. Importance of Communication:

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

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

    4. Reminders for Development Teams:

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

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

    5. Cost and Context Switching:

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

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

    6. Discipline in Agile:

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

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

    7. Continuous Learning:

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

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

  • 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 [email protected] 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