Agile Coaches' Corner

This week on the podcast, Dan Neumann is joined by AgileThought colleague and return guest, Eric Landes! Eric Landes comes from a DevOps background and originally started as a developer. Currently, he serves as a Senior DevOps Consultant, ALM Director, and Solutions Architect at AgileThought.   In today’s episode, Dan and Eric are discussing organization transformation. If you haven’t already heard Agile Coaches’ Corner ep. 59, “The Four C’s of Organizational Culture,” you should tune into that first, as this episode makes reference to it. Today’s episode, however, is asking the question of whether an organization should start by implementing a practices-based change or a culture change when they’re looking to transform.   Is starting with changing the culture a more practical approach, or, is keeping the culture as it is and incorporating more Agile practices overtime more beneficial? Tune in to hear Dan and Eric’s take!   Key Takeaways A culture change approach vs. a practices-based approach: A practices-based approach generally refers to making small changes to behavior A culture change is much more of a big bang whereas a practices-based approach is more of an Agile journey A culture change is more of a plan-driven, A-B transformation and a practice approach is more an incremental, step-by-step process The argument for taking a practices-based approach to transforming an organization rather than changing the culture first: The ability to change practices and shift the overall mindset without changing the culture is a more achievable place to start — it’s also more of an Agile mindset/method (because you’re starting with a practice, seeing how it helps, measuring it, and then moving forward) Practices get modified over time so it can be beneficial to be more Agile as your organization is going through a transformation (rather than going for that “big bang” that a culture change would call for) Putting practices into play (such as test-driven development, breaking down product backlog items, or implementing more Kanban metrics) can help the organization discover what fits and what doesn’t fit into the current culture and also what delivers the most value to the customers Using metrics and practices will lead to changes in thinking around how the organization is delivering   Mentioned in this Episode: Eric Landes (LinkedIn) Agile Coaches’ Corner Ep. 59: “The Four C’s of Organizational Culture” The Reengineering Alternative: A Plan for Making Your Current Culture Work, by William Schneider Professional Scrum with Kanban Certification   Eric Landes’ Book Picks: Training from the Back of the Room! by Sharon L. Bowman The Color of Compromise: The Truth about the American Church’s Complicity in Racism, by Jemar Tisby   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!

