Agile Coaches' Corner

In this episode, Professional Scrum Trainer Sam Falco answers the question: "Is it OK to plan several Sprints in advance?" I’ve seen this practice in many organizations. Product Owners plan four, five, even six Sprints of work for their teams. The result is something like a Gantt chart with Sprints instead of weeks as the unit of measure. It’s a bad practice with many drawbacks and no real benefit. It diminishes transparency The Scrum Guide’s description of the Product Backlog gives us our first clues that planning Sprints in advance is a bad practice. “The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.” Assigning Product Backlog items to future Sprints means that you’re splitting your Product Backlog into multiple lists. The order is more difficult to see, and instead of a single source of requirements, you now have several. The Scrum Guide also says that the Product Backlog is dynamic and constantly changing. Having Product Backlog Items scattered over a number of Sprints makes managing this dynamic change more difficult than if you have a single artifact. In one organization I was in, Product Owners would plan an entire Program Increment and then spent a significant amount of time trying to manage multiple forecasted Sprint Backlogs as well as the remaining Product Backlog. It diminishes self-organization When multiple Sprints are planned in advance, the Development Team loses its role in collaborating with the Product Owner to craft a Sprint Goal and select Product Backlog Items into the Sprint Backlog that they believe will help achieve that Sprint Goal. Often, no Sprint Goal is identified—instead, the goal is for the Development Team to “do all the things.” The Development Team’s autonomy is hobbled, and it is robbed of the opportunity to self-organize around a coherent, meaningful goal. It diminishes inspection and adaptation The Scrum Guide closes its definition of the Product Backlog by pointing out that while forecasting progress may prove useful, forecasting techniques “do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.” Planning multiple Sprints in advance means that we are making decisions about the future based on what we expect will happen. Sprint six is planned based on what we expect to do in sprints one through five, for example. We’re making assumptions about the future before we have a chance to validate what we’re doing right now. It tends to result in attempting to produce to a forecast rather than basing our work on current business conditions. But how do I forecast? Proponents of planning multiple Sprints in advance say that they need to do it in order to forecast release dates. But as Scrum Master Yoda said, “Always in motion is the future.” Planning several Sprints at a time, only to have to re-plan them as things change is wasteful and doesn’t create certainty. Instead, we should embrace uncertainty and incorporate it into our forecasts, providing a target range that widens the farther out we look. Forecasting with Scrum is best done by understanding our team’s velocity (as it actually is, not as we want it to be). We can use what we know about the team’s historical ability to deliver to make a “good enough” estimate of the least and most they are likely to produce.   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 on the Agile Coaches’ Corner, Dan Neumann is joined by a new guest, Michael Guiler! Mike is an Agile Consultant at AgileThought. He has been an Agile coach for over 13 years now and has tons of experience helping geographically dispersed organizations (both business and technology) transform to better achieve their goals. His focus is on helping organizations learn and apply the values and principles of the Agile mindset to continuously improve.   In this episode, Dan and Mike will be focusing on the topic of intent-based leadership and the key leadership characteristics that allow for intent-based leadership. Mike shares how an organization can begin to take the first steps towards intent-based leadership, how to avoid common pitfalls, and shares his best practical tips and advice on embracing intent-based leadership throughout the organization.   Key Takeaways What is intent-based leadership? What problems does it solve? Helps to get the entire team to chip in and no longer wait for approvals and sign-offs Takes the pressure off of one single leader and unlocks the potential of every employee The opposite of directive leadership Changing the pattern from leader-follower to leader-leader Those in the leadership level are not telling people what to do/how to do it; they are setting goals and directions The ‘followers’ are engaging their creativity, mind, and intelligence and leveraging those skills and sharing their solutions with the leadership (this gives the organization a great opportunity to learn and exposes leaders to things they hadn’t thought about before) Getting started with intent-based leadership/Characteristics of leadership to allow for intent-based leadership: Before the leader-leader pattern can take place a lot of growth has to take place Keep in mind that this process won’t happen overnight Immediately begin to address competence — leadership at all levels can’t thrive if your team doesn’t have the skills or knowledge to prioritize and take action Establish safety — mistakes will happen; it’s how we react to those mistakes that will enable leadership at all levels to thrive or to fail miserably Use mistakes as a learning opportunity rather than punishing an individual Be curious and ask good questions from a place of true curiosity Challenge your preconceived notions of how things have always been done Embrace new ideas and thoughts — there’s a real chance you’ll learn something! Allow time for the team to talk out loud Respect others opinions and encourage others to have their own point of view It’s hard and will take a lot of time and investment (but it’s money well-spent — the productivity will explode) It’s important to set guide rails in the technology world Focus on the goal/outcome instead of the ‘how’; set clear intentions and let the team figure out how Adopt the “I intend to” language pattern Mike’s intent-based leadership tips: Once the competency is established and you’ve gotten your organization thinking about it, it is important to establish safety (without safety people won’t bring their creative-selves or do anything new) It is key crucial for the team to know what the goals are Have an “ish” mindset; decisions and actions being taken won’t match yours and that’s OK! Overcome urges to command and control Be tolerant of differences and encourage different points of view Mike’s recommendation to further learn about intent-based leadership: Turn the Ship Around!: A True Story of Turning Followers into Leaders, by David L. Marquet   Mentioned in this Episode: Michael Guiler Agile Coaches’ Corner Ep. 84: “Getting to ‘Finish’ as a Scrum Team with Andrea Floyd” Turn the Ship Around!: A True Story of Turning Followers into Leaders, by David L. Marquet Forbes article regarding psychopathology in CEOs   Michael Guiler’s Book Picks: The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done, by Stephen Denning Leaders Eat Last: Why Some Teams Pull Together and Others Don't, by Simon Sinek   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 addresses the question: “How do you escape the tyranny of the burndown chart?” The Problem with Burndown Charts This was the question a student asked last week. I knew exactly what he meant. I experienced it myself with my first Scrum Team, and I’ve seen it many time since. Teams try to predict every task they’ll have to do during a Sprint, estimate the hours for each, and make sure that the team’s capacity is fully allocated. As the Sprint progresses, they discover new work. Work that was predicted takes longer than usual. The burndown rises instead of falling, or it plateaus. The burndown chart becomes a burden that destroys morale and effectiveness. After a few Sprints of this experience, teams either abandon the burndown chart or they start playing games to make the burndown “look right.” In both cases, the team loses out on a valuable tool for helping them achieve the Sprint Goal. Does the Scrum Guide Require Burndown Charts? To be clear, the Scrum Guide does not mandate the use of a burndown chart. Here’s what it says about tracking Sprint progress: “At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.”         Tracking total work remaining provides transparency about the team’s progress toward the Sprint Goal. That transparency allow the team to make informed decisions about how to adjust the scope of its work throughout the Sprint. If the team doesn’t know how much forecasted work remains, the Sprint Goal may be placed in jeopardy. A sprint burndown chart is one way to fulfill the need to sum up the remaining work and make that data visible. So why does the burndown chart so easily become a burden to the team, rather than a tool? Often, it’s because of a holdover from the mistaken belief that software development can be managed through predictive processes. Even in organizations that recognize the folly of predictive planning on a macro level, teams fall into the trap of thinking they can and should plan every minute of a team’s capacity. How do we use a Burndown Chart Effectively? Software development falls into the realm of complexity. Even within a Sprint, we have to allow for emergent understanding of the work. Requirements, understood well enough for the work to begin, become clearer. New work emerges as a result. Teams that have strived for efficiency in allotting their time find that there’s no room to adjust as new information and understanding becomes available. The secret to avoiding the tyranny of the burndown chart has nothing to do with the burndown chart itself. The secret is to let go of the belief that we can know everything up front and that efficient time usage is a worthwhile goal. Instead, strive for value delivery, select work that the team understands well enough to start on, and don’t strive for 100% utilization. The only thing certain about software development is that it is filled with uncertainty. In Sprint Planning, you need only look a few days into the future, and allow remaining details to arise as work gets underway. 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 this week’s episode, Dan Neumann is joined by frequent guest of the show, Quincy Jordan — principal transformation consultant and agile competency lead at AgileThought! Together, they are exploring COVID-19 as an agile accelerator.   In the agile space, there has been a long-time myth that face-to-face is synonymous with colocation and that you cannot have effective agile teams if they are not colocated. However, in the past year or so, many companies have been beginning to consider going to a hybrid remote model. But, when COVID-19 hit, their 12-month transition plans quickly became one-week transition plans. And though this has been very difficult for many, this acceleration due to COVID-19 has actually been a good thing in many cases — which is what Dan and Quincy will be talking about today!   They discuss which types of things got accelerated, beliefs about agility that got challenged due to COVID-19, what the ‘new normal’ post-COVID-19 may look like, and how these changes will be made to be sustainable going forward.   Key Takeaways Beliefs about agility that got challenged due to COVID-19: Those people in the agile space that were especially adamant that you cannot have effective agile teams that are remote were shown that it was possible  Some people believed that doing training in a distributed way would bring the quality down — however, the quality of training that is being delivered has not gone down since going remote What COVID-19 has accelerated: When pressed, many people are able to do very impressive things and accomplish more than they thought possible It accelerated ingenuity and creativity It accelerated the decisions to collaborate with one another as teammates and to quickly come together on a situation to figure out the most effective solution It helped accelerate clarity on what was truly important to accomplish It has driven companies to really start embracing business agility a lot more Agility went from a concept that companies only thought about to a concrete concept that they embraced Organizations have been focusing on value more due to embracing the agile mindset (and COVID-19 has been pushing this to further bounds) It has helped push organizations to further their alignment on business agility and focus on the problems that need to be solved COVID-19 has also accelerated businesses beyond those in software (it permeated into all facets) Challenges regarding COVID-19 and the acceleration it has brought: How do we maintain alignment between business and IT in this remote world? (How often do we need to meet? What do we need to be aligned on?) Video conference fatigue How do we ensure that the right problems are being solved, that the vision is clear, that the business objectives at hand are clear, and that the teams know how to tie their work to meaningful outcomes for the business? People don’t adapt as fast as technology What might the new ‘new normal’ look like post-COVID-19? There most likely will be more remote work and more emphasis on collaborating remotely There may be a bigger demand for remote tools (such as digital whiteboards) and they will become even more efficient going forward People will most likely be more intentional about how they are showing up to video conferences with clearer goals in mind   Mentioned in this Episode: From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver, by Johanna Rothman and Mark Kilby The Decision: Overcoming Today’s BS for Tomorrow’s Success, by Kevin Hart   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 addresses the question: "How do we avoid Scrum adoption pitfalls?" Last week, a student asked me what are some common pitfalls that we see when organizations shift to Scrum from a “big design upfront” process like waterfall. A big one is that they think it’s a silver bullet Adopting Scrum doesn’t solve problems overnight. It doesn’t solve problems at all! Scrum will surface the problems in your ability to deliver so that you can fix them. Too many organizations falter when Scrum runs up against an organizational impediment and “the way we’ve always done it” wins out. One example of this phenomenon is when there’s an onerous change management system that prevents code from getting into production. Scrum teams complete an increment and it sits there waiting until someone approves it to be moved to production. Sometimes, the wait is so long that multiple increments pile up. Some organizations will cling to that change management system even though it’s getting in the way. Success comes when they adapt to the new way of working. At one organization I worked with, the solution was to set up an experiment with one team working on a less risky area of code. Once they proved that they could safely put code into production without breaking things, it paved the way for broader changes to their process. Another pitfall is that the organization doesn’t really adopt Scrum  In many cases, organizations claim to adopt Scrum, but what they really do is apply Scrum terminology to existing roles and processes. I frequently see the term “Product Owner” used—or maybe I should say abused—as a new name for a Project Manager. But those Project Managers carry on pretty much the way they did before. They lack any of the accountabilities or authority of a Scrum Product Owner. They shift from using Gant charts measured in weeks to plotting out a project in Sprints over several months. And that’s another way this behavior manifests. They’ll use the name of Scrum events without understanding their underlying purpose. A Sprint lacks the focus of creating a usable increment. “Daily Scrum” is a daily status report. “Sprint Review” is a carefully orchestrated smoke-and-mirrors show with limited, if any feedback or collaboration with stakeholders. Without using all of its roles, events, and artifacts—and the rules that bind them together—you’re not using Scrum. You’re probably perpetuating your existing system. You know, the one that wasn’t working for you before. This is the realm of “Scrum, but.” And “Scrum, but” is not Scrum at all. They don’t make other necessary changes Even when an organization adopts Scrum’s mechanics, they sometimes find that Scrum doesn’t provide the benefits they hoped for. Delivery improves a little, but it soon plateaus and it’s a struggle to keep improving. That’s because other changes are necessary to really reap the gains of Scrum. A common organizational structure is to have teams organized around technical layers or components. For example, a User Interface team, a Data Access Team, a Service gateway team, and so on. Scrum requires that we produce a working increment each Sprint, which means one that’s in usable condition. Teams organized by layers or components face numerous handoffs and challenges integrating their work. There’s a loss of transparency, and they struggle to compete that working increment. The solution is to form teams that can deliver complete features that cut across all layers. Scrum doesn’t tell you to do that, but it works best if you do. Scrum also doesn’t tell you to adopt good DevOps practices, or incorporate Kanban techniques, or to refactor your code. They’re all still good ideas. Scrum is incomplete for a reason and that’s so that you can identify what works best for your organization. You have to go beyond Scrum. I talked about the pitfall of “Scrum, but,” earlier. But “Just Scrum” isn’t enough. You need “Scrum, and.” Adopting Scrum requires a shift in organizational mindset. Without that, people revert to familiar behavior, even if that behavior wasn’t effective. And adopting Scrum can’t be an endpoint. It’s the beginning of a journey of experimentation and continuous improvement. In the Trainer Talk episode “Why Does Scrum Have So Many Meetings?” a few weeks ago, I mentioned that implementing Scrum requires intentional, thoughtful organizational redesign. That’s true of implementing the basics of the framework, but it’s equally true about the wider ecosystem that Scrum teams work in. And just like I said in that earlier episode, that’s why you need a good experienced Scrum Master—and sometimes more than one—to guide your organization’s Scrum adoption. 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!

