Agile Coaches' Corner

So you want to be an Agile Coach, huh? This week on the podcast, return guest, Christy Erbeck, is going to tell you everything you need to know if you’re looking to be a coach!   In case you haven’t caught Christy on a previous episode, she is a Principal Transformation Consultant at AgileThought and a Certified Dare to Lead™ Facilitator. She has over 25 years of experience in domestic and international consulting, training and coaching, and working in both software development and non-product-focused environments, including manufacturing (discrete and process), distribution, and sales and marketing.   Christy and Dan discuss what a coach is, what it takes to be a coach, how to become a coach, how to know when you are a coach, the differences between a coach and a trainer, as well as some coaching anti-patterns!   Key Takeaways What is a coach? It is a passion and mindset As a coach, it is your duty to bring out the best in your team — you’re there to see what others cannot see Someone who delivers value to your clients by creating and improving Agile processes within a team What does it take to be a coach? The ability to hold space for others to discuss tough subjects A strong combination of hard and soft skills are required Hard skills would be your ability to think strategically and tactically; clearly communicate up, down, and across the organization; your ability to tell the truth (even when it’s the last thing people want to hear); and to have real-world experience where you were not the coach Soft skills would be a healthy sense of self, strong personal boundaries, the ability to empathize with others, a playful spirit, and natural curiosity You should have had the proper training (for example: through CoachU or Lyssa Atkin’s SolutionsIQ) Another important soft skill for a coach is to be the ‘wind behind their wings’ by releasing your ego and allowing the person you are coaching to be front stage How to become a coach: A new Scrum Master can experiment with coaching their team and should be there long enough to build a depth of experience — both good and bad to build a library of experience from A coach should see multiple success and failure patterns It’s important to have a strong foundation of your strengths and weaknesses, know how you’re going to respond to different situations, know what might trigger you in a setting, and to do ‘your work’ before coaching others to do ‘their work’ It’s important to not assume everyone else has the same success and failure patterns and experiences as you When you’re walking into a new team as a coach you should always have a beginner’s mind (i.e. the perspective of being fully present in the moment and not projecting on historical experiences) Anti-patterns of coaching: Sending in a coach only when a team needs the help When a manager is considered a coach of an employee (which sets both parties up for failure and is a conflict of interest) Coaches that do not see their coachees as equals Difference between a coach and a trainer: A training stance would be that you are the expert in the given topic and those you are teaching are novices Trainers impart knowledge to the trainees in a way that they can apply and grow from it A trainer’s primary skill is to teach In a coaching stance, you are there to help coachees uncover what they need to learn in order to become their best selves A coach’s stance is not to be an expert in the person they teach; the person they teach should be the expert of themselves (a coach is just helping a person create space to allow them to follow and blossom) How do you know when you are a coach? What should you continue to do? As a coach, you should seek continuous improvement and adopt a lifelong learning mindset You should continue to improve upon your hard and soft skills If you want to be a coach, get a coach! Understand that this is a journey Ultimately, you will know when you’re ready to become a coach   Mentioned in this Episode: Christy Erbeck Agile Coaches’ Corner Ep. 68: “Fixing Your Scrum with Ryan Ripley” Fixing Your Scrum: Practical Solutions to Common Scrum Problems, by Ryan Ripley and Todd Miller Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, by Lyssa Atkins Flawless Consulting: A Guide to Getting Your Expertise Used, by Peter Block Becky Hartman #BecauseHumanCoachU SolutionsIQ Agile 2020 Brené Brown   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!

In this bonus episode Christy Erbeck and Dan Neumann discuss some of the work impact from COVID19 and share some of their coping mechanisms.    Want to Learn More or Get in Touch? If we can help coach you or your organization, contact us at podcast@agilethought.com and we'll connect you to the right folks at AgileThought.  Visit the website and catch up with all the episodes at AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

In this episode of the Trainer Talk supplemental series to the Agile Coaches' Corner Podcast, Professional Scrum Trainer Eric Landes answers the question "Can Scrum work with remote teams?"   Want to Learn More or Get in Touch? See available training courses at agilethought.com/training. Visit the website and catch up with all the episodes at AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

