Agile Coaches' Corner

In this episode, Professional Scrum Trainer Sam Falco addresses the question: "If we have stories that aren't finished by the end of the Sprint, how do we get credit for the work we've done so far?" Introduction I get that question a lot, both in training classes and when I'm coaching teams. It stems from a fundamental misunderstanding of what a Scrum Sprint is for and how Scrum Teams should measure their effectiveness. How does seeking credit relate to the Agile Manifesto? Two of the principles behind the for Agile Manifesto are relevant: "Working software is the primary measure of progress." It doesn't talk about credit. "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." Seeking credit for unfinished work violates both principles. There's no value in unfinished work! OK, mister smart guy, I hear people saying, but it happens. Sometimes things don't get finished. What should we do about it? Achieving the Sprint Goal without finishing all Sprint Backlog items In the most positive scenario: the team achieved the Sprint Goal, but there were some extra items in the Sprint Backlog that weren't directly related to it. We have a working, thoroughly tested Increment that meets our definition of "Done," but we also have these one or two things we were doing, and we've run out of time. If that's the case, congratulations on creating a potentially releasable increment! As to those extra bits that you thought you could finish, have a conversation with your Product Owner. Is this work worth continuing? Make sure it is reflected in the Product Backlog, so the Product Owner can order it appropriately. Maybe it should go into the next Sprint, maybe not. It's the Product Owner's call. In your Retrospective, talk about the fact that the Development Team brought work into the Sprint that it couldn't complete, and talk about why it happened. Did the team overestimate how much work it could do? Adjust for that in future Sprint Planning. Did your team add the extra work as a kind of "stretch goal," or add new work to the Sprint Backlog late in the Sprint because it was running out of work to do, and wanted to "fill up the time?" Talk about whether those are practices that add value. That half-completed work is a form of waste. The Sprint Goal was not achieved Another scenario, less positive, is when the incomplete work means that the team failed to achieve the Sprint Goal. There's no new working increment. If that's the case, the team needs to figure out why that happened. This becomes another topic for a Retrospective. Was the Sprint Goal too ambitious?  Worse, was the Sprint Goal simply, "Do all the things?" Learn to create better Sprint Goals. If the Sprint Goal was reasonable, figure out what kept the team from achieving it. Do better the next Sprint. Examine your practices and figure out how you can achieve the Sprint Goal next time. Just don't kid yourself that you "get credit" for incomplete work. Don't engage in accounting tricks, where you split the Product Backlog Item and include the incomplete work in this Sprint's velocity and hope to finish the rest in a future Sprint. Carrying over work from Sprint to Sprint subverts the Product Owner's accountability for maximizing the value of the product and of the Development Team's work. How do we measure effectiveness of a Scrum Team? Scrum Teams should measure their effectiveness by the value they deliver, not by how busy they are from Sprint to Sprint. If the organization values productivity measures rather than value delivery, the Scrum Master should work with the organization to re-orient its outlook. The Scrum Master will also probably need to work to establish safety for the team, so that they don't feel obligated to try to fill up every minute of their time. Conclusion The purpose of a Scrum Sprint is to produce a thoroughly tested product Increment that is in useable condition. There is no "credit" given for work that isn't complete in Scrum. You either produce an Increment by the end of the Sprint that meets your definition of "Done," or you don't. You either fulfill your Sprint Goal, or you don't. There's no middle ground. 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 repeat guest and AgileThought colleague, Quincy Jordan! Quincy is a Principal Transformation Consultant and Agile Competency Lead who has been with AgileThought for just over two years. Prior to AgileThought, Quincy was the transformation lead for Pivotal’s Atlanta office, where he consulted with clients to help them reach enterprise scale. Quincy also served as a principal consultant and agile coach at SCRUMstudy.com for over six years.   In their discussion today, Dan and Quincy are talking all about disruptions in these unprecedented times. Right now, disruptions, especially in the transformation space, are incredibly challenging. Though, there is a silver lining given the circumstances; Disruption can also lead transformation where there wouldn’t have been without the push. So in this episode, Quincy and Dan highlight some of these transformations that they’re seeing currently happening within companies and the silver lining of what it could mean for these companies in the long term.   Key Takeaways Transformations currently happening within organizations: Airlines have had to revisit their business model and reward programs (such as extending reward points) Companies are making very quick adjustments and shortening their feedback loop Companies also have to respond very quickly which is causing them to figure out what they need to respond to and prioritize Companies have a new focus that has emerged: they need to figure out the true important problem that they are solving Companies are needing to figure out creative ways to continue operating during this time They are adding services (like curbside pickup) and figuring out what services to subtract (such as offerings that are not applicable or appropriate during this time) Obtaining professional certifications have gone remote as well (such as on Scrum.org) Companies and individuals are understanding what is important to focus on now and moving more quickly to get it in place They are figuring out how to limit their risk by figuring out what to respond to and what not to They are limiting risk by shortening their feedback loop (sometimes to even a matter of days) They are leveraging their infrastructure and their ability to use Cloud technologies to scale up and roll out new changes  They are making sure that the company’s values stay central to the decisions Final thoughts and questions around transformation: COVID-19 has really challenged the agile space as many of its principles are grounded in being in person/communicating in person It has proven that remote facilitation and coaching is possible When someone’s back is pushed against the wall all of a sudden new solutions arise because you have to It’s not just about being Lean or Agile; it’s about figuring out the right problems to solve as quickly as possible ‘What are the things that are being disrupted that will lead to true transformation and then what things are being disrupted that are being put on pause and will be revisited later?’ ‘What disruptors that are happening now as a result of all of this will create a new norm that becomes what we have transformed into?’ Are we changing for now and then going back or is it a permanent change in how we do things? There is more need and delivery on remote agile coaching and remote transformation consulting due to not being able to go on-site (will this be more of a permanent offering going forward or is it just transient until everything settles down?)   Mentioned in this Episode: Mike Rowe “Amazon temporarily suspending Amazon Shipping service” Scrum.org Scrum Alliance MURAL   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 technical stories should be used in Scrum?" Overview I have been asked how technical stories should be used in Scrum.  Great questions, and of course Scrum has a framework, while not specifically talking to this issue. When discussing technical stories, I typically am thinking about things like product performance, system availability, and security.  I refer to these as non-functional requirements, and the Scrum guide does not specifically speak to NFRs.  However, the scrum guide has this to say about the product backlog: "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. " So, looking at the scrum guide definition it would seem that we can put NFRs in the product backlog.  Of course, the last sentence of this part of the scrum guide: "The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering." means that the team needs to work with the Product Owner on NRFs that belong in the product backlog. Example of a Non-Functional Requirement Here is an example of an NFR that might be used in the backlog.  The team has a screen on an application that shows personal information, including credit scores to a sales administration user of your application.  Your security team has deemed that Personal Information like this cannot be displayed due to certain laws within different countries. Your product owner could add a PBI that describes hiding data on the Sales administration screen, which is not adding functionality.  Refine the Definition of Done I also tell students that NFRs that apply to multiple PBIs might be a candidate for definition of done.  For instance, if we have a security requirement that all code must be run through a static code analysis and then dealt with, we might put running a static code analyzer against source code as part of our definition of done.  Update the Acceptance Criteria Another way to deal with an NFR is to place it in the Acceptance Criteria of a PBI. Let's say we have a feature that includes posting data to an external data store.  The requirement was that after a sales transaction the sales data needs to be pushed in that data store within 10 minutes of the transaction.  We could easily put that into your Acceptance Criteria. Conclusion The bottom line is that while Technical Stories, or Non-Functional Requirements are not mentioned explicitly in the Scrum Guide, the framework gives teams ways to handle them.  And in typical self-organizing fashion, it is up to the team to determine the best way to handle this for their application. 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 once again joined by his colleague, Quincy Jordan! Quincy is a Principal Transformation Consultant and Agile Competency Lead who has been with AgileThought for just over two years. Prior to AgileThought, Quincy was the transformation lead for Pivotal’s Atlanta office, where he consulted with clients to help them reach enterprise scale. Quincy also served as a principal consultant and agile coach at SCRUMstudy.com for over six years.   Today, they’re talking agile psychology and the rise of the agile Jedi. They go beyond the general skills and practices of agile to the key mindset pieces and various ways of thinking. Similar to a Jedi, agilists need to also go on a journey of mastery to improve all aspects of their skills. So tune in to find out more about agile psychology and begin on your path to becoming an agile Jedi!   Key Takeaways What is agile psychology? Being more in tune with how things are impacting the teams From a human standpoint, you’ll have an easier time getting teams to perform better Understanding people better and then understanding how to use that information effectively Evaluating things like reading the room and reading microexpressions — and not only picking up on them but knowing what to do with that information What does it mean to be an agile Jedi? It is a play on Star Wars — Jedi is a master of certain skills, so in reference to agility, it is referring to going beyond agile coaching to a true mastery of agile psychology and understanding how you influence vs. manipulate, etc. It’s about mastering the soft skills, reading microexpressions, seeing microaggressions, etc. Quincy’s tips for coaches and project managers: It’s important to ask yourself if the project was truly successful (i.e. it’s not always just about getting the result — ask yourself, ‘Are you contributing to a sustainable model?’ or ‘Is this a sustainable business model that goes toward business agility?’)  As a coach, it is important to teach behaviors and skills rather than a shift in mind-shift Bad practice: project managers that are more concerned about if the process was followed rather than if the outcome was achieved It’s important to understand that the individuals on your team understand the psyche of the role they’re assigned in an agile framework (i.e. you can’t just spray paint a lime orange and call it an orange!) When you’re moving someone from one role to another during an agile transformation it is important to take psychology into consideration It’s important to consider the ‘why’ behind the Agile Manifesto Agile coaching vs. Agile psychology: A key difference: getting into the experience that those that you’re influencing are having i.e. influence vs. manipulation The difference between influence vs. manipulation is the intent If you’re operating in agile psychology, you want to influence, not manipulate Helpful tools, tips, and skills around building agile psychology: Active listening training can be helpful in helping you to empathize with the person you’re listening to and forcing you to put your own thoughts aside and genuinely listen — critical thinking is also crucial Micro-expressions and negotiation training is beneficial in learning how to read others (the agile psychology part comes in when you learn what to do with this information) If you can empathize with someone it puts you in a better position to help them in shifting their thinking that is more beneficial for the whole   Mentioned in this Episode: The Dave Ramsey Show (Podcast) National Public Radio (NPR) Active Echolocation   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 complaint: "I don't like Scrum because there are too many meetings." At first glance, that seems like an odd thing to say, because there are only four meetings. The Meetings in Scrum Sprint Planning is timeboxed at up to eight hours for a one-month Sprint. It's usually shorter for shorter Sprints. The Daily Scrum, as the name implies, happens every day, but it's timeboxed to no more than 15 minutes. Sprint Review takes no more than four hours for a one-month Sprint, and it's usually shorter for shorter Sprints. Sprint Retrospective maxes out at up to three hours for a one-month Sprint. Like the other two big events, it's usually shorter for shorter Sprints. In a one-month Sprint then, you're spending no more than 15 hours in the big events, and for the Daily Scrum, five or so hours spread out in fifteen-minute increments. And that's out of roughly 160 hours per month. That means that we're talking about twelve to thirteen percent of your time in meetings that are designed to make the remaining 87 percent more effective. It's not actually that much time. So, what drives the complaint that Scrum has too many meetings? Scrum Might be Adding Needed Structure One driver comes when Scrum is being introduced into an environment where there aren't many existing meetings. Usually, this is an organization that is emerging from a startup culture, where there is a more wild-west style, with an informal network of ad-hoc communication. As startups grow, that informal network starts to break down. A framework like Scrum ensures that the necessary coordination and collaboration occurs. Otherwise, meetings metastasize across the calendar. Get Rid of Some Old Meetings More commonly, I hear the complaint in the context of an organization that already has a ton of existing meetings. Scrum events are overlaid like a veneer on existing process and meetings, which are retained without examining them to determine if they're providing value. The Solution The solution is not to add Scrum to existing process and meetings. Scrum is a radical replacement for an ineffective, bureaucratic culture--including all those meetings that aren't providing value. Odds are, the Scrum events supply all the value you need for effective collaboration and delivery. If you find that you really do need more structure than Scrum provides, you can always add it back in. Regardless of which direction the concern about too many meetings comes from, implementing Scrum requires intentional, thoughtful organizational redesign. That calls for an experienced, effective Scrum Master who is adept at navigating all levels of the organization and helping achieve business agility. 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 excited to be joined by someone outside of AgileThought, Yvonne Marcus! Yvonne specializes in teaching home management (which is the process of effectively running a household) with an agile twist. Her mission is to help parents develop flexible home management solutions using agile principles to leave them with more time for themselves, quality family time, less money spent, and a more productive week.   Yvonne Marcus shares how you can begin to implement agile into your home with her invaluable tips and tricks in this episode! She shares exactly how you can start bringing the agile process into your home, how to introduce your family to it, and actionable tips to take in getting started. Yvonne truly illustrates how applying agile principles can take your family from surviving to thriving!   Key Takeaways What is home management? Everything you have to do in your house to make it run (doing the dishes, cooking dinner, taking care of your kids, etc.) The process of effectively running a household Ways to apply agile to home management: You can use Scrum boards at home for your kids so they know what they need to do for the day (and lessen their dependency on parents to guide them through every step) The kids can contribute to the backlog during their family sprint meetings (ask your kids: “What needs to be done in the next two weeks?” or “What do you want to do in the next two weeks?”) Families can also discuss behavioral problems at the sprint meetings and discuss what an appropriate consequence could be for said behaviors by involving them in the process (similar to a team working agreement) Yvonne’s tips for bringing Agility into your home: Yvonne uses DAKboard for their sprint goal board where she keeps track of their daily schedule, count downs to important events, sprint goals, etc. She recommends whiteboarding and putting everything either in a Google Sheet or using an application that creates to-do lists (such as Microsoft To-Do) Do not ask anyone in your family to start using a new piece of software that they do not already use (because if they’re not used to it they will not use it and you’ll fail with your first implementation of trying to run agile at your house!) You can use Scrum, Agile, Kanban, etc. — whatever works best for your home! Do your daily Scrum first thing in the morning An important question to ask yourself is: “How much time do I need to take care of myself today?” (Because if you don’t set aside self-care time at the very beginning of the day you will always find something in your home that is more important that needs to be done and you’ll forget about it) Create a sustainable pace with the principles behind the Agile Manifesto (it’s not just about the work)Stick with it even if it’s not perfect the first few times Create a continuous feedback loop by asking your family what went well that week, what didn’t work, modifying, and implementing changes Ask yourself: “What is the simplest thing you can do to create a solution for the start?” Don’t go over the top; just start with what you have Take the four tendencies quiz (it can be helpful to understand who is on the “team” and how to communicate in a way that will be most receptive for them) Where Yvonne recommends getting started with implementing the Agile process in your home: Start with the daily standup (because being able to reconfigure time so that everyone’s time is valued will be one of the most eye-opening spots) If you start with the daily standup you’ll see the most immediate success Everyone should provide input so that everyone knows they have a weight in what is going on inside the home   Mentioned in this Episode: Yvonne Marcus “Agile programming — for your family” Bruce Feiler’s TEDTalk The Secrets of Happy Families:  Improve Your Mornings, Tell Your Family History, Fight Smarter, Go Out and Play, and Much More, by Bruce Feiler DAKboard Microsoft To Do Whiteboarding Yvonne Marcus’ Podcast: Your Agile Home Airtable ClickUpTrello iCalendarGretchen Rubin — The Four Tendencies Quiz Ethical Hacking Courses on Udemy   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: "Can Scrum and Kanban work together?" Introduction In my classes I often get asked about the differences between Scrum and Kanban.   Can Scrum and Kanban work together, how can that work?  Typically people will talk about one team doing and Kanban, typically an Operations type team along with other Scrum teams, typically feature teams. Scrum and Kanban can Coexist The short answer is Kanban and Scrum can coexist.  Scrum.org has a class called Prfessional Scrum with Kanban.  This was created by Kanban expert Daniel Vcante and Yuval Yevet a Professional Scrum Trainer.  Both of Daniel and Yuval have extensive kanban experience and have been working in the Kanban community Yes, Kanban and scrum can coexist. How does that actually work, you are asking? Let's think about this. Kanban is about flow and Kanban principles and practices do not conflict with the Scrum framework.  The principles for Kanban are: start with what you know and agree to pursue incremental evolutionary change and respect the current process, rules responsibilities and titles. Within Scrum, we  have a built in way to achieve evolutionary change, because we inspect and adapt.  The retrospective and daily scrum are ways that this can be achieved.  Limit Work In Progress There is some limit work in process in Scrum, in Kaban it is more explicit.  Making processes explicit is another Kanban practice that makes sense, Kanban implements feedback loops and we improve collaboratively and evolve experimentally.  Again all of these seem very compatible with the scrum framework So we're not staying with Kanban and scrum together, you are  getting rid of anything within the framework.  We are saying kanban practices and some of those tools can help you achieve flow within a scrum framework.   And you get the benefits of the focus of scrum what scrum team practices that they're used to. Getting Started How will scrum team begin with what they do?  What is one thing they can do is begin with Kanban in scrum.  For instance, if the teams forecasts five stories done in the current sprint, but the team  consistently misses one or two stories in a sprint, these Kanban metrics can help with the cause.  Metrics for Scrum with Kanban For instance the Aging working process metrics used in a daily scrum so that can help the scrum team focus on that question with data, are we going to meet our forecast or not?  If not the team can decide to focus and swarm on one item, get that item to done and continue to finish PBIs in the sprint.  Hopefully this helps the team focus on getting to done, and issues that prevent the team from achieving their forecast.  I would recommend the aging working process metric as a great way to start work with your scrum team using Kanban in your daily scrum. Other practices like visualizing your workflow and limiting WIP will help that focus as well.  Conclusion If you are want to increase your teams focus, I recommend reading up on Scrum and Kanban.  Even taking the Scrum with Kanban course, which goes in depth on methods to help Scrum team utilize metrics to increase their focus.  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 episode, Dan Neumann is excited to be joined by special guest, Felipe Castro! Felipe is an expert on OKRs or Objectives and Key Results. He is an OKR trainer, speaker, and author who helps organizations transform how they use goals by adopting OKR! He has even created his own OKR tool called the OKR Cycle which is a simple method to avoid OKR’s most common pitfalls.   As a master of all things OKR, Felipe Castro is here to speak about — you’ve got it — all things OKR! He goes over what OKRs are; important aspects you should consider; tips and advice regarding them; common mistakes, misunderstandings, and pitfalls; and how to overcome them.   Key Takeaways What are OKRs? Stands for Objectives and Key Results An Agile approach to setting goals and creating alignment OKRs are about the outcome you want to achieve A framework for defining and tracking objectives and their outcomes Focuses on outcome-based planning as opposed to tracking tasks and activities Instead of giving the teams a feature to build, you are giving them a problem to solve or an opportunity to tackle Important aspects of an OKR: The objective should be memorable, compelling, motivating, and inspiring The ‘why’ comes from leadership and the team figures out the ‘what’ together Asking ‘so what?’ can help your team create better key results Give your engineers autonomy to solve problems Psychological safety is crucial for fostering an environment for high-performance teams Felipe’s OKR tips and advice: Start with targets that are regular goals (hard, but achievable) Don’t copy another company’s method around OKR — adopting OKR is a journey that will be different for every company Adapt the principles of OKRs for your specific context You need to unlearn, adapt, and evolve — especially if you come from an Agile background Common OKR mistakes, misunderstandings, and pitfalls: Treating it as a glorified to-do list Using OKRs as a copy of Jira (which doesn’t add any value) Seeing the role of engineers as assisting only with the coding rather than problem-solving That the sweet spot for achieving a target is 70% (which has zero science behind it)   Mentioned in this Episode: Felipe Castro The Beginner’s Guide to OKR, by Felipe Castro SVPG (Silicon Valley Product Group) INSPIRED: How to Create Tech Products Customers Love, by Marty Cagan McKinsey’s Three Horizons Model Doc Norton “How Can You Test Business Ideas? Interview with David J. Bland,” by Felipe Castro Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs, by John Doerr   Felipe Castro’s Book Picks: Testing Business Ideas: A Field Guide for Rapid Experimentation, by David J. Bland and Alexander Osterwalder Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing, by Ron Kohavi, Diane Tang, and Ya Xu   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 questions: "What does an effective Daily Scrum look like?" Introduction Recently, I saw a great question on Twitter from Ebenezer Ikonne. I love following him because he often asks thought-provoking questions about agility in theory and agility in practice. His question that day was about practice of daily standups. He asked, "Is there anyone in my network who has experienced a standup done well? And possibly consistently? now I'm curious... is there anyone in my network who has experienced/participated/facilitated/observed...a standup done well? possibly consistently? if yes, would you mind describing what it looked like? — Eb (@eikonne) April 26, 2020   I thought that was a great question because the Daily Scrum in Scrum is so often a ritual devoid of meaning other than people standing around giving a status report to someone else, often the Scrum Master. I responded with a short thread describing an experience with one of my teams, years ago that was very positive and a very effective use of the Daily Scrum. I think that it's worth repeating here and elaborating on. The team in question had been practicing Scrum for quite some time pretty successfully. We were delivering on a regular basis. We were delivering fairly high-quality stuff. But our Daily Scrum fell into the typical rhythm: The Development Team members took turns answering the classic three questions and then it would be on to the next person, without really collaborating. Because what we were doing most of the time was merely mentioning task IDs from our electronic tool: "Yesterday I finished 1037. Today, I'm going to pick up 1052 and if I finish that I'll get started on 1053. No impediments." We were following the Scrum Guide, but only in a rote fashion. The Product Owner was attending our Daily Scrum one day because we’d asked him to be there to answer some questions about the scope of one of the PBIs. He said he was really confused at what he had just seen and asked if it was really helpful to us. We realized that it wasn’t, and that we needed to change. The next day, we started at the top of the Sprint Backlog and talked about the first unfinished Product Backlog Item. We talked about what was remaining. What did we still need to do to get this PBI completed? Could we do it today? Failing that, what could we do to advance its progress? When we finished talking about that item, we'd move on to the next, and the next one after that, and so on, until our fifteen-minute time box expired. As we continued this practice, the effect was dramatic. We came out of the Daily Scrum every day energized instead of bored and disaffected. We were collaborating, and it led to further collaboration throughout the day. Instead of people working on their individual tasks in silos, we were working together to deliver that integrated increment. We started finishing PBIs faster as a result. We also very quickly realized that it was pointless to have more than a few PBIs in progress at any given time. We only had time to discuss three or four of them each day in the Daily Scrum. Previously, we had enacted a work-in-progress limit based on the number of tasks per person. Instead, we started limiting the number of PBIs in progress. That increased our focus on collaboration. It increased our focus on completing PBIs together, not getting tasks done. The change of focus helped our throughput increase, and it increased our quality. We changed from a mechanical practice of the Daily Scrum "by-the-book" to one that honored the spirit of Scrum, which is true team collaboration. Although we weren't individually answering the "three questions," we were still answering them--as a team. Conclusion If your Daily Scrum is stale or you feel as though it isn't providing value, try changing it up. Ask yourself how you can structure the discussion around what the whole team needs to do today in order to get a little closer to the Sprint Goal. 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 episode, Dan Neumann is back with his co-host and colleague, Sam Falco! Today, they’re discussing whether or not a Scrum Master should be technical. Sam often finds himself being asked about this and has noticed many other people have a strong opinion for arguing either side of the coin. But, there’s more to it than just those two extremes!   So, in their discussion today, Sam and Dan will be walking listeners through the various possibilities beside technical or not technical, and providing their advice on how to find the perfect balance between the two!   Key Takeaways A technical Scrum Master: benefits, challenges, and advice: It can be beneficial to know the product and the knowledge domain your team is working in so that you can help the team when they have an impediment or are struggling with something Knowing the domain also makes it easier to help the Product Owner understand good backlog management, communicate to the development team, and encourage refinement to happen With technical knowledge, you can call out your team if they are sandbagging Challenges and pitfalls that can come with having a Scrum Master having a technical background is that there is a possibility that they might want to get in and do it themselves (which is not their role as a full-time Scrum Master) which can damage a team’s ability to self-organize and ability to innovate As a Scrum Master, if someone on the team approaches you and asks how to solve it, your response shouldn’t be to directly solve it, but to instead ask: “What are you going to try?” A Scrum Master who has no technical knowledge: benefits, challenges, and advice: They can be helpful in removing impediments because they have some knowledge about how things work (which may help them with knowing who to go to when there’s a problem in a particular area) The danger in not having any technical knowledge (but having domain knowledge) is that they may step on the Product Owners toes A non-technical Scrum Master could be challenging the team where they shouldn’t be Another concern is if the Scrum Master only knows Scrum and they’re only concerned with the team getting value out of Scrum Sam’s Scrum Master tips: A valuable skill for a Scrum Master is knowing when the team is confused or misunderstanding things and pausing to check and make sure that everyone is in the same place You have to be good at what you do and you have to be doing it to serve the team; not making sure everyone does everything by the book (without understanding why) As a Scrum Master, you should be asking yourself: “What are we doing here?”, “Why are we doing this?”, “How can I help my team?”, and “How can I serve best?” Take some time to reflect on: “Is the Scrum framework is being applied well?”, “Is the team delivering value incrementally?”, and, “Are the Scrum values present?” In Conclusion, should a Scrum Master be technical or not? The question itself is a bad premise because it implies either ‘yes’ or ‘no’ The answer is ‘yes’ and ‘no;’ it depends If you’re a Scrum Master that feels that your lack of technical knowledge is inhibiting your ability to serve your team, then it is okay to take some basic classes to understand the challenges your development team is facing If you’re a Scrum Master who is very technical, take some time to reflect on where your service is best applied and ask if yourself if you’re relying too hard on your technical knowledge   Mentioned in this Episode: “The Expert (Short Comedy Sketch)” (Seven Redlines Video) Agile Coaches’ Corner Trainer Talk Episode: “The Risks of Having Scrum Masters as Schedulers” The Professional Product Owner: Leveraging Scrum as a Competitive Advantage, by Don McGreal and Ralph Jocham   Sam Falco’s Book Pick: The Janes: An Alice Vega Novel, by Louisa Luna   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!