Agile Coaches' Corner

Recently, Sam and Dan discussed velocity; an important metric to agile teams, and what it looks like when used correctly vs. incorrectly. In keeping with this theme, they’re exploring two other important metrics that are also often misused and misunderstood: story points and user stories.   Story points and user stories are all-too-commonly misused. In this episode, Sam and Dan debunk some of the common misunderstandings, share how both concepts are often misused, personal experiences in their roles as agile coaches, and how to correctly use them.   Key Takeaways What are user stories? How can they be misused? User stories come from extreme programming as one of the practices that were advocated for during its emergence User stories were born out of a need for telling a story about what the users want the system to do (and use that instead of the detailed requirements documentation that nobody actually reads) Kent Beck is attributed to coining the term “user story” User stories have good intentions and work in a particular context but are often misused and come with a multitude of unintended consequences If the user story framework helps you, great — but if it doesn’t, don’t use it (don’t think that you have to use it because it “makes you agile”) The idea of the user story framework is to concisely suggest to developers what a user might want to do with a system (it should also answer: What kind of user? What kind of behavior? And why?) Good vs. bad uses of utilizing user stories: Misuse: If you simply want to do something as a developer, put a task in your backlog; you don’t have to twist it into a user story format Misuse: Writing everything down and believing that the problem has been clearly communicated (Just because it is written down, doesn’t mean there is a shared understanding) Correct use: When user stories are used to have a conversation about what we want the system to do or what the user wants the system to do Misuse: If the user story is short enough, it isn’t necessary to have an abundance of written documentation (If you’re finding yourself needing to attach a lot of written documentation to the requirement, it is most likely too broad of a scope for a user story) Misuse: You don’t need to know all of your stories ahead of time to get the project done Correct use: Understand that in creating user stories and moving through your agile journey, many of them will be wrong and it’s unknowable Correct use: Conversations should be happening more frequently and be broken down into smaller pieces so that everyone has a clearer picture Tips for leveraging user stories effectively: Get in the mind of the user so that you can better come up with some strategies for appealing to their needs or fulfilling their needs Address the acceptance criteria/conditions of satisfaction (i.e. How do I know when I’ve achieved this goal?) Try to make the user story about what the user is trying to achieve (i.e. conditions of satisfaction) Reference User Stories Applied: For Agile Software Development, by Mike Cohn Don’t take user stories too seriously Remember the three Cs: Card (because they used to be written on index cards), Conversation, and Confirmation Good vs. bad uses of story points: Misuse: Story points are often conflated with days (i.e. how long it will take to do something) which, in turn, become used for velocity metrics (which is then often weaponized against the team [listen to episode 135]) Misuse: You shouldn’t be predicting too far out with story points (instead, talk about what you can do in the next couple of sprints and then go from there) Misuse: Similarly to user stories, don’t take story points too seriously (i.e. don’t take them as means of precision beyond having had a conversation around something that is possible to do) Correct use: Story points are simply unitless measures of relative size (in sprint planning you can worry about the finer details and granular approach) Misuse: There is no value in breaking up story points into multiple points, resizing the stories, etc. (It’s supposed to be a close-enough/estimate… it’s not supposed to be precise) Misuse: Software development is unpredictable and filled with unknowns, trying to force specific predictions with story points is counterintuitive Correct use: Breaking things into smaller pieces with user stories is a lot easier to figure out the size of the task Closing Thoughts: Don’t take user stories and story points too seriously Don’t think you know more than you do Cut yourself some slack and cut your team some slack Break things down into smaller and smaller pieces The smaller something is, the more easily it’s understood and the fewer unknowns there are   Mentioned in this Episode: Agile Coaches’ Corner Ep. 135: “Exploring Velocity: What is iI? How Do We Measure It? How Can We Leverage It?” Lean Coffee User Stories Applied: For Agile Software Development, by Mike Cohn Killer Nashville Devil in a Blue Dress: An Easy Rawlins Mystery, by Walter Mosley   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, Dan Neumann is joined by return guest, and Senior Consultant in AgileThought’s Innovate line of service, Adam Ulery! Adam is a perpetually curious, continuous learner who is always willing to encourage others to try new things (as he very often does himself). He is very focused on helping organizations clarify and meet their business outcomes, and he loves to help companies become resilient and rediscover their curiosity.   In this episode, they are exploring the topic of strategic vs. tactical decisions and actions in agility. Adam explains why it is important to make this distinction; why, as leaders, we need to be focused on strategy more than tactics; the key differences between a strategic and tactical perspective; and tips, techniques, and advice for navigating strategy vs. tactics.   Key Takeaways Why is it important to distinguish between strategic vs. tactical decisions and actions? With the distinction, leaders will often focus too much on the tactics and not enough on the strategy or strategic duties Organizations are often focused on the tactical details of what’s happening in their business and less on the strategy — distinguishing between the two allow for a more healthy/appropriate balance Why is focusing more on tactics rather than strategy bad? What are common anti-patterns? As a leader, you shouldn’t be too involved in the micro-details of what to do to fix an issue (instead, let the people closest to the work do the work) As a leader, you should be focusing on the higher-level leadership activities rather than getting granular on what the experts should be doing on a micro-level If you’re too focused on the details of what your team is doing, you’re slowing down the decision-making Employees that are being watched/queried by a higher-level leader are going to end up slowing down and deferring to them to make decisions where they don’t need to (which eventually leads to demotivation down the line) If the leader continues to operate in this way (of micro-managing) the employees don’t have the time to cultivate and nurture the competencies and higher skills needed to be self-sufficient Focusing on tactics more takes eyes off of meeting the strategic outcomes that are desired Instead of focusing on: “Does the team have the right priorities?” focus on: “Is what we’re putting out to market this month aligned with our organizational goals?” Leaders should be focusing on higher-level things (i.e. business outcomes and ensuring they are aligned to the organization’s strategy) Focusing on tactics as a leader also takes eyes off of improving the system in which people are working (for example: building customer loyalty by delivering what they need quickly and reliably) If leaders are focusing on embracing technical excellence and the small details of how to actually get those activities coordinated and executed on, then they’re not focusing on the higher-level strategy of building customer loyalty or the long-term view If leaders are getting in the trenches and focusing on low-level things, it distracts them from being able to think about long-range goals The differences between a strategic and tactical perspective: A tactical perspective is shorter-range and a strategic perspective is longer-range If you’re a leader, you add value by executing on the strategy, creating vision, and growing your people On the operational level, you add value by “doing the thing”/executing on deliverables Neither is better than the other; it’s just about how you want to add value, where you’re focusing, and where you want to spend your time Tips for how to navigate strategy vs. tactics: Leaders need to work on their fears associated with letting go of control and do what they need to do in order to let others take control and be self-sufficient Leaders need to enable and equip their people by making sure that they are competent and skilled before they take control (if you give control at the wrong point, you risk massive downsides) As a leader, allow your people to be accountable (and teach them how to be accountable); and as they build their skills, competencies, and they’re able to take over; let them be accountable As a leader, it is your duty to make sure that everyone knows what the strategy is and that they understand it (because it is hard to align to a strategy if you don’t know what it is) Do introspection, self-study, look in and analyze your own behavior and actions as a leader — are you too “in the weeds” with tactics?   Mentioned in this Episode: Adam Ulery’s LinkedIn Turn the Ship Around!: A True Story of Turning Followers into Leaders, by L. David Marquet Agile Coaches’ Corner Ep. 135: “Exploring Velocity: What is It? How Do We Measure It? How Can We Leverage It?” Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, by Jake Knapp Stanford d.school   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 a return guest and AgileThought colleague, Michael Guiler. Mike has been an agile coach for over 15 years and has experience helping geographically dispersed organizations (in both the business and technology fields) to transform and better achieve their goals. For the last year and a half, Mike has been with AgileThought as an Agile Consultant.   Together, Dan and Mike are discussing employee engagement and what organizations and leadership can do to improve it. Mike shares 2020 employee engagement statistics, what creates engagement, the differences between managers and leaders (and why this is important), and the key tips on what we can all do to drive employee engagement forward.   Key Takeaways 2020 employee engagement statistics: Only 36% of the people in an organization are actively engaged 50% of the people are “going along for the ride”/are ambivalent 14% of people are actively looking to “get off the train”/actively disengaged That adds up to 64% of the people in an organization are not giving the best they can give The good: the actively engaged employee percentage has been consistently going up year after year since 2009 What can we do to improve these statistics? What would make employees more engaged? People want to do know why they are doing what they’re doing, have autonomy over it, understand what the goal is, and have a purpose Don’t micromanage people as a manager or leader in an organization Transition managers into leadership roles Managers in an organization need to make sure employees understand autonomy, mastery, and purpose if they really want to help motivate and engage their people (Daniel Pink’s book, Drive) Managers need to make sure that the organization’s vision is very clear to everyone Ask, “Where are we headed? What are we trying to achieve?” Becoming self-managing and engaging will lead to employee motivation but the goal first needs to be understood If the vision is too big or too far out, employees can’t visualize it (as a leader, you need to break this vision down into smaller, shorter-term goals so that getting from A-Z is understood) The product goal should be tied to the organizational vision If something isn’t fulfilling the goal, end it/throw it away The goal should be shared early, often, and everywhere Share examples of things that were accomplished in the organization that fulfill said goal Managers vs. Leaders (and how leaders can improve employee engagement): A manager is somebody that is task-oriented, activity tracking, and only concerned about their own actions A leader is focused on the “us”/what “we” achieved, improving the environment for those who work within it, and enabling their team to succeed An organization’s duty is to develop its managers into leaders, hire leaders, and foster an environment for leaders Keep in mind the recent shift to the Scrum Guide from “Servant-leader” to “leading by serving” It is important for managers/leaders to create a safe environment for people to engage without punishment/ridicule for making mistakes As a leader, it is important to understand that sometimes good decisions can lead to bad outcomes and bad decisions can lead to good outcomes (so don’t punish, but rather explore this concept and create safety for employees) Leadership is not proportional to the time spent talking in meetings You have to give people the space to talk, explore, and share A tip for giving others space in conversation: Ask yourself before speaking, “Does it need to be said? Does it need to be said by me? And does it need to be said right now?” Tips for leaders for improving engagement: Provide clarity on what the problems are that employees are expected to take on There are many different ways to solve any given problem — as a leader, it is your job to point out the problem and give space to your people to explore the options and solve it their way Create a safe environment and boost engagement in meetings by asking questions, inviting people to speak, sharing the spotlight, resisting the urge to provide answers Emphasize “we” language, not “you” or “I” (i.e. if the team experiences “failure,” don’t place the blame on a single individual) Own your own mistakes as a leader   Mentioned in this Episode: Michael Guiler’s LinkedIn Agile Coaches’ Corner Ep. 121: “Self-Managing vs. Self-Organizing with Michael Guiler” Agile Coaches’ Corner Ep. 87: “Intent-Based Leadership with Michael Guiler” “What is Employee Engagement and How Do You Improve It?” Gallup “Historic Drop in Employee Engagement Follows Record Rise” Gallup Drive: The Surprising Truth About What Motivates Us, by Daniel H. Pink Thinking in Bets: Making Smarter Decisions When You Don’t Have All the Facts, by Annie Duke Tribal Leadership: Leveraging Natural Groups to Build a Thriving Organization, by Dave Logan, John King, and Halee Fischer-Wright Lean Enterprise: How High Performance Organizations Innovate at Scale, by Jez Humble, Joanne Molesky, and Barry O’Reilly   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!