This week on the show, Dan Neumann is joined by Jorgen Hesselberg! Jorgen is the author of the new book, Unlocking Agility: An Insider’s Guide to Agile Enterprise Transformation, as well as the co-founder of Comparative Agility — a leading Agile assessment and continuous improvement program.   This episode will be focused on data-driven continuous improvement. Jorgen shares the main reasons to use data to drive continuous improvement, some of the main ways to gather data (and why these methods are used), and important pieces to keep in mind when implementing changes to your team and organization through the data you collect.   Jorgen has a lot to say about this topic as a co-founder of a leading Agile assessment and continuous improvement program so you definitely don’t want to miss his insights and key takeaways!   Key Takeaways Why use data for continuous improvement? Data can help guide you and your teams by asking better questions as well as shining a light where there otherwise would be darkness Helps you reflect on what you’re doing and what you can do better; data helps guide these conversations Optimizes workflow by making the feedback loop faster so you can take action more quickly and therefore see results faster As a change leader, data can help you find out where you can be of most use to help your teams What are some ways to gather data for continuous improvement? And why are these methods used? Objective data (defects in production, trends, etc.) Surveys, even though very subjective, can also be very useful because they can hit some important patterns of ways of working (i.e. psychological safety was discovered through a survey) and highlight other points that wouldn’t naturally come up in conversations because they create anonymity and give everyone an equal voice Structured interviews Gathering data — whether it’s through structured interviews, subjective data, or collecting data electronically — helps to shorten feedback loops What is important to keep in mind when using data for continuous improvement? Subjective, objective, and quantitative data are all great — as long as the data helps you and your team ask better questions, that is the main goal As a coach or change leader, it is important to ask meaningful questions that highlight the issues and challenges your teams are facing and to give them a voice Don’t implement changes all at once that you have gathered from the data because you and your teams will become overwhelmed and end up making no changes (i.e. because you are diluting the focus and creating confusion; people don’t have time to adjust too many different things at once) An important facet to making change based off data is to change at a rate where you can see it ripple through the organization Combine subjective data with objective data Measure technical debt simply by asking your developers Listen to data early on and refresh it periodically to stay ahead of the curve Don’t continually ask your developers how they’re doing — they’ll get annoyed! Understand what ‘normal’ benchmarks are for your niche Data isn’t going to give you answers but it is going to help you ask better questions Use data for information, not evaluation   Mentioned in this Episode: Jorgen Hesselberg Unlocking Agility: An Insider's Guide to Agile Enterprise Transformation, by Jorgen Hesselberg Comparative Agility The Agile Manifesto “Psychological Safety and Learning Behavior in Work Teams,” by Amy Edmonson Mood Marbles Daniel H. Pink Books Strava Agile Coaches’ Corner Ep. 58: “How to Get Past the Two-Week Shelf Life of Your New Year’s Resolution”   Jorgen Hesselberg’s Book Pick: Blueprint: The Evolutionary Origins of a Good Society, by Nicholas A. Christakis   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

