Agile Coaches' Corner

In this episode, Professional Scrum Trainer Eric Landes addresses the questions: "Why doesn't Scrum care about good software development?" Introduction In my Professional Scrum Foundation classes, sometimes I'm asked, "Why doesn't Scrum care about good software development?" Kind of a funny question, right? Scrum was founded for software development teams and we don't really see that in the Scrum guide. So, for instance, if I look at the Scrum guide and search for terms like tester and development or continuous integration, we don't really see that in the Scrum guide. Scrum Does Care About Good Software My answer to this question to the students typically is Scrum does care about software development and one of the first classes from Scrum.org was for the Professional Scrum Developer course and Ken Schwaber created that, he's a software developer at heart and in his background. So very passionate about good practices there. And this course teaches Scrum along with good software engineering practices. Things like test driven development, continuous integration, those kinds of things where the foundation of the course and as with all courses you create an increment of software over the course of multiple Sprints. You create multiple increments of course. So, I'm a Professional Scrum Developer Trainer, love the course. And one of the things I do love about it is we keep incorporating fresh trends, trends like DevOps for instance, infrastructure is code, telemetry and monitoring. Those are all things that are incorporated now into that course. So Scrum.org is always modifying, inspecting and adapting as good Scrum should do on their courses. Build the Right Team The idea that Scrum doesn't care about good engineering practices though is not actually correct, but the Scrum Framework encourages development teams to have all the skills necessary to create that increment, that complete increment. So, for instance, if your team doesn't have the ability to do infrastructure as code, they don't have the right person so that you can get all the way to production, you need to get somebody on your team to do. Also, self-organization means we as a team have to decide which practices we're going to utilize. Scrum may not say specifically you need to use these technical practices and it's not prescribing them. But Scrum gives you some good basis from your Professional Scrum Developer course on what practices are good and go well with Scrum. Self Organize Scrum assumes that you as a self-organizing team are going to come up with those good engineering practices to create that finished increment that delivers what the customer wants and you're going to continue to keep up on good trends and what the software needs for your customer. So, in the end, Scrum does care about good software engineering practices, it's just not prescriptive about it. And if you're interested at all in the Professional Scrum Developer course, keep in mind it's been made for all different kinds of languages. Java, C sharp, JavaScript, React, those kinds of things can be modified and used with that course. 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, Professional Scrum Trainer Sam Falco answers the questions: When should we hold our Daily Scrum? Introduction A student asked me, "When should we hold our Daily Scrum? Does it have to be in the morning?" The Scrum Guide tells us that "The Daily Scrum is held at the same time and place each day to reduce complexity," but it doesn't give any guidance on when. That means it is up to the Development Team to decide the best time for them. Here are some thoughts about the pros and cons of various times: Early Morning Daily Scrum First thing in the morning often works well, because we're starting fresh. Planning for the day together helps us get our heads back into the work. A challenge some teams have is that if it's too close to the start of the workday, commuter disruptions (traffic delays, kids need to be dropped off, and so on) can make it difficult for everyone to arrive on time. Also, sometimes it's hard to remember what happened yesterday. Mid-Morning Daily Scrum Mid-morning gives everyone time to get into the office, but if you wait too long, some people have already started working, and Daily Scrum can feel like a disruption. Lunchtime Daily Scrum One team I worked with held Daily Scrum right before lunch time. Everyone was in the office, and everyone was taking a natural break, so they didn't feel disrupted. However, they sometimes felt rushed when they had team lunches scheduled--everyone wanted to get moving before restaurants became crowded. End of Day Daily Scrum Near the end of the day means that what everyone did today is still fresh in mind, which can make planning tomorrow's work easier. But sometimes it means that there's too much focus on what we've done, and not enough on what we should do tomorrow. Scaled Agile Daily Scrum  In a scaled environment, with multiple teams, it's probably a good idea to have all the teams' individual Daily Scrums around the same time, so that cross-team issues that emerge can be resolved more quickly. Want to Learn More or Get in Touch? Register for our upcoming AgileThought Virtual Community events: Resolving Agile Anti-Patterns in Remote Work See available training courses at agilethought.com/training. Visit the website and catch up with all the episodes at AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