On today’s podcast, Dan Neumann is joined once again by Christy Erbeck! Christy 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.   On top of all of Christy’s licenses and titles, she is also a Certified SAFe® Program Consultant — which is also the topic of today’s show! There are a lot of horror stories around SAFe implementations because, in many cases, the original intent has been corrupted. So in this episode, Christy is breaking the SAFe framework down for listeners. She’s busting the myths that have given SAFe a bad rap and then providing her tips for a successful and effective implementation of SAFe!   Key Takeaways What is SAFe? SAFe is a framework for predictability at scale Empowers complex organizations to achieve the benefits of Lean-Agile software and systems development at scale Christy busts some myths regarding the SAFe: “Waterfall disguised as Agility” — not true; it is a framework with elasticity in how it can be implemented “It’s very prescriptive” — though there is an overarching framework and path that is laid out, the fundamental mindset underneath it is Agility “SAFe stops at training the leaders about velocity” — untrue! Just train the leaders and just get started “You can just put aside vulnerability” — you cannot, so instead get in front of it and break down the walls by discussing the discomfort and change that comes with implementation “SAFe always goes wrong and completely goes against an Agile mindset” — SAFe as a framework does not do this; it’s perpetrated by the consultants and the organizations that don’t fully commit to implementing it How to ensure your SAFe implementation is effective and successful: Start small and ‘nail it before you scale it’ Start with training your leaders and give them a compelling ‘why’ Create a Lean-Agile center of excellence where you can bring everyone together to help identify the system-level items and issues that are going to need to be addressed as you all move through the implementation roadmap As a manager, reject bad plans (this is very beneficial towards getting more predictable deliveries) Implement the events within SAFe well (and safely) so that your organization can be set up for success Understand Lean thinking Establish safety within the team and the organization to build trust Stay nimble Listen to what the client needs, not what you think they need   Mentioned in this Episode: Christy Erbeck’s LinkedIn Scaled Agile Framework Certified SAFe® Program Consultant Agile Coaches’ Corner Ep. 1: “Do Scrum Well Before Scaling!” Agile Coaches’ Corner Ep. 22: “The Role of Managers in Agile Organizations with Esther Derby” Brené Brown Brené Brown — Dare to Lead Start With Why: How Great Leaders Inspire Everyone to Take Action, by Simon Sinek Relentless Forward Progress: A Guide to Running Ultramarathons, by Bryon Powell How to Measure Anything: Finding the Value of Intangibles in Business, by Douglas W. Hubbard   Christy Erbeck’s Book Pick: Master of One: Find and Focus on the Work You Were Created to Do, by Jordan Raynor   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 Agile Coaches’ Corner, Sam Falco is taking over the podcast! He’s gathered up some interesting questions on the topic of Scrum through Quora and will be going through them one by one to give his insights and key points regarding each!   Tune in to hear Sam’s take on what the purpose and benefits are of a daily Scrum meeting, the best way to resolve the issue of a team member taking up too much time at the daily Scrums, and whether or not he thinks the role of the Scrum Master should be temporary in a Scrum team until the team is self-organizing!   Key Takeaways What is the purpose, as well as the benefits, of a daily Scrum meeting? The Scrum guide states that the purpose is for the development team to plan its work for the next 24 hours To inspect the work the team has done since the last time they’ve met and adapt the plan accordingly to achieve the sprint goal It’s all about helping the development team to meet the sprint goal You should be getting a new plan out of the daily Scrum meeting that takes into consideration the new data you’ve gathered since the last time you met A team member is taking too much time at daily Scrums — what’s the best way to resolve this issue as the Scrum Master? Firstly, remember the purpose of the daily Scrum: to inspect the work and adapt the plan to achieve the sprint goal, and ask: is that still happening in the allotted timeframe? If it is, it’s really not a problem for the Scrum Master to solve It could be a real problem when it’s leading to the daily Scrum taking way too long, people begin ‘checking out’ in the middle of it, or it’s preventing the team from self-organizing Don’t jump in right away as the Scrum Master; your role is to simply make sure the development team has the event and teach them to keep it in the timebox Consider pointing out that the meeting has been taking too long to the team and allow them to solve it themselves Consider coming up with a signal when someone is taking an unnecessary deep dive into a topic (but make sure the team isn’t relying on this method to the point where they’ll struggle to self-organize) Bring up the problem at a retrospective, let the team decide whether it’s a problem or not and how they want to handle it, and then give them guidance based on that feedback Should the role of Scrum Master be temporary in a Scrum team until the team is self-organizing? The Scrum Guide argues that no, it wouldn’t be Scrum, because if you do away with any of the rules and roles in Scrum (though possible) the result becomes something that is not Scrum The presence of the Scrum Master on the team will vary depending on the team, but early on it is especially important that they need to be involved quite a bit As the team matures and learns to self-organize, the Scrum Master could shift their role from working on the rules of Scrum and how to apply them to help the team determine better engineering practices It’s not practical to think that the team will never need their Scrum Master again (as the Scrum Master does more than facilitate meetings and teach the Scrum framework) Ultimately, it’s important that the team is able to call upon their Scrum Master   Mentioned in this Episode: Quora The Scrum Guide Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, and Leave Competitors in the Dust, by Ken Schwaber 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!