Joining the podcast once again one of Dan’s favorite return guests, Christy Erbeck! Christy is a principal transformation consultant at AgileThought and a Certified Dare to Lead™ Facilitator (CDTLF). 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 are exploring the topic of uncertainties. There’s a lot of uncertainty going on in the world right now with COVID-19. We’re in this awkward gray zone that Christy refers to as “the muddy middle.” And, as much as we’re getting used to this ‘new normal,’ there are still adjustments and daily changes that can be very disruptive to our psyche. So, in today’s conversation, Christy and Dan are taking a deep dive into exploring these uncertainties and Christy provides the tools and tips you need to better adapt during this confusing time and make the most of it!   Key Takeaways What is this ‘new normal?’ The ‘new normal’ can refer to “the new better” in reference to organizational transformation or change (because with these new changes come new ways of working and new ways of thinking that create a better outcome than what was previously in place) In reference to what we’re currently experiencing, ‘our new reality’ may be a better phrase ‘New normal’ is a concept of accepting the current disruption as our new reality to have an easier time adapting to the new way our day-to-day lives look The sooner we recognize that this is our reality the better able we will be able to adapt, grieve our old reality, and find a way to make this current reality the best we can Christy’s tips and tools for adapting to the ‘new normal:’ First, recognize where you are personally and take some time to reflect and go inward and ask yourself: “Where am I? How am I feeling?” Christy uses a journal to track her mood every day so she’s better able to reflect on where she’s at Recognize that we cannot, at this moment, move into comparative suffering (i.e. saying that your suffering is worth more than someone else’s and vice-versa) Own how you feel Dig deep into your ability to empathize and seek to understand how others are experiencing the ‘new normal’ Be overly generous with yourself (which will give you the space and capacity to be overly generous with those in your circle and community) Adopt the concept “assume good intent” because, as you take care of yourself, you’ll have more space to assume good in others around you (which gives extra grace with your interactions with people) Come together and allow everyone to share their voice and stories Reach out for help if, in your process, you are still struggling (because you don’t have to do this alone) Anti-patterns/How we should not respond: Comparative suffering Competitive storytelling Listening to respond   Mentioned in this Episode: APA’s Help Center SILK + SONDER (Self-care monthly planner and journal subscription service) “10 Eye-Opening Statistics on the Mental Health Impact of the Coronavirus Pandemic,” Forbes The Road Less Traveled, Timeless Edition: A New Psychology of Love, Traditional Values and Spiritual Growth, by M. Scott Peck The Four Agreements: A Practical Guide to Personal Freedom, by Don Miguel Ruiz Turn the Ship Around!: A True Story of Turning Followers into Leaders, by L. David Marquet 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 week’s episode, Dan Neumann is joined by special guest and AgileThought colleague, 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).   Last week on the podcast, Dan and Quincy Jordan were exploring the topic of getting to ‘start’ as a Scrum team and overcoming the inertia of being stuck. Continuing on this theme, Dan and Andrea figured it would be fitting to discuss what comes after getting to start. I.e., start finishing! So, in this episode, they discuss everything that happens between starting to finishing, getting to ‘done’ incrementally, challenges Scrum teams run into with starting ‘finishing,’ and Andrea’s tips for getting to ‘done’!   Key Takeaways Challenges Scrum teams run into with starting ‘finishing’: They get stuck with reimagining the new way of working and understanding how to get to ‘done’ incrementally They face analysis paralysis by overthinking (which prevents them from adapting to this new way of working) They may defer risk due to their fear of failure They have a reluctance to let go of yesterday and falling back on the previous practices they were comfortable with because it’s easier/what they know They take on more work without considering what’s going on with the rest of the team What does “finish” or “done” mean? All organizations have their own, unique definition of ‘done’ Some organizations even have multiple definitions of done for different levels (i.e., ‘done’ at the story level, done at the sprint level, done at the release level, etc. [it depends on their build and release cadence]) Andrea’s tips for teams for getting to ‘done’: It is important for the team to discuss what “finish” or “done” means and to come to a consensus Make the definition of “done” visible in the team room (the more visible it is, the easier it is to refer to and to guide conversations) Get creative in the visibility of your team’s definition of ‘done’ — Andrea suggests making team t-shirts with the slogan, “Our definition of done: ______” Look for opportunities to care and work with your team members to support them in this journey (retrospectives and daily scrums can be great opportunities for positive reinforcement, calling out work well done, and celebrating successes) Work together as a team and help one another Consider adopting a catchphrase for your team such as, “No man/woman left behind” Stay focused on the sprint goal as a team The practices established in Scrum will help you understand the ‘why’ behind what you’re doing and how you’re working Use the Five Whys to understand the root cause of why some team members may be stuck in their ways and not wanting to adapt Get the team to a point where they feel safe and courageous enough to share the challenges they may be facing that are preventing them from achieving their goals Create an environment that feels safe and supports learning, courage, and experimentation Make safety a prerequisite You can achieve great wins as a leader by empowering your team, helping them become autonomous, and teaching them the ability to self-organize   Mentioned in this Episode: Agile Coaches’ Corner Ep. 83: “Getting to ‘Start’ as a Scrum Team with Quincy Jordan” The Failure Bow The Five Whys Waco (TV Mini-Series) Tiger King (Netflix Series)   Andrea Floyd’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!