This week, Dan Neumann is joined by his colleague and return guest, 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 this episode, they’re going to be discussing portfolio management. A lot of times, Agility is thought of as team practices or activities that go around the team. And yet, there’s a lot of disruption and a lack of clarity that can happen when the higher-level contacts around those teams aren’t set. And a lot of times, that vision and strategy are being set at the portfolio level. So in Dan’s and Quincy’s discussion today, they shed some light on Lean and Agile portfolios in particular, as well as how portfolios fit into Agile ways of working and how it could help. They also provide actionable advice around how to keep the communication clear and transparent, key takeaways around the sustainability of the portfolio, and how to add Agile or Lean components to portfolio management.   Key Takeaways How to add Agile or Lean components to portfolio management: Make sure that alignment is there (when you don’t have alignment from the portfolio level you run into a lot of challenges around teams not being clear about why they’re doing the work that they’re doing and the overall vision) Capture the vision through a framework (like OKRs) to add clarity Make sure that alignment is created and that there is a concise and clear vision that everyone can execute on Ensure that the team knows where the organization is going (so that they know what that the goals are beyond just delivering on a project) Good alignment from the top-down is critical You don’t want to spend time on products that are not going to bring value, so the portfolio of products needs to be constantly reprioritized and reevaluated Make sure that the team is not putting emphasis or focus on products that are not bringing value to the portfolio of products Ways to keep communication clear and transparent: Once alignment is established and everyone understands what the vision is, you then have to make sure that everything/everyone is very transparent about them Establish good, clear, and frequent communication Potential downfalls with portfolio management and agile transformations: forgetting to communicate on a frequent basis with those on the ground who are helping to bring this vision to pass (when people aren’t clear on the ‘why’ they don’t have as much of an invested interest in the outcome) Make sure communication is flowing both ways Value mapping can be a valuable method for making the value creation visible, which improves communication and understanding Within a portfolio of products, you can utilize Kanban boards which will show all of the products within that portfolio that are in flight and all of the teams that are supporting those products (they’re also highly visible to all the teams and it’s a nice transparent way for people to see how their team fits into the bigger picture) Key takeaways around the sustainability of the portfolio: Within the portfolio, you want to make sure that you’re looking at the cross-team dependencies and using an appropriate model that will allow the management of the portfolio to be sustainable To make things sustainable, you need to look at what the post-transformation sustainability and the overall sustainability model looks like Conduct change in a series of ‘push and let go’ Have a portfolio combined of different horizons (reference the ‘Three Horizons Method’) You don’t want to spend so much time keeping the lights on that you end up being a ‘blockbuster video’ (i.e. remember to look ahead at Horizons 1 and 2 as referenced in the ‘Three Horizons Method’)   Mentioned in this Episode: Quincy Jordan OKRs “How to Avoid OKR Fake News — Felipe Castro at the OKR Forum Amsterdam 2019” Video Value Mapping McKinsey’s Three Horizons Model   Quincy Jordan’s Book Pick: Unlearn: Let Go of Past Success to Achieve Extraordinary Results, by 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!