Welcome to the first episode of 2020! In this first episode back into the new year, Dan Neumann will be taking a look at organizational culture.   It’s often said in the Agile community that the culture has to change within an organization for Agile to take place. When it is thought of like that, changing culture can be a pretty tall order. But in William Schneider’s book, The Reengineering Alternative: A Plan for Making Your Current Culture Work, he outlines a framework to make your current organization’s culture work. In this episode, Dan will be taking a look at the key concepts of Schneider’s framework and exploring the four cultures he categorizes every organization into — also known as the four Cs.   There’s no one-size-fits-all for the perfect culture to support Agility in an organization. Your results will be much more effective if you work with your organization’s current culture — so be sure to tune in to learn how to fully leverage your current organization’s culture!   Key Takeaways The four Cs of organizational culture: Collaboration: Similar to a family in their social nature Derives their strength through affiliation Strengths: very team-focused, participative, values diversity, and are a generally fairly trusting organization with lots of open and honest communication Weaknesses or downsides (when the pendulum swings too far into a collaboration-based culture): the harmony of the group may be valued over the frankness that’s needed to talk about tough issues, and there may be too much compromising and too much movement towards consensus building and collaboration versus being clear about how decisions get made and collaborating within the defined framework (i.e. trouble making and sticking to decisions) Important to consider: collaboration culture can be great, but just make sure the pendulum hasn’t swung too far to the point where the organization is ignoring misbehaviors or shortcomings; instead, tackle them head-on within the culture Control: Similarly modeled to the social institution of the military Power-oriented Leaders are awarded for power reasons Strengths: emphasizes strength; very effective at planning; and there are clear systems, policies, and procedures in place Weaknesses or downsides (when the pendulum swings too far into a control-based culture): people will begin to rigidly adhere to the policies and practices without ever stopping to improve them, innovation may stop within the organization, and it becomes difficult to have generalists (which can be very important on Agile teams) Important to consider: control culture is not anti-Agile, but if you are looking to embrace the values and principles of Agile, you have to keep the culture in perspective Competence: Similar to the social institution of a sports team or university Rewards staff that are achievement-focused Can be very creative and visionary and values craftsmanship Strengths: organizations are task-driven, tend to be very efficient and objective, and have high-performance standards Weaknesses or downsides (when the pendulum swings too far into a competency-based culture): individuals may go on ‘technical tangents’ and are spending too much time in ‘analysis paralysis’ (i.e. trying to find the ‘perfect’ solution instead of moving forward with building), overplanning, and may become too emotionally controlled with no willingness to deal with interpersonal conflict Important to consider: make sure that the organization’s culture is not striving to win at all costs but instead focusing on completing tasks and achieving objectives Cultivation: Similarly to a religious institution in their social nature Values growth and self-actualizing Generally non-profit organizations Strengths: these organizations tend to be personal, nurturing, inspiring, fairly subjective, help people self-actualize to be their best, and provide lots of opportunities for growth and development (which can be very helpful for an Agile team) Weaknesses or downsides (when the pendulum swings too far into a cultivation-based culture): way too much self-expression, too much time focused on feelings and worrying about the slightest offense that may have been taken, favorites may be played in the organization, and emotions may begin to trump the place of data Important to consider: make sure the pendulum doesn’t swing too far into cultivation as the notions of measuring and managing would have a hard time really taking root   Mentioned in this Episode: Agile Coaches’ Corner Ep. 58: “How to Get Past the Two-Week Shelf Life of Your New Year’s Resolution” The Agile Manifesto The Reengineering Alternative: A Plan for Making Your Current Culture Work, by William Schneider Susan DiFabio’s LinkedIn Team of Teams: New Rules of Engagement for a Complex World, by General Stanley McChrystal, Tantum Collins, David Silverman, and Chris Fussell How to Measure Anything: Finding the Value of Intangibles in Business, by Douglas W. Hubbard   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!