This week on the podcast, Dan Neumann is joined by Ryan Ripley! Ryan is a Professional Scrum Trainer, the host of the Agile for Humans podcast, and the co-author of the new book, Fixing Your Scrum: Practical Solutions to Common Scrum Problems.   Together, Dan and Ryan dig into his new book to uncover some of these common Scrum problems that hold back teams and what a Scrum Master can do to find them and help their teams get back on the path to delivery. Fixing Your Scrum is all about the steps you can take as a Scrum Master to transform your Scrum practices, bring life back to your Scrum events, and use Scrum as a competitive advantage for your organization.   Tune into this episode to hear all of Ryan’s insights and highly practical (and actionable) tips regarding the Scrum framework!   Key Takeaways What does Fixing Your Scrum set out to accomplish? What does it cover? Helps Scrum teams inspect and adapt the way they’re working and to discover ways that they can improve Aims to help Scrum teams solve common problems Focuses on practicality and actionable steps; it’s not another theoretical tome It’s not about defining agility but rather how to use the Scrum framework to position your teams to have a shot at agility The book provides ideas and structures; it’s not super prescriptive (i.e. Ryan and Todd take a consulting approach rather than a “thou shalt do this…” approach) Aims to provoke discovery with suggestions It is aimed at the Scrum Master to hone their craft What is the 15% solution approach? The approach emphasizes not getting overwhelmed with the big things but rather to move the needle a little bit in the direction you want to go It’s about discovering what your next step is (that could lead to something impactful) instead of trying to plan out the next thousand steps which are going to change as you get feedback, anyway Anti-patterns: Diminishing the Scrum Master to an administrative role (they’re supposed to have an impact on the way that the teams are using Scrum and how the organization is using agility) A commitment to deliver on a specific set of product backlog items in a sprint (there should be a sprint goal that you hold sacred rather than a commitment to a bunch of backlog items) Change, change, change all at once (changes need time to bake in to ensure that they’re effective) Teams that are a group of loosely associated people rather than a truly collaborative group working together Important notes about the Product Owner role and the product backlog: There’s a misconception about the product backlog that it just needs to be posted somewhere to be transparent, but transparency means whole-team understanding (which requires refinement, continual collaboration, and whole-team discussions) Go beyond visibility by making sure the product backlog is fully understood by the whole team (by continually refining, enhancing, and sharing your understanding of the product) The product backlog should represent the future vision of the product Ruthlessly delete old/unnecessary product backlog items (product backlog items shouldn’t be treated like inventory so don’t be afraid to delete [if it’s a good idea it will come back]) Shift the language around the product backlog — it’s more of a forecast; not a commitment The importance of implementing Scrum values: Scrum values change behavior Without them, every practice that Fixing Your Scrum recommends becomes rote By bringing Scrum values in, you’re honoring the human side of the work If you bring them forward correctly, it brings life to the framework When the values are present, agility becomes possible   Mentioned in this Episode: Ryan Ripley’s Website Ryan Ripley’s LinkedIn Ryan Ripley’s Twitter Fixing Your Scrum: Practical Solutions to Common Scrum Problems, by Ryan Ripley and Todd Miller The Pragmatic Bookshelf Woody Zuill Quote   Ryan Ripley’s Book Pick: Only Joking: What’s So Funny About Making People Laugh? by Jimmy Carr and Lucy Greeves   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

This week on the podcast, your hosts, Dan Neumann and Sam Falco, will be exploring the Nexus Framework. Joining them is Kurt Bittner, Patricia Kong of Scrum.org! In their roles at Scrum.org, Kurt is the Vice President of Enterprise Solutions, Patricia is the Product Owner of Enterprise Solutions, and Dave West is the CEO. Together with Dave West, CEO of Scrum.org, they are co-authors of the book, The Nexus Framework for Scaling Scrum: Continuously Delivering an Integrated Product with Multiple Scrum Teams, which is also the topic of today’s episode!   Together, Kurt and Patricia provide a thorough introduction to the Nexus Framework and take a deep dive into some of the facets of it. They explain many of the whys and the hows around it, debunk some of the common misconceptions, and share how they resolve some of the common problems that sometimes pop up.   Key Takeaways What is the Nexus Framework? It aims to address the main problem of how to coordinate across multiple teams delivering one product When you start to scale up the number of teams involved, questions arise, which Nexus helps to address Its main focus is on teams and the products Nexus aims to help the organizational change problem (regardless of the practices being introduced) It helps people apply Scrum in a larger context and addresses scaling-specific issues Can you implement Nexus without Scrum? What happens if you implement the framework without doing Scrum well? There are lots of ways to fall down with Scrum — Nexus won’t make or break it You should learn how to do Scrum well before implementing Nexus If a set of teams isn’t doing Scrum well, there are scaling techniques that you can apply How the Nexus Framework works: Multiple teams work to build one integrated increment at every sprint (usually three to nine teams) There’s one Product Owner with one product backlog There is a Nexus sprint backlog, which is a representation of and transparency around the dependencies that the teams might face Teams still have their daily Scrums but there is a Nexus daily Scrum before that so the unit can come truly come together, understand the current issues, and properly plan ahead There is only one Nexus sprint review as opposed to the individual sprint reviews you would see in Scrum (because of the emphasis on the integrated product) After the review, you have the Nexus retrospective where the appropriate people come together to address the current issues and find solutions There is also the Nexus sprint goal, which is a culmination of what the teams are doing as a Nexus for the sprint There’s a new role called the Nexus Integration Team, which consists of a Product Owner, a Scrum Master, and Nexus Integration Team members to ensure the integration of the Nexus With no Product Owner hierarchy, how does one Product Owner handle multiple teams vs. single team Scrum? Understanding that they’re not looking for different job titles; it’s about a role Clear communication about autonomy “One Santa, many elves” i.e. there may be one person that is responsible for the product being successful but they can have lots of help Make sure that the teams understand what the goal that is being worked towards is   Mentioned in this Episode: Kurt Bittner Patricia Kong Scrum.org The Nexus Framework for Scaling Scrum: Continuously Delivering an Integrated Product with Multiple Scrum Teams, by Kurt Bittner, Patricia Kong, and Dave West Ken Schwaber Scaling Scrum with Nexus (Scrum.org) Nexus Framework Poster (Scrum.org) Evidence-Based Management Mike Rother   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