Most literature around starting an agile (or scrum) team makes the assumption that you will be starting from scratch. But oftentimes, you’re joining an organization with teams that are in the middle of a half-built or fully-built product.   As an agile coach being brought into an organization, you usually have to work with pre-existing teams that are in the middle of their product life cycle with pre-existing behaviors and norms. In this episode, Dan and Sam are exploring what it is actually like starting in the middle of an agile journey and offer their tips and advice for agile coaches in addressing common challenges associated with pre-formed teams, products in the middle of their life cycle, and organizations already in the middle of their agile journey.   Key Takeaways The different ways you can be “in the middle”: In the middle of an agile journey In the middle of team formation (or by working with an already fully-formed team) In the middle of building a product A combination of all three Addressing challenges of joining a team that is in the middle: There needs to be a mindset shift around the whole team being accountable (rather than each individual for themselves) When a team already has its behaviors and norms established, they can be nervous with new roles and expectations being introduced It is important to respect the team’s history and knowledge Scrum doesn’t say “abandon your job titles,” rather, ‘‘You work out how you want your team to look. As long as you can get to done.” (i.e. it’s okay to stick with your original job titles as long as you remember that you’re all in this together as a team; not individuals) Those in senior positions (i.e. those with more expertise and experience) should shift into a mentorship role for those junior to them Recognize that the team is going to have to take smaller bites at the apple every sprint instead of taking on these huge challenges that will take months Create safety by delivering in smaller chunks Do regression testing more often Slow down and automate the old stuff Addressing challenges of a product life cycle that is in the middle: Sometimes, adding value to the product might be in removing features that nobody (or few people) use, that are slowing down the delivery of new features that people will use If it’s expensive and not giving your team/organization a return on investment, reevaluation should take place around why you are spending money to maintain this feature Look at value investments from a product standpoint even when you’re not starting a new product from scratch A challenge with jumping into products in the middle is that the strategy has been laid out in a fairly plan-driven way (the requirements are largely thought to be understood) “Scope creep” isn’t actually a monster; it’s a friend that helps you have a better understanding of your requirements Bring users in earlier and ask for feedback earlier (this helps get users engaged, interested; you’re able to correct course mid-flight to create something that users actually want) You don’t have to wait until a sprint to adjust Addressing challenges of joining an organization that is in the middle of its agile journey: This usually takes the form of A) the organization has tried to do an agile transformation themselves and now recognize they need help, or B) they had a consultant or coach come in previously, dismissed them when they thought they were done, everything went off the rails, and now they need to bring in another consultant once again to fix it “[Agile is] a journey; not a destination. So we have to continue going [forward]. I think it’s actually a misnomer to say that we, [as agile coaches], come in in the middle of an agile journey. It’s all middle. Once you take that first step, it’s ‘middle’ for the rest of time.” Agile journeys take a long time; there’s not a magic wand to shift behavior The organization needs to learn how to do the learning because it never stops Adam Ulery’s tips for being brought into an organization “in the middle”: First, understand where the organization is right now What do they do really well right now? Where are the gaps that need to be addressed? Conduct an assessment (doesn’t need to be formal) to understand their current challenges What are their goals? Their business goals, their agile journey goals, and where they would like to be in the not-so-distant future (i.e. six months to three years)? Based on this, develop a plan on how to move forward with them   Mentioned in this Episode: Agile in the Enterprise Survey by Gartner Sam Falco’s LinkedIn Adam Ulery’s LinkedIn   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