Joining Dan Neumann this week is frequent guest, 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 this episode, Dan and Quincy are talking about what it takes to get from zero to ‘start’ as a Scrum team. They speak about the different types of starting, the strong values needed for getting started, the foundational pieces you need a strong understanding of, some of the bad practices and anti-patterns teams fall into when getting started, and additional key pieces to keep in mind after a Scrum team is established.   If you want to know how to go from zero to start — stay tuned in!   Key Takeaways Scrum values that are key to getting started: Courage is needed to get to the point of deciding to start A willingness to try something that you haven’t tried before Adaptation is crucial Be comfortable moving forward in the face of ambiguity Being okay with starting before everything is “perfect” or “right” (because you can’t ever get it “right” if you don’t start at all) Key points and understandings to getting to ‘start:’ Clarify the roles in Scrum Refer to the Scrum Guide to understand the foundations of the framework Determine who is going to fill the role of Scrum Master and the Scrum Product Owner It is critical to understand that the Scrum framework is already so scaled down that you really can’t take anything out If you do not have enough team members to separate the roles out it is possible to start, but not recommended Having the product backlog in place helps keep the team focused — especially early on (because it helps the team know what they’re headed toward is truly producing value) Start with the questions: Do we have a team? Do we have a group of people who are committed to doing the work? Are they cross-functional enough to do the actual increment at the end of every sprint? Do they have a product backlog that helps identify what to do? Take note of what isn’t in the Scrum guide You don’t need to forecast four or five sprints out (too much will change before you get to that point); if you have enough for one or two sprints you can start Camaraderie is an essential part of doing Scrum Leadership support/buy-in is not 100% necessary to get started You should have a commitment to allocate a cross-functional group of people to the effort and allow them to focus The team needs to collaborate and work together; you can’t have islands within the team Key pieces to understand after getting to ‘start’: A way to gain leadership support/buy-in is to get some early, quick wins and show the value of what your Scrum team is doing When the leadership support is there, the onus is on the team to make sure that they’re communicating well with leadership Communicate well with leadership by not only letting them know what’s great but letting them know the challenges as well Frequent communication within the team outside of the daily Scrum is crucial   Mentioned in this Episode: The Scrum Guide   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