In this episode, Professional Scrum Trainer Sam Falco answers the questions: Are there any types of work which aren’t suitable for Scrum? Scrum is for Complex Work Scrum lives in the area of complexity, where more is unknown than is known--about requirements, about how to fulfill them--and we have to apply an empirical approach in order to discover what we need to know and how to solve the problem. Scrum is Unnecessary for Simple Work Scrum would be unsuited to very simple work domains, where cause and effect are obvious to everyone, and all needed information can be known. This is the realm of "best practices," meaning there is one way to solve the problem; it is known to everyone involved, and following the known process will provide the expected result. As a concrete example, think of an oil change. In simple work, Scrum is unnecessary. Scrum is Overkill for Complicated Work For more complicated work that is not complex, more is known than unknown about the problem to be solved. This is the realm of "good practices." The problem is not as precise or easily defined as in simple work, and there are likely a few different ways to solve it. The example I always use is when I had to have a new roof put on my house. Everyone agreed on the requirements: Make my roof water-tight! But there are multiple types of roofing technologies, and my house's roof has a peculiar design. Those complications required analysis before we could decide on the appropriate approach. But my roofers could still use a predictive, plan-driven approach. For complicated problems, an empirical approach like Scrum could work, but it is likely to be overkill. Scrum is not Suitable when we Know Nothing Finally, Scrum is not likely to be suitable for a chaotic environment, when almost nothing is known about the problem to be solved or how to solve it. The classic example is a natural disaster, but I've also worked in an environment where no one could agree on what was wanted, and any plan we made could be invalidated at a moments' notice. Provide Feedback Let us know what you thought about this supplemental episode of the Agile Coaches’ Corner. If you’re interested in training, visit agilethought.com/training or call us at 877.514.9180 to learn more. And if you have a question you want us to answer on the next Trainer Talk episode, email us at podcast@agilethought.com. Want to Learn More or Get in Touch? Register for our upcoming AgileThought Virtual Community events:  Kanban for Work and Home" 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 David Horowitz, the co-founder and CEO of Retrium! Retrium is an incredible tool that’s all about helping teams have engaging retrospectives that fuel continuous improvement. It enables Agile teams to have more effective conversations, discover new insights, and generate action plans by providing a toolbox of activities, a guided facilitation process, and a space to organize your retrospective documentation in one place.   And speaking of retrospectives, today’s episode is going to be a retrospective deep-dive! Dan and David will be addressing some of the common misunderstandings and misconceptions around retrospectives, why you should hold retrospectives in the first place, some of the common anti-patterns with retrospectives (and how to combat them), and most importantly, how to have much more effective, engaging retrospectives!   Key Takeaways What is the goal of a retrospective? To achieve actionable team learning It’s not just about improving productivity; it’s about getting the team to learn something and try something new (that, in turn, may lead to improvement) They’re not limited to Scrum or Agile (or really any team working together on anything using any process) Anti-patterns of retrospectives: Retrospective disillusionment (where someone has the sense that retrospectives are a waste of time and don’t want to show up to them) Lack of follow-through (if every retrospective led to actionable team learning that eventually led to productivity gains, people would show up and be engaged) Not being cautious of who you invite to the retrospective because if you can’t get the right people in the room, how are you going to retrospect effectively? (It is crucial to think through who you invite based on the circumstances that you’re facing) How to improve your retrospectives: Make sure who you invite is an opt-in that the whole team, through consensus, agrees on bringing in (if you don’t, you’re throwing psychological safety out the window) You can have multiple retrospectives and it doesn’t have to be at the end of the sprint — do what’s best for your team in any given situation Some people may speak too much at the exclusion of others — you can use various ways to level the playing field (one way is to ask everyone to write down their ideas on sticky notes or through ‘dot voting’) Some people feel more comfortable talking 1:1 so you could use something akin to ‘1-2-4-All’ before talking in a group Generally varying the way the conversation takes place is a good way of ensuring everyone has a chance to speak up Having a solid background in meeting facilitation is incredibly beneficial to the success of your retrospective Using open-ended questions (such as, “Does anyone have anything else to say about this?” and counting to ten) can be very helpful for giving everyone a chance to speak The Scrum Master does not have to facilitate the sprint retrospective If you’re facing low-engagement in your retrospectives you can increase empathy by opening up the meeting to others who might want to experience how difficult facilitation really is (it also gives you the chance to experience participating) It can be good practice to reach outside of the scrum team for someone who is a neutral party Ten surface-level conversations are not as effective as having a single deep-level conversation on a single impediment Narrow the scope down to the most minimal amount of impediments possible until you’ve proven that you can do more There are some great facilitation techniques to find the root cause analysis such as the ‘5 Whys’ and ‘Fishbone’ Create space for diverging before converging on a potential solution Rank your action items to get a list of prioritization of which one your team should try/focus on first (you can use the ICE Framework for this) Follow the energy of the team to understand what the team wants to focus on (if no one wants to work on it, it won’t happen) Uplevel the impediments your team is experiencing that it can’t solve Have information radiators in place Ask your team: ‘What, out of everything we just discussed, should we talk about intentionally, frequently, with everybody in the organization, as often as we possibly can?’   Mentioned in this Episode: David HorowitzDavid’s Twitter: @DS_Horowitz David’s Email: David@Retrium.com Retrium Agile Retrospectives: Making Good Teams Great, by Diana Larsen and Esther Derby The Retrospectives Academy by Retrium Project Retrospectives: A Handbook for Team Reviews, by Norman L. Kerth Dot Voting 1-2-4-All Liberating StructuresRoot Cause Analysis The 5 Whys Fishbone ICE Prioritization Framework Badass: Making Users Awesome, by Kathy Sierra   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 of the Trainer Talk supplemental series to the Agile Coaches' Corner Podcast, Professional Scrum Trainer Sam Falco answers the questions: Do Sprint Reviews and Sprint Retrospectives Overlap? Why do we talk about what went well in a Sprint Review? In a Professional Scrum Foundations class I taught recently, one of my students asked if there was an overlap between the Sprint Review and the Sprint Retrospective. She was reacting specifically to the statement from the Scrum Guide that in Sprint Planning, “The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved.” Doesn’t that discussion properly belong to the Sprint Retrospective? It’s easy to see how someone could be confused by that statement in the Scrum Guide. After all, a common format for Retrospectives is “What went well, what could have gone better, and what could we do differently?” The Intent of a Retrospective The difference is in the intent. In the Sprint Retrospective, the Development Team is focused on how it can improve its work. Whether that has to do with the way we work together, the tools we use, improving our Definition of Done, or some process we’re using, the goal of the Retrospective is to produce improvements it can introduce into the next Sprint. The Intent of a Sprint Review By contrast, the focus of Sprint Review is to collaborate on the most valuable thing we can do next with regard to the product. When the Development Team talks about what went well and what problems it ran into in this context, it is valuable feedback to the Product Owner and stakeholders about the nature of their work—facts that ought to be taken into account when creating and ordering Product Backlog items. Provide Feedback Let us know what you thought about this supplemental episode of the Agile Coaches’ Corner. If you’re interested in training, visit agilethought.com/training or call us at 877.514.9180 to learn more. And if you have a question you want us to answer on the next Trainer Talk episode, email us at podcast@agilethought.com. Want to Learn More or Get in Touch? Register for our upcoming AgileThought Virtual Community events: "Working Agreements Workshop" and Kanban for Work and Home" 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!