This week on the podcast, Dan Neumann is joined by his co-host and colleague, Sam Falco. They are joined by special guest, Gene Gendel, an Agile Coach, Trainer, and Organizational Design Agent. He is a proud member of the Scrum Alliance Certified Enterprise Coaches (CEC) and is Certified in Agile Leadership (CAL), Large Scale Scrum (CLP-LeSS), and Scrum @ Scale (S@S). Gene’s focus is on helping organizations and teams with improving system design and organizational structure and overall efficiency — which he engages in at all organizational levels (senior leadership, mid-level management, teams, and individuals.)   Today, Dan, Sam, and Gene will be exploring the Large Scale Scrum Framework also known as LeSS! They’ll be giving an overview of the framework, going over some of the lesser-known aspects, debunking some of the misconceptions around it, and highlighting the types of organizations and organizational challenges it is best suited to address. Gene also provides many key insights and tips for the framework!   Key Takeaways What is Large Scale Scrum (LeSS)? It was initially called LSS (with the ‘e’ added later because “less is more!”) It is Scrum It is not multiple teams doing their own, independent Scrum; It is multiple teams working in the same Scrum, for the same Product Owner, on the same wider defined product, on the same cadence An organizational design framework It is not a way to scale up or make things more complex It is often referred to as a de-scaling framework as it requires the removal of organizational overhead in order to scale up Agility Highlights organizational problems and asks you to solve them How to address fear and resistance when it comes to implementing LeSS: Mid- and first-level management can be resistant to anything that is bringing about change or uncertainty — but not to worry: LeSS will not change your organization in a broad and shallow way; it is meant for deep and narrow organizational changes that take months to years to succeed The type of organizational challenges LeSS is best-suited to addressing: When the organization needs to get many teams working in the same direction to deliver on a project, product, or significant capability How does LeSS help teams coordinate across their boundaries in order to pull together in the same direction? Since there is so much transparency and visibility between the various teams in various channels with LeSS, there is almost no additional need to coordinate outside of those events Every team in a LeSS product group is almost a clone of another team Other important aspects of the LeSS framework: It is highly encouraged to communicate in-person with one another The Scrum Master is a full-time role (if a company implements LeSS they should be prepared to go to HR and makes sure that a Scrum Master is entered into the database as a role on par with any other role) LeSS managers are capacity builders, not task managers LeSS introduces a concept called ‘undone work’ which is a necessary evil at the beginning steps of LeSS reduction (the goal of LeSS is to shrink the undoneness to null over time) The LeSS framework wasn’t created reactively to meet market demand; it was very proactive and has almost a decade of experiments and experiences documented behind it In order for a LeSS product group to be formed you need to properly define the product   Mentioned in this Episode: Large Scale Scrum (LeSS) Larman’s Laws of Organizational Behavior The Scrum Guide The Green Book: Collection of Independent Essays About Agility, by Gene Gendel   Gene Gendel’s Book Picks: Taiichi Ohno’s Workplace Management, by Taiichi Ohno Large-Scale Scrum: More with LeSS    Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