In this episode, Professional Scrum Trainer Eric Landes addresses the questions: "hy would the Scrum guide not use ceremonies and events interchangeably?" Introduction In some classes, students will refer to the scrum events as ceremonies.  Yet the guide refers to these as events.  So why would the Scrum guide not use ceremonies and events interchangeably?  My answer typically is something along these lines: What is a Ceremony? While we might be able to use these words interchangeably, I think there is a reason for the distinction.  There is not a clear explanation in the scrum guide why this is.  But if we look at the definition of “Ceremony,” we might find some hints.  According to dictionary.com, one of the definitions of ceremony is "the formal activities conducted on some solemn or important public or state occasion".  I think the key is in formal and solemn.  In fact, most of the rest of the explanations include the word or a variant of the word formal. What is an Event? In contrast, dicitonary.com defines event.  "something that happens or is regarded as happening; an occurrence, especially one of some importance."  The scrum guide says this about events - "Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.” The talk of creating regularity is better defined by event than ceremony to me.  And this speaks to scrum as a whole.  It is more about a framework that helps solve complex problems, it's not a solemn process that teams must follow. Scrum Should Minimize Other Meetings I also emphasize to students that the events are supposed to minimize the need for meetings not defined in Scrum.  If team members are saying that Scrum makes most of their time about meetings, I will respond that this is not from the scrum framework.  This may be an issue where prior meetings for non-scrum frameworks are still on the books and may not be necessary!  As a team take some time and evaluate the need for these meetings. Collaboration is Key Sometimes I will tell classes that Scrum and other agile frameworks were invented to make sure that developers meet in a regular cadence.  Collaboration was not a necessary component of software development when I first started.  Agile frameworks just showed us knowledge workers how much we needed collaboration and gave us events that made sure we were collaborating!  Conclusion So whatever we call these events, make sure to follow the framework, and use them to encourage and foster team collaboration! 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 a special return guest — 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.   Today, they’re going to be exploring the topic of how to ask powerful questions. Powerful questions can lead to powerful change if they are asked in the right way. In this episode, Christy explains what makes a question powerful vs. a not-so-powerful one, how to ask powerful questions, when and when not to ask a powerful question, and important qualities and skills for a facilitator or coach to have that is asking these powerful questions. Christy also shares some fantastic resources for further reading on the subject and provides some examples of what powerful questions look like!   Key Takeaways What makes a ‘powerful question?’ A powerful question is one that gets the person being asked to think about the situation in a way that they may not have if the question had not been asked Powerful questions elicit a thoughtful response They provide a way to help the individual being asked to become ‘unstuck’ The Co-Active Training Institute defines a powerful question as: “A provocative query that puts a halt to evasion and confusion” The person asking the question is inviting the client to clarity, action, and discovery at an entirely new level They help people think differently How to ask powerful questions: Kickstart coaching sessions by asking, “What’s on your mind?” to simply begin the conversation in a way that allows the coachee to bring forward a topic in a way that is non-judgemental and invites additional inquiry Ask a question in a neutral way versus a ‘loaded’ way Stay neutral and ask the question in a curious way rather than in a judgemental way Use the Five Whys technique Take into consideration the layering and sequencing of the questions you’re asking Make sure that the person you’re engaging with is interested and engaged Ask yourself if you have earned the right to ask the question in the first place (i.e. a level of mutual respect has been reached and the person being asked believes you to be credible) Important qualities and skills for a facilitator or coach asking these powerful questions to have: Understand what type of questions or decision-making needs to happen in the moment Understand the different types of questions and the different intents and outcomes that those questions will provide Have a natural curiosity and perspective of care when working with clients Create space and allow for silence for people to answer the questions When shouldn’t you ask a powerful question? When you don’t have time to debrief and explore Potentially, in a group setting (it is important to consider the dynamic of the room) Ask yourself, “Is now the time to ask this question?” because the trust and safety may not be strong enough yet to be asking certain questions Questions that are uninvited, at an inappropriate time, or out of line Examples of powerful questions: “What do we need to do to wrap this up and have clarity around our next steps?” “What’s preventing us from moving forward?” “What’s keeping [decision] from actually being enacted?” “Tell me more” questions Clarification questions Open-ended questions such as who, what, when, where, why, and how Powerful resources to learn more about powerful questions: The Co-Active Training Institute The Coaching Habit, by Michael Bungay Stanier The Complete Book of Questions, by Garry D. Poole Vertellis — a card game   Mentioned in this Episode: Co-Active Training Institute The Coaching Habit: Say Less, Ask More & Change the Way You Lead Forever, by Michael Bungay Stanier Five Whys Technique The Complete Book of Questions: 1001 Conversation Starters for Any Occasion, by Garry D. Poole Vertellis card game   Christy Erbeck’s Book Picks: Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs, by John Doerr Employee Experience: Develop a Happy, Productive and Supported Workforce for Exceptional Individual and Business Performance, by Ben Whitter   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!