With just days before the new year, your host, Dan Neumann, figured it’d be the perfect time to discuss New Year’s resolutions! Many people set New Year’s resolutions, but the problem is: they don’t keep them. Some research even says that only 8% of people actually achieve the goal they’ve set out for. Many of these goals don’t even reach a two-week shelf life before many people give up.   But why is this? In today’s podcast, Dan Neumann sets out to find the answer! He takes a look at what’s inherently flawed about this concept of New Year’s resolutions, gives his insights on how you can make your New Year’s resolution more likely to stick, and even shares some of the goals and resolutions related to the podcast itself!   Key Takeaways What is inherently flawed about the concept of New Year’s resolutions? It’s too long of a goal; you’re setting a goal for the next 365 days! January 1st is actually a pretty arbitrary start date A lot of people don’t plan for what to do in a situation that challenges their New Year’s resolution (a lack of planning can majorly impact your ability to follow-through) How to get your New Year’s resolution to stick: Set a shorter duration; it doesn’t have to be for the next year If two-week sprints work well for you, you could work similarly on this cadence Differentiate between a resolution vs. setting a goal Use the S.M.A.R.T goal framework (S= Specific, M= Measurable, A= Achievable, R= Relevant, T= Time-bound) Set your new goals on a better starting date that makes more sense for you (such as on a Monday or the start of a new month) Brainstorm some ways to set milestones for yourself Plan for what you’re going to do when you run into a challenging situation Find an accountability partner Each week, each ‘sprint,’ or each month, reflect on how to become more effective and adjust accordingly (similarly to the last principle in the Agile Manifesto)   Mentioned in this Episode: “This is the Day You’re Most Likely to Let Your New Year Fitness Goals Slip,” by Runner’s World S.M.A.R.T Goals The Agile Manifesto   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!

On today’s podcast, Dan Neumann is joined by his collaborator, Sam Falco! Today they will be comparing a product-focused approach versus a project-focused approach and highlighting some of the major differences. They also cover how to apply a product mindset to a project-focused organization and offer some key tips on how to effectively implement either!   Key Takeaways What defines a project-based approach? A defined start and a defined end Success is defined at the beginning by doing the project within scope, budget, and within the estimated time and to deliver on that Check off the tasks and get to the end This approach works best in best-practice or turnkey solutions where a defined process is always going to give you the same outcome The focus is on completing tasks What defines a product-based approach? No defined beginning and end Starting with an undefined want or need Delivering in increments Instead of asking, ‘Did we do all the things?’ success is defined around user adoption and user retention as well as revenue increases and/or cost savings Think of the three Vs: Vision to Value to Validation (these three Vs are also aligned with the three pillars of empiricism [which is what Scrum is based on]: transparency, inspection, and adaptation) With more complex work like software development, a product-based approach tends to work the best (as you will generate less waste and be able to change course as needed) Focused on achieving outcomes What exactly is a product? Anything that can be put out into the market and could satisfy someone’s needs or wants Something that will generate a benefit for the producer of the product (whether that is revenue, new customers, cost savings, etc.) Once that value is created, you want to release frequently and get feedback from the consumers of the product The mindset of product and some additional key pieces of information: Creating a sustainable pace (don’t bombard people with updates nor release too infrequently) A product mindset can be applied to a project-focused organization Remember: mindset is not just the way we think about something; it’s thinking that drives our actions (so you can still be in a project environment but have a product mindset) Getting a working piece of software into the hands of your customers every sprint rather than defining everything upfront   Mentioned in this Episode: Agile Coaches’ Corner Ep. 56: “Scrum and Agile Q & A with Christy Erbeck” The Professional Product Owner: Leveraging Scrum as a Competitive Advantage, by Don McGreal and Ralph Jocham Relentless Forward Progress: A Guide to Running Ultramarathons, by Bryon Powell How to Measure Anything: Finding the Value of Intangibles in Business, by Douglas W. Hubbard Agile Coaches’ Corner Ep. 27: “Deep Dive on Scrum Values with Sam Falco” Sam Falco’s LinkedIn   Sam Falco’s Book Picks: Blink: The Power of Thinking Without Thinking, by Malcolm Gladwell Thinking, Fast and Slow, by Daniel Kahneman   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!