George Dinwiddie discusses software estimation best practices, misconceptions, and the importance of accurate estimations. He emphasizes the need for clear communication, tracking progress, and adaptive estimating for effective project management. The podcast addresses the differences between estimates and plans, the dangers of false task completion, and the role of human dynamics in collaboration. It also delves into learning organizations and systems thinking for addressing organizational challenges.

In this episode of the Trainer Talk supplemental series to the Agile Coaches' Corner Podcast, Professional Scrum Trainer Sam Falco answers the questions: Is there anything wrong with the Scrum Master scheduling and running all the Scrum events? Today’s question came up in a discussion about the perception that a Scrum Master’s responsibility includes scheduling all the Scrum events and running them all. Is there anything wrong with that being the Scrum Master’s responsibility? After all, the Scrum Guide says that one of the Scrum Masters’ services to the Product Owner and to the Development team includes “Facilitating Scrum Events as requested or needed.” Danger 1: Scrum Master as Admin Assistant While that’s true, I think there are hidden dangers in assuming that “as requested or needed” means “always.” The first danger is that it risks turning the Scrum Master into an administrative assistant to the team. Remember that a Scrum Master is also supposed to provide other services to the Scrum Team and to the organization at large. When a Scrum Master’s primary responsibility is to schedule meetings and run them, it necessarily means that the Scrum Master has to limit other activities that may provide higher value. Danger 2: Teams Will Not Self-Organize The second danger, and the more significant one, is that it may impair the team’s ability to self-organize. This is especially true in the case of the Daily Scrum. The Daily Scrum is a tool for the Development Team to self-organize around solving problems, and the Development Team is explicitly given responsibility for conducting the Daily Scrum. When this responsibility is shifted onto the Scrum Master’s shoulders, the Daily Scrum often transforms from a collaboration session into a round-robin status report of Development Team members to the Scrum Master. For the other events, it is valuable for everyone on the Scrum Team to develop the skills necessary to facilitate the Sprint Planning, Sprint Review, and Sprint Retrospective events. Conclusion There’s nothing wrong with a Scrum Master facilitating events “as requested or needed,” but if the Scrum Master is always needed and is always requested, it’s a sign that the Scrum Team needs to work on its self-organization. Let us know what you thought about this supplemental episode of the Agile Coaches’ Corner. If you’re interested in training, visit agilethought.com/training or call us at 877.514.9180 to learn more. And if you have a question you want us to answer on the next Trainer Talk episode, email us at podcast@agilethought.com. Want to Learn More or Get in Touch? Register for our upcoming web meeting "Staying Focused in a Remote Work World." 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 Dan Neumann today is Andrea Floyd, an Enterprise Agile Transformation Consultant within AgileThought! Andrea has 25 years of experience in software development and project management. She’s been an innovator that has a ton of experience leading multiple organization-wide Scaled Agile implementations as well as architecting innovative solutions, strategies, and roadmaps across many frameworks (including Scrum, Kanban, and Scaled Agile Framework).   Today, Dan and Andrea will be taking a look at some of the reasons why Agile transformations don’t stick! Sometimes transformations get announced with fanfare… but then die off with whimpers. Tune in so that you can reduce the chance of failure and give your teams the best chance of success!   Key Takeaways Top reasons why Agile transformations don’t stick: If the organization doesn’t understand why they’re doing a transformation and how it is going to impact them on an individual level there will be resistance (which will erode the intention behind the transformation) There is a lack of identifying a team of champions throughout the organization The train goes off the track; i.e. the ‘rubber-band theory:’ if you don’t continually reinforce positive behaviors and have a deep understanding of the ‘why’ behind the changes being made, it often becomes a series of checking off the boxes, which leads to a breakdown If someone is not looking for anti-patterns and helping to coach others about the transformation, individuals will go back to their old ways If you don’t put the right investment in your transformation or the change that you’re trying to create, you’re not going to see the results that you’re looking for How to ensure that your Agile transformations stick: You need to have an awareness of why you’re doing a transformation and it needs to be shared enterprise-wide The transformation should be done holistically and in small pockets where you can actually start to demonstrate the value of the transformation You need a perfect marriage between having enterprise-wide support and individuals who are fully on board The message of how the transformation is going to impact individuals in a positive way needs to be reinforced often You want to make sure there is transparency Make what the transformation is trying to achieve and the progress that is being made towards that visible and known Foster a community of believers who turn into supporters Identifying a team of champions throughout the organization, which helps set up the transformation for sustainability (five is usually a good number) Having someone to monitor or provide ongoing awareness around the transformation (i.e. a trusted advisor who can provide support to individuals who are wary about the changes) It’s important for the organization to also take responsibility for moving things forward Show the value and improvement of the transformation sooner rather than later Get people excited about the changes by showing other teams’ success Create a sustainable environment with sustainable practices and people that can actually continue after you leave   Mentioned in this Episode: Andrea Floyd Real-World Kanban: Do Less, Accomplish More with Lean Thinking, by Mattias Skarin Training from the Back of the Room!, by Sharon L. Bowman   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 of the Trainer Talk supplemental series to the Agile Coaches' Corner Podcast, Professional Scrum Trainer Sam Falco answers the questions: How do you that in the first Sprint? Don’t you have to build out all your infrastructure first?” Prove Your Infrastructure Works One common question I hear from students in my Professional Scrum Master classes is, “How do you deliver business functionality every Sprint, including the first one? Don’t you have to build out all your infrastructure first?” It’s true that on a new software development initiative, there’s a lot of architectural and infrastructure work to be done at the beginning. But infrastructure alone doesn’t give stakeholders the information they need to decide whether to continue funding the project. You need to deliver some kind of business functionality to prove that the infrastructure you’ve built actually works. Stakeholders need to know that work they care about is happening. Deliver Business Functionality What might that look like? There’s a great example in Ken Schwaber’s book Software in 30 Days. He describes a project to build a mobile banking app. In the first sprint, the development team did a lot of work on architecture and infrastructure, but they also provided a way to connect to a web portal, designed a basic front end, and created a landing page where customers would ultimately be able to log in. They didn’t even build the capability to log in—all you could do was hit the front page. Obviously, you wouldn’t want to release that as a product, but it still provides some small slice of business value. It provides something for stakeholders to evaluate and collaborate on with the Scrum Team. What’s the response time? Does the design look good? What might customers want to see once they log in? Was it worth continuing this project? They decided that it was. And if they hadn’t, the team wouldn’t have wasted time building out a platform that was never going to be used. Let us know what you thought about this supplemental episode of the Agile Coaches’ Corner. If you’re interested in training, visit agilethought.com/training or call us at 877.514.9180 to learn more. And if you have a question you want us to answer on the next Trainer Talk episode, email us at podcast@agilethought.com. Want to Learn More or Get in Touch? Register for our upcoming web meeting "Virtual Lean Coffee | How To Thrive In A New Virtual World" 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!