Agile Coaches' Corner

In this episode, Dan Neumann is joined by AgileThought colleague and frequent guest of the show, Quincy Jordan. Quincy has been with AgileThought for just over two years as a principal transformation consultant and agile competency lead. Prior to AgileThought, Quincy was the transformation lead for Pivotal’s Atlanta office, where he consulted with clients to help them reach enterprise scale. He has also served as a principal consultant and agile coach at SCRUMstudy.com for over six years.   In their discussion today, Dan and Quincy explore the topic of culture as related to agile transformations. They define what culture is, why it is important, how it factors into agile transformations, and how to begin addressing it as an organization. Quincy also shares how to become more intentional about addressing culture early on as the company is moving toward a more agile way of working, the outcomes of being unintentional about addressing culture challenges, and additional tips and takeaways that are critical to keeping in mind when addressing culture.   Key Takeaways What does ‘culture’ refer to? A combination of the values, habits, and norms within a group or organization The values that are present in everything that your organization does It applies to any organization (whether it’s a religious institution, your family unit, company, etc.) Can be characterized as “The way things happen around here” or “How we do things around here” Quincy’s advice regarding how culture factors into agile transformations: Culture cannot come last; if you want the ‘machine to run well’ and address the culture after, you have created a culture that says, “The machine is more important than the culture” If a specific habit, such as courage, is not encouraged, you are building cultural debt; i.e., it will become more and more difficult for courage to be expressed It is important to be intentional about culture upfront and incorporate it into your transformation as part of your strategy If you don’t want certain habits to be a part of the culture, you have to intentionally set a new structure for everyone to transition to (otherwise it will continue to be pervasive) Outcomes of being unintentional about addressing culture challenges: If you’re not intentional about the culture and you develop a culture by default, it is likely to be riddled with cultural debt If you don’t address having the proper culture that you want up front, you are going to have a mismatch of what you currently have and what it is that you really want If the team/s are checklist-driven then they won’t have the opportunity to help the culture be values-driven How to be more intentional about addressing culture early on as the company is moving toward a more agile way of working: Ask: “Are we involving the teams in the actual planning or are they being given plans and milestones that they’re expected to hit without participating in the creation of those plans?” Ask: “Is our culture checklist-driven rather than values-driven?” The team/s should be involved in understanding what’s drawing value so they can better help accomplish the work that needs to be done for the values to be there Set the culture upfront Figure out the things that you are and are not aligned to as an organization Decide on where the values lie and what they would be (ask individuals and teams: “What are the things that we value?”) Have teams and individuals fill in the blank: “It really agitates me when _________.” It helps make clear what things affect their value system Do a team working agreement where you establish what the values are Once you establish what the values are, ask: “How can we act on these values?” and “What are the things that we can do, day-in and day-out, to express that those are our values?” For example, if the value is: “Everyone has a voice,” then you need to provide opportunities for individuals to have their voice heard Additional culture tips and takeaways: You need to be intentional and know what your values are so that you can drive towards them (and be intentional about not allowing those values to be encroached upon) If you address culture upfront, then you’re putting the organization in a position where you’re helping to impact the decision-making Addressing the culture upfront helps the organization work towards their overall vision It is important to have people within the organization that are carrying the culture forward so that when others are unsure/confused, they can look to those people   Mentioned in this Episode: The Reengineering Alternative, by William E. Schneider Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs, by John Doerr Science of Running: Analyze your Technique, Prevent Injury, Revolutionize your Training, by Chris Napier   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 of the Agile Coaches’ Corner podcast, Christy Erbeck, the Chief People Officer at AgileThought, is serving as your guest host for today’s conversation with Dr. Jerry Smith. In their conversation today, they discuss how to make AI work for your enterprise. Dr. Jerry Smith explains why understanding causality is critical for AI-driven business transformation and how data science and analytics can help enterprise clients transform and become the digital winners that they desire to be. Key Takeaways How AgileThought aids enterprises in understanding AI-driven business transformation: Come up with a working set of definitions for AI, machine learning, and data science How AgileThought helps their enterprise clients solve their problems:  The question: “What is data?” should be asked (Dr. Jerry Smith’s answer: “Data is the debris of human activity; it’s because of us, not in spite of us”) Note: Data is not just spontaneously created in your data systems; it’s created from an application which captures an interaction between a human being (you, your customers, or your admins/salespeople) and that system Note: The data we see is because of human actions When we look at our capabilities, we should be asking the fundamental question: “What data in our enterprise is causal to our business outcomes?”  For example, ask: “What data that you have spent time collecting is directly causing your revenue to perform the way it does?” The very first thing to ask is: “What is causal?” Once you know the causal data, you can go back to the application and the human and say, “How do I change the human behavior so that the application picks up the new behavior and changes the data?” This result is causal-based data engineering for AI, and is the only way to change your organization AgileThought helps companies institutionalize data science, machine learning, and AI at the enterprise level by breaking down the process (as shown below), so that each and every process resides in infrastructure and a set of capabilities There are three kinds of data: Your enterprise, your IT, and your opensource – the goal is to get this data into a single machine learning record This single machine learning record is critical in showing all of the variables in columns and observations in rows – from there, you can do basic analytics, and then, data science Data scientists make sense of the data and create models out of the data, so the data no longer has to be used In the machine learning phase, data scientists try to predict what these models are trying to do and how they’re going to change under certain variables Note: AI is about prescriptions; making decisions Note: The biggest value is not in generating or reading reports; it is in making an appropriate decision based on these reports About Dr. Jerry Smith: Dr. Jerry Smith is AgileThought’s Managing Director of Analytics and Data Science. As a practicing AI & Data Scientist, thought leader, innovator, speaker, author, and philanthropist, Dr. Jerry Smith is dedicated to advancing and transforming businesses through evolutionary computing, enterprise AI and data sciences, machine learning, and causality. 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 episode, Professional Scrum Trainer Eric Landes addresses the questions: "How do you measure a Scrum Team's Performance?" What Does the Scrum Guide say About Measuring Performance? In many of our Scrum classes, the issue of measuring performance is asked about how can we measure a Scrum team's performance. It is a good question that the Scrum guide does give some information on the guide states that one of the inputs of Sprint planning is past performance of the development team. It also States that the daily Scrum optimizes team collaboration and performance by inspecting work. In these two statements, we learn that Scrum does want to help optimize team's performance. So how do we measure that though? When we go back to our question, let's talk about why we should measure a Scrum team's performance as the Scrum Guide mentions, we do need that as an input to Sprint planning. Velocity is not the Best Measure For this input, many teams use a velocity chart. A team's velocity chart to understand past performance. And this is a complimentary practice to Scrum. It's not actually asked for in the Scrum Guide or prescribed. But it is one well-established way to measure performance along with Sprint burndown charts and release burndown charts. I find that velocity may not be the best measure. Use Kanban Metrics to Measure and Forecast If this question is more about helping the team understand and communicate delivery performance, there are tools like cumulative flow charts and throughput that could be used. These metrics come from a Kanban perspective and these tools help teams understand their flow and can be used to communicate forecasts. For instance, your team may have a throughput of one PBI done each day. Just as an example, as a for instance, while using the past metrics are never one hundred percent accurate. It can help teams as they go into Sprint planning and Kanban even gives you a forecasting method called Monte Carlo simulations that can help with this. Now this is a complex topic for sure, but the main purpose of this Trainer Talk is to introduce you to concepts beyond team velocity charts, and burndown charts. Many Kanban metrics can be used to help teams understand their delivery capabilities better and achieve a flow that many mature teams are hallmarks of many mature teams. Scrum.org even has a class called Professional Scrum with Kanban that teaches participants to get to that flow and to help measure that flow. Find What Works for Your Team If you are interested in different ways to measure a Scrum team's performance, I urge you to check out some of these other metrics. There is no one size fits all. So, make sure it works for your team and self-organize around the way your team measures performance. Want to Learn More or Get in Touch? Register for our upcoming web meetings by visiting agilethought.com/events 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!