Today on the podcast, Dan Neumann is joined by a return guest, Christy Erbeck! Christy is a Principal Transformation Consultant at AgileThought and 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. In this episode, they’ll be taking a look at a couple of different areas on the theme of agile by reviewing some questions from Quora.com! They start off discussing sprint retrospectives and how to make them more creative and fun; later shifting to discussing frameworks and which are appropriate where; and then lastly, they take a look at agile vs. waterfall.   Key Takeaways “How does a Scrum Master make the sprint retrospective more creative and fun?” Allow room for creativity by creating a safe environment through structure Slowly introduce new ways to run the retrospective so the team can look at their work and interactions differently Get to know your team — the better you know them, the better you can adapt the retrospective to fit their needs Use a method such as the Sailboat Retrospective to get the team outside of their regular 3-question retrospective Try the ‘Genie Retrospective’ and ‘The Four Ls Retrospective’ (and don’t be afraid to customize them to make them your own, either!) Read Agile Retrospectives: Making Good Teams Great, by Diana Larsen and Esther Derby for further insights on what makes a great retrospective Seed the data for the retrospective Check out TastyCupcakes.org, FunRetrospectives.com, and Retromat.org for further ideas for creative and fun retrospectives “How do we convince clients to use agile methods?” Share case studies and stories from your own experience that illustrate the benefits that come from it Explain the “why” Meet them where they’re at You can’t convince them; you need to help them uncover their own reasons for why they would want to adopt it so they can sell themselves on it Dig into what isn’t working for them right now that agile would solve Do a lot of listening about what their problems are “What is the advantage of waterfall over agile?” There is a time and a place for waterfall, depending on the project It can be a great approach to solving a problem and getting a product out the door for simple projects that have a clear checklist Remember: you can still apply an agile mindset to a waterfall project and an organization can use both approaches successfully   Mentioned in this Episode: Christy Erbeck Quora Sailboat Retrospective Genie Retrospective The Four Ls Retrospective Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen TastyCupcakes.org Retromat FunRetrospectives.com Stacey Complexity Model Cynefin Framework JordanRaynor.com Relentless Forward Progress: A Guide to Running Ultramarathons, by Bryon Powell   Christy Erbeck’s Book Pick: Master of One: Find and Focus on the Work You Were Created to Do, by Jordan Raynor   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 today’s episode, Dan Neumann is joined by Steven Granese, the Vice President of the Transform Practice at AgileThought! As the VP of Transform Practice, Steven leads a team of the top Agile Coaches, DevOps Consultants, and Product Consultants in the United States.   Together, Dan and Steven will be exploring the ‘why’ behind Scrum and examing the question of why organizations and teams should be using Scrum, in the first place. Steven often sees that the clients he’s working with lose focus on the ‘why’ behind Scrum or don’t even know what it is, to begin with! With these clients, there will be a lot of focus on the mechanics of Scrum and the framework itself (i.e. the ‘how’) without a deep understanding of why they’re using Scrum, what problems they’re trying to solve with Scrum, and what their purpose is for working with sprints with iterations. In this episode, Steven addresses how organizations can shift their perspective from a ‘how’ mentality to a ‘why’ mentality as well as many of the misconceptions and incorrect uses of Scrum (so you can be sure to avoid them!)   Key Takeaways Why it is important to focus on the ‘why’ behind Scrum rather than the ‘how’: The ‘why’ helps the team and organization understand what problem they’re trying to solve with Scrum in the first place Focusing on the ‘how’ (such as: “How do we execute Scrum?”) leads to organizations applying Scrum incorrectly Understanding the ‘why’ leads to a deeper understanding of why they’re using Scrum, the problems they’re trying to help solve with it, and what their purpose is in working with sprints and iterations The ‘why’ behind Scrum and where it makes the most sense to use: In conditions of high uncertainty In environments of high uncertainty Incorrect ways Steven sees Scrum being applied: As opposed to building a working increment of their product, getting feedback as they go, and adjusting their sprint-to-sprint plan based on the feedback (which is the heart and soul of the ‘why’ behind Scrum), they’re not allowing feedback into the process — therefore losing the ‘why’ in the process Breaking up work into milestones instead of sprints Treating the sprint demo like a sales pitch and not letting the customer experience the demo for themselves Techniques and tips for achieving the ‘why’ behind Scrum: Recognize that the market moves fast, there’s a lot of uncertainty in the world, and that the customer’s needs are changing very quickly Match the way you think about your work and deliver your work to that uncertainty (which allows you to move faster) Stop overplanning and just start working Put increments of the product into the customers’ hands and start getting their feedback Get back to the basics and simply focusing on two weeks at a time Measuring the right metrics (“You get what you measure”) Don’t just use Scrum to measure the team; use it to measure the flow of the entire system Focus on getting really quality feedback from your customers “Begin with the end in mind.” — Stephen Covey Through receiving high-quality, real feedback from a sprint demo, really listen to the feedback and adjust the plan and fix problems accordingly Understand where the market is headed (and differentiate between what the customer wants and what is actually needed) by building something and putting it in their hands to get feedback Fail fast to learn fast Build in thin slices and get feedback as you go — you will learn a ton about what users actually need and also save time by not building unneeded features Misconceptions about the Scrum framework: That Scrum is really about product delivery (“Scrum is just as much about discovering the solution as it is about delivering the solution” — Steven Granese) Scrum and other Agile frameworks are seen as a delivery mechanism (as opposed to a mechanism to discover what the customer actually needs) That you have to use Scrum (if you already know exactly what you need to build and there’s no uncertainty then there’s no need for the iterative nature of Scrum)   Mentioned in this Episode: Steven Granese Stephen Covey “Wagile” (Waterfall Agile)   Steven Granese’s Book Picks: 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 Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, by Nicole Forsgren, 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!