This week on the podcast, Dan Neumann is joined by his collaborator Sam Falco and special guest, Michael McGreevy! Michael is an Enterprise Agile Coach at Grow Financial and is a Certified Scrum Professional, Agile Leader, and Scrum@Scale Practitioner.   A couple of episodes back, Christy Erbeck shared some of her beliefs and understanding around the scaled Agile framework, SAFe. That fascinating conversation led hosts Dan and Sam along a journey to discovering other scaling frameworks. So, in today’s episode, they’re continuing their conversation around scaling and taking a look at Scrum@Scale! Michael explains some of the basics of Scrum@Scale and shares his own experiences with the framework, Agility, and scaling in general within his professional work at Grow Financial.   Key Takeaways Challenges Around Scaling: It is unique to every organization Too prescriptive of a framework can become its own impediment How these challenges can be addressed: You don’t have to use all of a framework; just what is necessary Benefits to Scrum@Scale/Why Grow Financial is using elements of the Scrum@Scale framework: It brings their teams together to get things done more effectively Helps to create transparency throughout the organization It is more simple than other frameworks It introduces concepts for people who might not know how to start scaling Creates complete alignment between all teams Supports information flowing both ways (from the “lowest” teams under the development scale all the way up to the enterprise team) It also supports information flow laterally (i.e. between the software teams and marketing teams) There’s ambiguity with the framework so success can be determined by the teams and enterprise More visibility into what all teams are doing and how it impacts other teams Creates more transparency (which is key in transformation as it helps to not let any teams lag behind) Possible challenges with Scrum@Scale: Because the framework is so simple it is somewhat vague and difficult to get right; there isn’t a clear path to success You need to make sure that everyone in the organization is on board and understands it Michael’s advice on scaling: Don’t get too prescriptive with any one framework — give it a try but be willing to adjust aspects of it or be okay with moving on to trying something else   NEW SEGMENT! Listener Q&A: Q: Janis, a Scrum Master at Fidel (a growing fintech startup from the UK), describes how their company is currently in a fast-growth and global expansion phase where they’re expanding from a single agile team to multiple teams. They ask Dan and Sam to talk about the dilemma of letting the devs do code reviews for other teams vs. keeping code reviews inside the team.   A: It’s good that Janis is interested in making sure that the knowledge of the codebase remains strong across the team and that the knowledge does not get fragmented and siloed. However, there are more than two options to explore. Here are some other ways for Janis to have a richer conversation with their team about how they might foster shared knowledge amongst team members as their teams grow: Pairing, Promiscuous Pairing, Mob Programming, Team Reviews/Inspection/Walkthroughs, and Unit Test Automation.   If you have a question you would like to send in, email Podcast@AgileThought.com or tweet using the hashtag #AgileThoughtPodcast!   Mentioned in this Episode: Michael McGreevy Grow Financial Agile Coaches’ Corner Ep. 61: “Christy Erbeck Busts Myths About the Scaled Agile Framework (SAFe)” Scrum@Scale Scrum of ScrumsScaled Agile Framework (SAFe) Crucial Conversations: Tools for Talking When Stakes Are High, by Kerry Patterson, Joseph Grenny, Ron McMillan, and Al Switzler Agile Coaches’ Corner Ep. 45: “The Benefits of Mob Programming with Chris Lucian”   Michael McGreevy’s Book Pick: The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done, by Stephen Denning   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!