In today’s ‘solocast’ of the Agile Coaches’ Corner, Dan Neumann is exploring the art of metaphors. Metaphors can be a powerful tool to illustrate important ideas and concepts of agility — if used well.   Dan shares the pros and cons of using metaphors in an agile setting, how to use them effectively whatever your role may be, and how metaphors can be a really powerful tool to add to your arsenal, regardless of what level you’re at in the organization and who you’re trying to communicate with.   Key Takeaways What is a metaphor? A metaphor is a way of using a concrete image/example to help connect to an abstract thought Taking an abstract idea like agility and then comparing it to something that is very concrete Metaphors help us connect abstract things to familiar ideas Examples: “All the world is a stage.” — Shakespeare, “Life is like a box of chocolates.” — Forrest Gump What to keep in mind when using metaphors: Be aware that we can sometimes bring in biases and/or unintended constraints that are not helpful Using a metaphor may impact the way a person is looking to solve a problem The way in which a metaphor is used is going to affect the way that someone is going to think about different problems Common (and not-so-common) agility metaphors: An 8-hour endurance race (where the goal is to see how many miles you can go in a set amount of time) can be compared to an agile software development project Building a car as compared to product development (the metaphor of construction helps to connect the thought of agility with regard to transportation) Agile gardening vs. Agile farming (illustrates the contextual differences when you’re doing small-scale agility [the gardening] vs. commercial, industrial-scale agility [farming]) Sailboat (a metaphor technique used in retrospectives): i.e. “What are the fair winds that are blowing your boat across the water?” and “What are the anchors?” (i.e. what is keeping your boat moving forward to its destination) Metaphors can also be used to show where agility does not make sense (i.e. you don’t exactly want a McDonald’s lineworker being agile when they’re making your burger; you want the same burger every time you go there) House metaphors: “If you’re building a house you have to build a solid foundation” and “You wouldn’t build a house one room at a time” (these can be good for user stories as well as illustrating the desire for pre-planning) Pros Metaphors are powerful in that they cause the brain to react differently Metaphors can help teams move away from a really concrete way of thinking about a problem to a much more abstract way, unlocking some new potential There are lots of different ways of using metaphors to help connect people to this abstract concept of agility Cons An issue with metaphors is that they can sometimes be militaristic (i.e. using military metaphors, such as those seen in Team of Teams) Some metaphors bring in gender biases (i.e. “don’t get your panties in a twist”) — this baggage is not appropriate and brings in stereotypes Metaphors about games and sports (because agility isn’t a win/lose scenario) Art metaphors — not everyone will be able to relate to the message (it’s important to be aware of your audience) Imagining your team as a machine in a metaphor can bring in some constraints you don’t necessarily want   Mentioned in this Episode: “How the brain finds meaning in metaphor,” ScienceDaily “Through Their Own Words: Towards a New Understanding of Leadership Through Metaphors” “Why Metaphors Are Important: Metaphors are not just a literary technique; they are a psychological technique” “The Power of Metaphors in Communication” Team of Teams: New Rules of Engagement for a Complex World, by Stanley McChrystal with Chris Fussell, Tantum Collins, and David Silverman   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 episode, Dan Neumann is joined by not one — but two! — AgileThought Colleagues; Quincy Jordan and Christy Erbeck!   In their conversation today, Dan, Quincy, and Christy discuss the key qualities to look for when bringing a new Scrum Master into your organization. They discuss the important characteristics you should be on the lookout for, the key skillsets, important soft skills, and some of the qualifiers (and disqualifiers!). They also share what to pay attention to when hiring, red flags to watch out for, and insightful questions you can ask during the interview process to make sure they’re a good fit.   Key Takeaways What to consider when beginning to look for a Scrum Master: Key characteristics Skillsets Soft skills Qualifiers and disqualifiers Good qualities: Humbleness — they focus on the betterment of the team rather than shining the limelight on themselves They are a servant leader A capacity to focus on the strengths of others A good balance of leadership and humility Open to feedback They have a growth mindset They are a learner; not a knower They come from a place of curiosity vs. judgment What to pay attention to when hiring: They understand the five Scrum values Mastery of the Scrum guide They are staying up-to-date on the Scrum framework They purposefully model the behaviors and values of Scrum Listen to how they use their words; i.e. are they phrasing from a competitive standpoint or a collaborative standpoint? Are they phrasing from a comparative standpoint or an inclusion standpoint? They should have stories and anecdotes of how they have applied the Scrum guide in real life They should take on the role of a Maestro rather than a ‘Master’ In the interview process, identify how they apply values, think through problems, and how they recover and ‘rise strong’ from a failure If they don’t have any certifications, inquire why that is and how they have self-taught If they do have certifications, ask when they received them and what they have done with them since Ask how they are participating in the agile community in their area Disqualifiers: Humility to the point where they are not actually leading anything Having too much knowledge and have a hard time pulling their weight from their own experience/knowledge and not allow the team to determine the ‘how’ for themselves They are not open to self-evaluation or evaluation from others They have a fixed mindset They are a knower; not a learner Misconceptions: Do not assume that you can take all of your project managers and turn them into Scrum Masters “We need a very technical person to be a Scrum Master” — untrue; in many cases, a less technical person makes a better Scrum Master   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 and Christy Erbeck are discussing how to lead in times of crisis and come out of it stronger than ever.   As a leader, it is critically important to take care of yourself during crises to be able to lead others through them, as well. In this episode, Christy shares her tips for leading through crisis, key strategies leaders can begin to implement, and how to cultivate a healthy work environment for everyone involved.   Key Takeaways Christy’s tips for leaders, leading in a time of crisis: Use it as a time to reflect on where you are now and where you want to be on the other side of it all Take time to process your emotions and lead from a place of truth Lead by example; take care of yourself and work at a sustainable pace while encouraging the rest of the team Transparency is key — be transparent about where you are, as a team, as an organization, and in relation to the difficult decisions you’ve had to make to survive the crisis (transparency offers the opportunity for growth and building trust within the organization) Understand your audience in your approach with being transparent; it is important to care for the person receiving the information Going hand-in-hand with transparency, it is also critical to communicate (and the need for communication exponentially rises, the greater the crisis) Meaningful, intentional communication and on-going dialogue between the employee and the leader (or the team and the team members) is critically important for minimizing the stories they may be telling themselves when there is a gap in communication or lack of communication Connect in a meaningful way with your employees vs. walking away or being silent Authenticity is critically important in leading through a crisis — it’s not about what you know; it’s about what you’re willing to learn Do not defer taking action until the last possible moment How to come out of a crisis stronger than ever with your team: Delegate decision-making and allow other people to make decisions within a framework Take pragmatic action Ensure you are still meeting and talking about your longer-term strategy beyond COVID-19 Examine how to position your organization so that when you come out on the other side of COVID-19 you are attractive to the marketplace and your customers Leverage OKRs Apply an experimental mindset and conduct experiments (one way you could do this is to utilize Kanban boards) Implement empirical process control Cultivate a culture steeped in trust and forgiveness Continual planning Reach out to others as a leader so that you’re not making decisions in a vacuum and are leveraging other people’s expertise Imagine what the leader that you most respect would do; how would they handle this situation? And how can you tap into this person’s expertise? Make the time to reflect and gain perspective Be courageous as a leader by being vulnerable   Mentioned in this Episode: The Dave Ramsey Show Brené Brown “A Guide to OKRs,” KOAN Agile Coaches’ Corner Ep. 5: “Exploring an Experimental Mindset with Adam Ulery” “What is a Kanban Board?” Small Business Administration (SBA) SCORE — Service Corps of Retired Executives Gartner The Conference Board Harvard Business Review “Microsoft Analyzed Data on its Newly Remote Workforce,” Harvard Business Review “Managing When the Future is Unclear,” Harvard Business Review “Leadership in Times of Crisis,” American Psychological Association “How to Survive a Recession and Thrive Afterward,” Harvard Business Review “The Downside of Flex Time,” Harvard Business Review “The Reopening Challenge: 5 Tips for Getting Back to Business,” Inc. “COVID-19 is Reshaping Business: 6 Tips for Coming Back Even Stronger,” Forbes   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 episode, Professional Scrum Trainer Eric Landes addresses the questions: "Will the Professional Scrum Master Certification help me get a job as a Scrum Master?" The Professional Scrum Master certification Bolsters your Credentials Of course there is no guarantee of a job with a certification, but I believe it helps you have the intelligent conversations around scrum when you have the background from passing a certification in the Scrum framework. If you are already working in IT, one way to do bolster your chances for a job would be to take the class and go for the certification.  Then in your current job, use Scrum with your team, at any opportunity you have.  Get Experience in the Scrum Master Role If you can volunteer for other teams within your organization.  This will help you get experience with the concepts.  Then you are positioned to be a Scrum Master in your current organization should the opportunity present itself.  Having the certification helps, and get as much experience as you can as you attempt to become a full time scrum master. Want to Learn More or Get in Touch? Register for our upcoming web meetings by visiting agilethought.com/events 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, Dan Neumann is joined by his AgileThought Colleague, Quincy Jordan!   In their conversation today, Dan and Quincy are diving into the world of online videogames — specifically Fortnite; the popular battle royale, sandbox game — and drawing comparisons between it and agility.   Having watched his son play Fortnite over the summer, Quincy saw how he remotely communicated with his friends online to come together as a team, seek out an objective, collaborate, and go after that goal. In this episode, Quincy not only highlights many of the similarities between online gaming and having an agile mindset, but he also shares some of what we (and our kids) can learn from playing these sorts of games and further improve our agility.   Key Takeaways The overlap between an agile mindset and Fortnite/other online games: In the game, you play in teams and the players coordinate and collaborate remotely through headsets In both agile teams and Fortnite, you need to come together as a team, seek out an objective, collaborate, and go after that goal In the game, you gather raw materials and architect right on the spot to create structures such as barriers or ramps (similar to the agile concept of solving problems with the resources you have at your disposal) They do team working agreements (i.e. before they start, they set out their goals and agree on what they’re trying to achieve) When their objective is at risk of reaching its goal (similar to a sprint goal), they reevaluate quickly, make adjustments, stay adaptable, and continue without losing sight of the goal What Fortnite/other online games can teach us about having an agile mindset: The team collaboration in Fortnite emphasizes teamwork and shows how having ‘hero complex’ does not get you to your goal (you have to work together, one person cannot do everything) In Fortnite, your character can lose energy and need time to recuperate. In this scenario, a teammate will ask another for help to spot them as they recover, which is very similar to how high-performing agile teams should behave (i.e. being transparent with one another if you need help) There’s a collective recognition that you win and lose as a team The teams in Fortnite are self-organized and not afraid to take risks and fail fast — this is key to growth They always stay focused on the overall objective, which is a crucial mindset piece for agile teams to have   Mentioned in this Episode: Fortnite Halo Discord The Decision: Overcoming Today’s BS for Tomorrow’s Success, by Kevin Hart   Quincy Jordan’s Book Pick: Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs, by John Doerr   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 episode, Professional Scrum Trainer Sam Falco answers the question: "Why do you say that Sprint Zero is an anti-pattern?" Why do you say that Sprint Zero is an anti-pattern? “Sprint Zero” is a label applied to the indeterminate period of time used to gather product requirements and analyze them before a Scrum Team can start developing the product. Although “Sprint Zero” appropriates a Scrum term, it isn’t part of Scrum, nor is it a Complementary Practice that enhances Scrum. Sprint Zero undermines Scrum and agility. Sprint Zero isn’t a Sprint The Scrum Guide tells us that “The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created.” That’s enough on its own to dispel the idea that Sprint Zero is a good Scrum practice. Sprint Zero rarely has a timebox— I have seen organizations where Sprint Zero lasted for months—and no potentially releasable product is produced by it. Sprint Zero inverts agile values The purpose of Sprint Zero is to generate comprehensive documentation. The practice rests on the false belief that we can and should understand and predict all of a product’s requirements before we start building. We often use the phrase “gather requirements,” as if they are some harvestable commodity. For complex efforts like software development, nothing could be farther from the truth. Requirements emerge as we build and are often obvious only in hindsight. Spending time trying to predict them is wasteful. Not only does Sprint Zero value comprehensive documentation over working software, it values contract negotiation over customer collaboration. The implicit promise of Sprint Zero is that once we have defined and analyzed our requirements, we can arrive at an agreement about scope and no further interaction with customers will be necessary until the product is completed. By attempting to define scope up front, we miss out on the value of working with the customer over the course of the development effort to ensure that the customers true needs are met. Sprint Zero undermines agile principles It delays the beginning of product development—so forget about satisfying the customer through early delivery of valuable software. It violates the principle of welcoming changing requirements. It prevents emergence of requirements, designs, and architectures. Articulate a vision and start building Sprint Zero is nothing more than the earliest stages of waterfall disguised by an agile-sounding term. But it’s not necessary—or possible—to know everything up front. All those features and requirements that seem so important during a requirements-gathering phase often turn out to not be needed at all. The best way to handle the uncertainty of product development is not extensive up-front analysis, but to articulate a clear product vision and start building toward it. Want to Learn More or Get in Touch? Register for our upcoming web meetings by visiting agilethought.com/events 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!