This week, Dan and Sam are discussing an important metric to Agile teams: velocity. If used correctly, velocity can be an incredibly helpful tool for teams to leverage to forecast future sprints and understand what it is that they can accomplish in a given amount of time. If used incorrectly, however, it can wreak havoc on a team’s ability to work together and deliver value incrementally.   In this Scrum-centric discussion, Sam and Dan take a look at what velocity is; how to measure it, why it is important to teams, leadership, and the organization; how we can effectively leverage it to improve a team’s output (rather than damage it); and key takeaways to keep in mind.   Key Takeaways What is velocity? Why is it important? Velocity is an output-based metric that measures what the team typically does/how much they do over a certain period In Scrum, velocity is usually measured within sprints Velocity is history; not what you hope for (i.e it is a past measure) Velocity is a great tool for teams to understand what they typically do in a given sprint and use it as a measure to know what they could do in a future sprint Scrum teams who are truly self-managing can use velocity as a way to think about what they might do in their upcoming sprint given what they’ve done in the past Velocity is similar to the term “velocity” used in physics (i.e. in physics, velocity is not just speed; it’s speed and direction) — If your teams don’t have direction, the speed at which they do things is meaningless How is velocity measured? There are a number of ways you can measure velocity (from story points to a “number of items completed” approach, etc.)Though velocity is often expressed in “points,” it isn’t needed to measure it in points (velocity is simply how much stuff you have done in whichever way you want to measure it) Points are not a forecast or the capacity that the team is expected to hit The pressure to measure in points can actually be more effort than it’s worth (if you’re already measuring in days, why use a conversion chart of days=points? Use what the team already knows and is working by) Measure in as small of pieces as possible (the tinier something is the more accurately you can assess how long it is going to take) Velocity anti-patterns: Velocity can be one of the most abused metrics in all of software development if the wrong person in power gets a hold of it Sometimes when leadership gets a hold of velocity metrics, they punish or put pressure on teams when they don’t meet the same markers that they did in the previous week/month/sprint Some organizations see the Scrum Master’s role as making sure that the team is constantly increasing its velocity Assigning “points” to people on the team (velocity is a team measure; not a measure of individuals) Just getting stuff done that isn’t moving the product forward may make your velocity look great, but really you’re spinning your wheels and not going anywhere You shouldn’t be managing velocity; velocity should be helping you manage other things (such as what teams can do to forecast) Why can measuring velocity improve your teams? As a Product Owner, you can use velocity to forecast beyond the next sprint You can use it as a measure to revise and adapt each sprint Key takeaways to keep in mind: When you change the team composition, the velocity will be affected and most likely drop (even if you are adding someone because they need time to get used to working together) Velocity is not about precision (through craving certainty, we want to apply a number measure to velocity) but teams begin to beat themselves up and spend too much time in refinement activities to have a stable velocity (rather than actually doing the work)   Mentioned in this Episode: The Mythical Man-Month: Essays on Software Engineering, by Frederick Brooks Jr.   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, Dan and Sam are joined once again to discuss agility — more specifically, the side effects of being agile! The side effects of agility are often not the reasons why you should start an agile transformation, but they are still very valuable and helpful to know about.   In this episode, Dan and Sam discuss the positive side effects that organizations might want out of agility, the indirect effects (both positive and negative) of putting certain agile practices in place (or not putting them in place), and how to address the challenges that come along with losing focus on the primary principles of agility.   Key Takeaways Why should you start an agile transformation? Look no further than the Agile Manifesto Common side effects organizations want out of agility: People will be happier We’ll get more stuff more quickly/twice the work and half the time Increasing customer involvement Improving the prioritization of features Increasing team buy-in and involvement Adapting to change during development Better understanding the project’s status More efficient planning and estimating Continuous risk management Delivering the project needed at the end Achieving the right level of project structure Potential negative side effects and how to combat them: The Agile principle “welcoming changing requirements” does not mean adding requirements When a priority is changed that means something else isn’t important anymore It is key to clarify the priorities and remind everyone of the consequences/cost of changing them Look at the cost of waiting to start the new thing vs. abandoning the old thing Building lots of stuff that you don’t ship and lengthy requirements lists that you may never be able to get to (therefore generating excess inventory and waste) You should instead focus on delivering value in increments Use the “MVP” (minimum viable product) strategy i.e. getting something potentially valuable to your customers quickly so that they can evaluate it and you can measure it Launching a product vs. the value you want to bring When you don’t embrace agile fully and attempt to scope out a large project by creating a static backlog and fix the team members, you will eat through the backlog (the best-case scenario is that you get a product and the worst-case scenario is that you don’t get a product and have a lot of work-in-progress) Think about your outcome rather than the activity than you’re engaged in or some artificial target When the goalposts are set and there aren’t true inspection and adaptation, it’s not an agile approach If the primary benefits of agile are not met, the secondary benefits will not matter as much and the agile transformation itself will be brought into question and challenged When there is a purpose to what they’re doing, employee satisfaction and fulfillment goes up   Mentioned in this Episode: The Agile Manifesto Agile2021 | Agile Alliance Becoming Agile: … in an imperfect world, by Greg Smith and Ahmed Sidky Thinking, Fast and Slow, by Daniel Kahneman Noise: A Flaw in Human Judgment, by Daniel Kahneman, Olivier Sibony, and Cass R. Sunstein   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, Dan is joined by fellow AgileThought colleague and return guest, Andrea Floyd! Andrea is an enterprise agile transformation consultant at AgileThought with over 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).   In their conversation today, they discuss delivering value using Scrum — what it looks like, why it is important to focus on, how to introduce the concept of value delivery in the product life cycle, and how to begin measuring the value of what you’re delivering.   Key Takeaways Why is delivering value using Scrum important? People want to know why they’re doing what they’re doing (and understanding how they are delivering value using Scrum answers that question) Understanding what value you’re bringing ensures that you’re working on the right thing/s at the right time In order to make certain business decisions, it is key to measure: “Are we getting the outcomes that we’re seeking?” and, “Are we actually making a difference in the eyes of our customers or users?” Do they see and feel what we’re providing and delivering in terms of capabilities is valuable? How and when to introduce the concept of value delivery in a product life cycle: There are a few entry points to consider At the organizational leadership level, they need to be outlining what they feel is valuable to the organization If leadership outlines what is valuable to the organization, everybody is able to check in with that Someone at the top of the organization should be setting the alignment (and allowing it to cascade down through the organization) At a product or a project level, you should start thinking about delivering value by encapsulating it in features (and having those features be on your product roadmap [which will then inform and drive your product backlog]) At a product or team level, apply your focus to talk about value at the feature level (think about the mechanisms to timebox features) Tips, tools, and techniques to measure the value of what you’re doing: Answer the question: “Have we moved the needle in anybody’s world? How so?” Organizations should be embracing transparency and trust so there is more access to communication (and so people know the context they’re operating in) Consider looking at how you do your portfolio management and have that work be hand-in-hand with investment decisions (which then will influence how you organize around the work or the product) Leverage techniques in work management tools (such as Jira, Azure DevOps, etc.) where you can put effort at a feature level (just like you would do at a story level) Use some form of relative sizing to forecast based on what you know today If you are able to do feature points, map the features on the product roadmap Leverage product goals to help your team ensure that the emergence of their product backlog aligns with the product goal Use product goals to help you focus on the right items (in the right sequence) in your backlog, and refine those features so that your team can communicate to stakeholders and leaders how they are doing as they move forward Leverage timeboxing — it is critical You should be able to explain to your team why you are working on something (if you can’t, push it down on your backlog until you can) How do we know when a feature is ready to be consumed by a team? It is important to have a definition of “ready” so that the team is on the same page Ideally, you have fields that indicate the state of readiness a feature needs to be at before it’s eligible for consideration to begin working on Ask: “What does ready look like for a feature?” and “What information needs to be present?” Collect data and measure: “Are we getting value out the door?” and “Are we getting value into the hands of our customers or users?” There should be a level of accountability on the people that are responsible for refining the backlog (if you want to make the cut, make sure that everything is clear) Tips regarding features and value delivery: Business decisions have to be made — that means you’re going to have to get comfortable with forecasting (and forecasting gets easier with the more data points you can reference) Having an understanding of velocity is important because it is helpful in forecasting and understanding if you’re biting off more than you can chew Andrea recommends having your product roadmap at a feature level and having a strong partnership between the product ownership and the team to help forecasting at a feature level Andrea recommends having the roadmap be based quarter-by-quarter, one year out How to know when you’re done with a feature: Use the definition of “done” at a release level (this is where you can articulate what features are eligible for release based on the release definition of done)   Mentioned in this Episode: Agile Coaches’ Corner Ep. 132: “Waterfall to Scrum: How to Measure the Value of Agility with Sam Falco” Jira Azure DevOps The Scrum Guide Azure Coaches’ Corner Ep. 118: “Big Room Planning 101 with Andrea Floyd” Agile Coaches’ Corner Ep. 29: “How to Combat Cognitive Biases for Effective Agile Teams”   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, Dan and Sam are answering another fascinating listener question. This listener wrote in, “We are in an organization that has been going through an Agile transformation. Our leaders have been asking for metrics to compare Waterfall vs. Scrum. They want to know if we are delivering more with Scrum. How do we measure this?”   Navigating how to measure values when transitioning from Waterfall to Scrum can be a difficult challenge. How do you measure whether something is a successful initiative or not? What are the key differences in what metrics you should be measuring between Waterfall and Scrum? How do you measure the value that Scrum brings? What are some of the key metrics you should be measuring? Tune in to find out!   If you have a question of your own (or would like to share your thoughts on today’s episode), you can email the podcast at Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!   Key Takeaways How do you measure the value your organization gets from Scrum vs. Waterfall? Typically what is measured in Waterfalls is “iron triangle” stuff (i.e. “Were we on time? Did we stay on budget? Did we complete the scope?”) However, these things don’t really indicate whether or not you are actually getting value out of the effort “Too often, what we’re actually measuring in Waterfall was: ‘Did we get all the work done in a certain amount of time and within budget?’ And that’s not what we’re interested in, in [an] Agile effort.” — Sam Falco Find different ways to measure the value, whether it’s in actual dollars earned or cost savings or goals achieved It is more important to measure the return on investment and the value it brought to customers rather than “Did we push it across the finish line?” Measure based on value rather than on velocity It’s not uncommon for those from a Waterfall world to measure how many tasks were completed rather than delivering valuable increments (which is critical with Scrum) Regardless of whether it is Waterfall or Scrum, you might measure: generated revenue, saved spending, etc. Evidence-based management as a method for measuring the success of an Agile effort: Reference The Evidence-Based Management Guide from Scrum.org It will provide you with a number of key value areas to help determine whether you are actually adding value, as well as some suggestions for key value measures for each of those areas Listen to episode 107 of the Agile Coaches’ Corner, “Evidence-Based Management 101 with Sam Falco” Think about the metrics you have in place now and whether or not they apply now (i.e. “Does this metric we’re using help us determine the current value for our products?”, “Does it help us determine time-to-market?”, “Does it help us determine our ability to innovate?” And if not, ask, “Do we really need it?”, “Are we measuring something that matters and drives results?”) Measure lead time (if it shrinks dramatically, this is a good sign that this is going to work for your organization) “Take a look at what metrics you’re measuring now. And if those were valuable in telling you whether or not your efforts were worthwhile, they might be appropriate now.” — Sam Falco Even though your process is different, you can still measure using a lot of the same metrics — you just have to look at them in a different way The most important things to measure are around the value (“Is the stuff we’re producing actually valuable to people?”) What are some of the ways we can measure value? Quality metrics (Has your quality increased?) — Agility tends to come with increases in quality because of a limit of work-in-progress and helping the teams focus Look at trends; not single points in time Have your escape defects gone down? Has your technical debt gone down? Look at things like, how long does it take you to get a release ready for production? Is it taking less time? One of the values of an agile way of working is that you build in feedback loops for looking at your own processes more frequently than Waterfall Through this, analyze trends and track process improvement  There is no single way to measure output from Waterfall to Scrum You have to always be aware of what the metric is actually telling you and evaluate not only your processes but whether you are using the right metrics (and whether they are telling you things that are helpful to you) Releasing in Waterfall tends to be infrequent, painful, and fragile. Releases should be frequent and near-automatic in Scrum. Measuring the pain of releasing is an indicator of how easy or difficult it is to capture value Measure deployment frequency (“How often do you actually deploy to production or customers and users?”) Measure: “Are customers happy with the number of releases? Are they happy with the features they’re getting?” Measure “mean time to first failure” — though it is an old metric in software development, it can still be valuable (i.e. “How long does it take for you to break something?” This should be getting longer and longer as your quality goes up) Keep track of process improvements   Mentioned in this Episode: Evidence-Based Management Guide | Scrum.org Agile Coaches’ Corner Ep. 107: “Evidence-Based Management 101 with Sam Falco” The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers, by Ben Horowitz   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 frequent guest of the show, Quincy Jordan, a Director in AgileThought’s Innovate Line of Service.   The last time Quincy was on the show, they spoke about the excursions you take along an Agile journey and what those look like. Today, they’re taking this discussion one step further and exploring how to maintain the work that has been done along an Agile journey.   On the “other side” of an Agile transformation, we want the work that we have done to stick. In this episode, Quincy shares his key tips for maintaining an Agile transformation once it has gotten to a place of sustainability, how to shift from a transformation team to an environment that has Agile Champions, why you should be implementing Communities of Practice, and the role that leaders play in communicating and instilling the practices formed during the transformation.   Key Takeaways What are transformation teams and how do they fit into maintaining the Agile transformation? A transformation team is critical to the health of an Agile transformation Transformation teams are almost like Scrum Masters to the transformation itself Once the thinking has changed and you’ve arrived at the part of the Agile journey where you’re only looking to maintain what you’ve achieved, you don’t necessarily need the transformation team When disbanding the team it is important to have Agile Champions to lead and guide the Communities of Practice (which are key in maintaining the way of thinking around continuously learning [and unlearning] based on the current needs and problems you are looking to solve) Members of the transformation team can join the team of Agile Champions or become Agile Champions for other teams of practices Be cautious in disbanding the transformation team too soon as you may revert to the old way of doing things Have a succession plan for your Agile Champions to maintain the new way of thinking Quincy recommends 3‒4 Agile Champions for a single Community of Practice The role communication plays in Agile transformation maintenance and continuous learning: Communication is beyond critical to maintaining the transformation — especially coming from leadership (Quincy recommends no more than monthly communication from leadership) An important aspect that leadership has to remember is that everyone does not know what they know (gaps in communication occur when leadership assumes that everyone knows what they know) It’s important for the leadership team to reinforce the new way of working and what it needs to look like Reinforce desired behavior by highlighting “bright spots” (i.e. when you see the behavior you want, point it out) Trust and build empathy (when trust is absent, the “ugly truth” of what’s happening in a project gets buried vs. when trust and empathy are present, the whole team works together toward solving the problems that arise) Maintain and bring transparency into the work How to reinforce the ways you deliver and maintain a value-driven perspective: Ideally in the transformation, the organization has adopted a value-driven perspective vs. merely tracking To maintain this, have dedicated teams Shift the mindset of having one specialist for one job to one of building an overall team competence Implement rolling forecasts with quarterly revisiting Maintain the perspective of funding so that you don’t revert to this notion of going to go down to a granular level (i.e. figuring out how much a particular thing is going to cost 12-months down the line between a 2‒5% margin) You want to maintain a way to fund investments and evaluate that funding earlier on (and on a quarterly basis) It is good practice to leverage OKRs to maintain a transformation (because you’re being clear in a simplistic way on what your objectives are and how you’re going to hit them) Closely align your portfolio based on your current dedicated teams and any planned dedicated teams   Mentioned in this Episode: Agile Coaches’ Corner Ep. 129: “Excursions Along the Agile Journey with Quincy Jordan” Switch: How to Change Things When Change Is Hard, by Chip Heath and Dan Heath    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, Sam and Dan take a deep dive into a fantastic listener question, “What happens in a scaling environment with the Scrum Master?”   What happens when you have one Scrum Master with many teams or many teams and multiple Scrum Masters? With the Scrum Guide not explicitly providing guidance on this topic, Dan and Sam explore the realities of focusing on multiple teams as a Scrum Master, whether or not a Scrum Master can or should handle multiple teams, and real-world examples of scenarios they have seen play out with both. They also discuss the risks and challenges that come along with multiple Scrum Masters coordinating across many teams and share their advice on increasing communication and helping your teams (and organization) understand Scrum.   Key Takeaways Can a Scrum Master handle multiple teams? With so much on your plate as a Scrum Master, it is ideal to only handle one team at a time (especially if they’re very early on in their Scrum journey; they’re going to need a lot of your attention and focus) It is possible to handle multiple teams but it is dependant on how far they are into their Scrum journey (if one of them is far along and another is newer, it is far easier to manage multiple) It doesn’t make sense to split a Scrum Master’s attention between multiple teams if they are all start-ups As a Scrum Master, you are already splitting your attention between your team and the organization (in helping them use Scrum effectively) — dividing your attention even further between teams can spread you too thin If you are acting as more of an Agile Coach with less focus on the organization, it may be possible to handle multiple teams An ideal scenario would be to have a Scrum Master master per team in the organization and have them coordinate and communicate across these teams Note: In order to be a great Scrum Master, you need to look beyond limiting your role to organizing meetings, enforcing timeboxes, and responding to the impediments people explicitly report (reference Michael James’ Scrum Master Checklist to see the full breadth of what you could be doing in your role as a Scrum Master [if you have the time and capacity]) Advice for multiple Scrum Masters coordinating across multiple teams: Have a Scrum Master Community of Practice — make sure that the Scrum Masters are meeting regularly to discuss what’s going on in their teams When a Community of Practice is successfully implemented, you can exchange new ideas which can really help the agility of the teams and the entire organization You can work together on the common challenges you are all facing and rally together to figure out solutions Your understanding of Scrum and your ability to help teams will grow exponentially A cautionary word about establishing a Community of Practice: you may not get outside ideas as easily which can develop a sense of “groupthink”  Be sure to seek outside ideas — always ask: “What are we not doing? And what can we learn from the broader community?” (Try attending conferences, events, or webinars) Get outside of your organization’s four walls whether that be through podcasts, books, or other resources — always be open to grow The risks of Scrum Masters coordinating across too many teams: The teams may struggle to understand the need for Scrum itself (the “why” behind Scrum becomes lost when Scrum Masters cannot spend enough time with a single team) which leads to dysfunctional behavior Being commanded to do things for the sake of doing them rather than “We need to do Scrum to deliver well” leads teams to become disengaged Simply finding the time to do sprint planning together and coordinate the teams Closing thoughts and key takeaways: The Scrum Master is an invaluable part of the Scrum team — do not try to short change your teams in order to save a little money (i.e. by spreading them thin in managing multiple teams) The Scrum Master will help your team be effective and stay effective By having a Scrum Master focus on one team they can better help them integrate with the larger organization If you need to have multiple teams per Scrum Master, try to have some balance (in that not all of their teams are new or old)   Mentioned in this Episode: Michael James’ Scrum Master Checklist The Scrum Guide Tampa Bay Scrum Masters Guild The Nexus Integration Team Agile Coaches’ Corner Ep. 126: “What is Agile?” Agile Coaches’ Corner Ep. 3: “Communities of Practice with Quincy Jordan” Frederick W. Taylor “Managing the Development of Large Software Systems,” by Dr. Winston W. Royce The Legacy of Conquest: The Unbroken Past of the American West, by Patricia Nelson Limerick Ph.D. The Dead March: A History of the Mexican-American War, by Peter Guardino   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!