This week on the podcast, Dan Neumann is joined by Che Ho! Che Ho is leading an agile transformation for the County of Santa Clara, California. He also recently got certified as a Scrum Master Professional through Agile Alliance. And, fun fact: He’s also a martial arts instructor for Wing Chun! He’s been studying it since he was 10 and has been teaching it now for 20-odd years.   Speaking of martial arts, the topic today directly relates to it! Shu Ha Ri is a concept that comes from Japanese martial arts’ kata (AKA forms) and is a fantastic tool for Agile coaches in their approach to agile adoption. In this episode, Dan and Che Ho are completely breaking down the concept of Shu Ha Ri to make it just a little more tangible.   Key Takeaways What is Shu Ha Ri? ‘Shu Ha Ri’ is not levels, nor is it a self-contained stage that you go through The description of Shu Ha Ri comes from Japanese martial arts’ kata (AKA forms) Shu Ha Ri is similar to a pyramid; each phase supports one another and one cannot exist without the other It’s simply a way to look at a maturity level which can help with agile adoption Breaking down Shu Ha Ri: The ‘Shu’ phase: Shu is when you first start learning (it’s essentially like learning the alphabet and how to put things together) Where you learn the ‘why’ The time for getting comfortable with the rhythm of things The ‘Ha’ phase: Ha is about playing with the techniques and stringing them together in your own unique way You can begin to personalize within the framework You can move off script as the framework is internalized Motivation comes to light at this phase The ‘Ri’ phase: Ri is the ‘ultimate mastery’ — it’s described as the phase where the form no longer matters (it’s a ‘formless form’) It’s more of a lifestyle — it becomes so ingrained in you that it just becomes the way that you are rather than something that you do The activity becomes organic Through this, you create ways that are uniquely yours and you can become playful with it A lot of experimentation can signify a ‘Ri’ level of maturity Ri is when you become so comfortable with what’s going on that it just becomes you; and you’re free to innovate, create, and experiment How to address resistance to Shu Ha Ri: Firstly, don’t take it personally — as Che Ho says, “They’ve honed their habits over decades to get to the success where they’re at now — so of course they’re going to resist changing it!” Address the ‘why’ for the change Remember: it takes time You can only get so far studying by yourself but a coach helps you get great A study group can be a form of coaching if they are focused and have their intention set for growth and change Che Ho’s key takeaways: Shu Ha Ri is a way to bring people to the same understanding Be sure to have patience with the change Celebrate the small wins along the way Instead of trying to achieve something, Shu Ha Ri should become an internalization and part of your being   Mentioned in this Episode: Che Ho's LinkedIn Profile Agile 2019 Conference Wing Chun Shu Ha Ri Bruce Lee Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, by Lyssa Adkins Alistair Cockburn Kata Woody Zuill Agile Coaches’ Corner Ep. 45: “The Benefits of Mob Programming with Chris Lucian” The Agile Manifesto County of Santa Clara Nonviolent Communication (Approach by Marshall Rosenberg)   Che Ho’s Book Picks: Say What You Mean: A Mindful Approach to Nonviolent Communication, by Oren Jay Sofer Resilient: How to Grow an Unshakable Core of Calm, Strength, and Happiness, by Rick Hanson Ph.D. and Forrest Hanson Pocket Guide to Interpersonal Neurobiology: An Integrative Handbook of the Mind, by Dr. Daniel J. Siegel M.D.   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!