In today’s episode, Dan Neumann is joined by return guest, Andrea Floyd! Andrea is an enterprise agile transformation consultant at AgileThought. Andrea has 25 years of experience in software development and management. She is an innovator who has led multiple organization-wide scaled agile implementations, and she has also architected innovative solution strategies and roadmaps across many frameworks (including Scrum, Kanban, and the Scaled Agile Framework).   Dan and Andrea will be discussing the premise of agility and the common misunderstanding that it is only an IT ‘thing’ and is software-centric. Andrea explains how agility addresses needs across the enterprise and that it is about collaboration with many different areas of the business beyond IT. She shares how a shift from software agility to business agility drives the enterprise; and talks collaboration, feedback loops, design-thinking techniques, the importance of being customer-centric, applying agility across the organization, and key considerations around bringing the technology side and business side together.   Key Takeaways Considerations when shifting to a more business agility: Be careful not to create “us vs. them” scenarios (‘us’ as in the technology side and the ‘them’ being the business side) As leaders, it is important to open up about the way you think about Agility and the principles It is important to create a united effort of working together to achieve the desired outcomes (moving from ‘doing’ to ‘understanding’) Be aware of cognitive biases, for instance, the ingroup and outgroup bias (where people tend to ascribe positive behaviors/attributes to people they consider to be in their group vs. ascribing/amplifying negative behaviors/attributes to people they consider to be outside of their group) It is important to expand your ingroup bubble to at least your whole company (which would lead to more interpretation of positive intent and better collaboration) It’s not about the individual developer getting to done; it’s about the team getting to done Being more inclusive and valuing what every individual is bringing to the table has an incredibly profound impact Key pieces in shifting from a software (or IT-centric) view of agility to business agility: Start to reimagine roles and how you operate together The business side needs to welcome the technologists to their side/domain and vice versa Everyone needs to understand that there is huge value in understanding their customers/users and understanding the ‘why’ behind delivering Allow people to be free and feel safe enough to create and innovate Invite everyone into the full conversation Truly value being engaged Work towards building empathy between the people building the software and the people who will be using it Apply the Agile principles, practices, and mindset pieces across the organization Understand the ‘why’ behind why you’re doing agile practices as well as the intention behind them Key places to have dynamic conversations with technology and the business: Through backlog refinement — the inclusiveness comes from the product owner being able to articulate Come up with a more creative ‘how’ or an ‘incremental how’ The product owner can communicate “no” or “not yet” to their stakeholders The software on its own is not the product; there are other key pieces that create the ‘shrink-wrapped’ product “When we think about business agility, what we want to do is understand what it takes to really get that product into the hands of our customers” How you coordinate across the teams so you get that “shrinkwrapped product increment” is important Think beyond just getting the software to ‘done’ Key points around accelerating the value chain: Look to make ‘idea to value’ as short of a line as possible Reference The Age of Agile’s three laws of business agility: the law of the customer, the law of a small team, and the law of the network Empower your team and allow for autonomy Feedback loops with your users/customers are key Design thinking techniques are a great way to learn more about your customers/users Empathy is huge — it is the basis for innovation and creativity   Mentioned in this Episode: The Agile Manifesto Modern Agile — Joshua Kerievsky The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done, by Stephen Denning The Decision: Overcoming Today’s BS for Tomorrow’s Success, by Kevin Hart   Andrea Floyd’s Book Picks: Shelter in Place, by Nora Roberts   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!