In this week’s podcast, Dan Neumann is speaking with Charlie Guse, the lead organizer for the Global Game Jam event in South Bend, Indiana. And today, they’re talking about going from zero to game in 48 hours!   With Agile teams — especially Scrum teams — they’ve got the notion of creating an increment within a timebox in Scrum between 1-4 weeks. Though this event is only 48 hours, there are many similarities and overlaps with one another. So in today’s episode, Charlie talks about how they go from zero to game in 48 hours and the facets of Game Jam that translate back into the work software developers do in their day jobs!   Key Takeaways What is the Global Game Jam? A global event where everyone starts at the same time and has 48 hours to create a game based on a certain theme (this year’s theme is “repair”) A great way to meet new people and have lots of new ‘aha’ moments! Not a competition How the Global Game Jam overlaps with day-to-day software development: Having a theme/concrete idea to rally behind makes it easier to make informed decisions about building stuff and helps everyone come together and contribute ideas A framework was developed for this year’s event so that next year they can iterate on the framework based on the feedback they receive There is an emphasis on trying to find what each person’s interests are and having them focus on those as opposed to ‘shoving’ them into a position based on their availability, skill, and need Cutting scope for the timebox (i.e. working together to find the core of what you’re trying to do and cut the excess until you have a core you can deliver on) If people are spread out in their own rooms there is less collaboration so open areas are better There is rapid prototyping, iterations, and cycles Lots of opportunities for networking and making connections   Mentioned in this Episode: Global Game Jam Charlie Guse Kintsugi AWS Lambda EVE Online   Charlie Guse’s Book Picks: Reamde, by Neal Stephenson   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

This week, Sam Falco is hosting the podcast once again! He’s invited on his colleague and friend, Adam Ulery, who is a Senior Agile Coach at AgileThought. Adam is a perpetually curious, continuous learner who is always willing to encourage others to try new things (as he very often does himself). He is very focused on helping organizations clarify and meet their business outcomes, and loves to help companies become resilient and rediscover their curiosity.   Today, they’re sharing their best tips for new Scrum Masters. When Sam and Adam were new Scrum Masters they found that there were not a lot of experienced Scrum Masters that were accessible to them. In fact, they didn’t even have access to many of the common resources that exist today! So today they want to share all that they’ve learned over the course of their careers and lend a hand to all of the new Scrum Masters out there!   Key Takeaways Tips for the new Scrum Master: Seek to understand where the team is in terms of their Scrum maturity level Observe the team without immediately trying to make changes to the way the team does things to inform yourself about where they are Ask yourself: ‘How well is what they’re doing working for them? Are they working well together as a team?’ If these things look good in-person even though they could look incorrect on-paper you may not want to change these things Do some sort of an assessment with the team to establish a baseline for where they are and how they’re executing Scrum (then periodically reassess down the line) Have the team self-assess Create a shared team vision Regardless of your experience level, educate yourself on the craft Get involved with a community group to improve your area of practice (and if there isn’t one where you are, start one) Indulge in books around your craft — they’re a great resource for taking you to the next level Go to conferences, big or small Tips for the new Scrum Master who is assigned to a pre-existing team: Start by working with them on the areas that need improvement (based off of an assessment) by getting the team’s input and having the team decide what they’d like to work on (assuming they’re mature enough to want to do that) Receive constant feedback by creating an open channel with the team to communicate Have transparency with what you’re doing there and what you want for them How to become a more effective Scrum Master: Find a mentor Be a mentor — just because you’re new doesn’t mean you have nothing to offer Become a speaker — you’ll discover you know more than you thought you did   Mentioned in this Episode: The Scrum Guide The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change, by Stephen R. Covey Tampa Bay ScrumMasters Guild Ken Schwaber Agile Project Management with Scrum, by Ken Schwaber Software Estimation Without Guessing: Effective Planning in an Imperfect World, by George Dinwiddie The Water Dancer, by Ta-Nehisi Coates   Adam Ulery’s Book Picks: Antifragile: Things That Gain from Disorder, by Nassim Nicholas Taleb Killing Sacred Cows: Overcoming the Financial Myths That Are Destroying Your Prosperity, by Garrett B. Gunderson and Stephen Palmer The Purpose Driven Life: What on Earth Am I Here For? by Rick Warren The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations, by Gene Kim, Patrick Debois, John Willis, and Jez Humble   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!