Recently, Dan received an email from a listener that posed an interesting question. In short, they said, “We’re doing alright every sprint and the business is doing alright too — we’re not really facing any competition. So, when the team asks, ‘Why should we continually improve?’ how can I help them through that scenario?” This is a great question! Though this team is stable, have been working together for a long time, and are doing well — they’ve reached a plateau.   When you dominate your market and you feel there is no competition there can end up being a serious lack of continuous improvement (especially if the barrier to entry is really high!) And it’s not totally unexpected that teams sometimes can get a little bit complacent — but it’s the Scrum Master’s job to challenge that. So, in today’s episode, Dan, and his collaborator, Sam Falco, will be answering this question and addressing how you, as the Scrum Master, can help remotivate your team to amplify what’s going well, shake things up, and make sure they’re all doing more of what they love!   Key Takeaways Why should you continually improve? In the case of competition (people may find an alternative to your company!) Because there is always something you can look to improve (even if things are going well you can always amplify that) How can you get your team to be interested in continuous improvement? What’s important to note as a Scrum Master or team leader? Watch out for change fatigue (sometimes it’s good to simply celebrate stability) Ask: “What could we try differently?” even if everything is going well (amplify what’s already going well!) Hold timeline retrospectives (i.e. with the team, plot the events that happened over a period of time and list them from most positive to least to see what people are feeling good or negative about) By looking back further than a sprint, you can do an exercise called a journey map for the last quarter (or as far back as a year) to look for trends Find the things that are going to be good for your team (i.e. a compelling interest beyond just the financials of the company) If some members of the team are bored with the work they’re doing, assign a new project or have them learn a new area of the business Work with the Product Owner on the question of: “What could we do to delight customers? What are they asking for?” using the Kano model Work with the Product Owner and coach them on the product road map/how to understand customer needs and creating more inspired product backlog items to fuel the motivation for continual improvement Look for ways to tap into your team’s intrinsic motivation (if you have a long-standing team it may be important to find out what motivates each individual member of the team [which could be autonomy, mastery, or purpose, according to Daniel H. Pink]) Remember that you are looking for the intrinsic motivators rather than the extrinsic motivators (which are things like time off or financial rewards) Try flipping the script; do your retrospective around: ‘What would destroy as us a team,’ ‘How can we mess up,’ and ‘What would make the next sprint a complete disaster?’ Identify somewhere that the team can go and lead the way by holding the vision and finding areas of improvement (i.e. lead more than serve) Be sure to keep in mind that change and improvement can take a long time Find a representative within the team of developers who is interested in continuous improvement to facilitate change, model the behavior, and lead through attraction   Mentioned in this Episode: Kano Model Drive: The Surprising Truth About What Motivates Us, by Daniel H. Pink Moving Motivators Cards Agile Coaches’ Corner Ep. 43: “The Importance of the Product Owner Role in Scrum with Sam Falco” Agile 2019 Conference Agile + DevOps East Conference “The Experience Trap” – Harvard Business Review   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!