Agile Coaches' Corner

This episode marks the first anniversary of the start of the Agile Coaches’ Corner podcast! In celebration of this special mark, Dan Neumann and his collaborator, Sam Falco, are taking a look back at the very first episode: “Do Scrum Well Before Scaling!” They’ll be revisiting the topic — but from a slightly different angle this time: “What anti-patterns interfere with or prevent good scaling?”   Tune in to hear Dan’s and Sam’s anti-patterns around scaling in Scrum and some of their solutions on how to address them or stop them before they start!   Key Takeaways Anti-patterns that interfere with or prevent good scaling: Not having a sprint goal; not having one clear goal for the sprint that is understood by everybody (which ends up creating a laundry list of items that are not tied together which can create unrealistic expectations about delivery) Having two sprint goals (which causes a lack of focus) — “If you aim at two goals you won’t hit either of them!” That everything doesn’t have to be integrated or can be integrated after a few sprints (this can be a side effect of not having a clear sprint goal), which creates risk build-up If everything is not integrated, technical debt will bring things to a grinding halt and create a mountain of undone work A lack of automated testing and thinking you can build out the unit tests and automated functional tests later — because later might never happen or, by the time you get to it, the effort becomes far too large Team dysfunctions and anti-patterns that affect scaling: Not making the impediments visible — if you make the impediments and dependencies visible and communicate in-person this can be resolved fast! A common dysfunction in beginning Scrum teams is this concept that individuals own the product backlog items which leads to siloed work (which, in turn, can lead to not getting things done because the team takes on more than it can handle and cannot coordinate properly) Assigning stories to individual developers (when it is actually much more effective to leave the PBI unassigned or assigned to the Product Owner) Multiple Product Owners for an individual Scrum team (you only want one — but if there are multiple ones in a scaled environment they should be aligned!)   Mentioned in this Episode: The Scrum Guide Agile Coaches’ Corner Ep. 1: “Do Scrum Well Before Scaling!” Agile Coaches’ Corner Ep. 51: “Getting to ‘Done’ Within a Sprint” Agile Coaches’ Corner Ep. 43: “The Importance of the Product Owner Role in Scrum with Sam Falco” Scrum@Scale   Sam Falco’s Book Pick: Mastering Professional Scrum: A Practitioners Guide to Overcoming Challenges and Maximizing the Benefits of Agility, by Stephanie Ockerman and Simon Reindl   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 Neumann will be focusing on the topic of getting to ‘done’ within a sprint. Getting an increment to ‘done’ is really challenging — even for Scrum teams that have been working for a while. So it is especially challenging for folks that are new to Scrum and sprinting all together. Even at the longest duration of a sprint (which is one month), it can fly by incredibly fast! So if you’re used to really long delivery cycles with long requirements, think about how fast a two-week sprint will go!   So how might we get to a done increment? Tune in to find out!   Key Takeaways What does it mean to get ‘done’ in a sprint? In the Scrum Guide, it says that the increment must be done and in usable condition The team ultimately decides what ‘done’ is (but it does need to be in usable condition) What do we not want to do to get to ‘done?’ What methods — though, often posed — simply do not work? Nailing the requirements up-front so they’re moving because it’s easier to hit a static target than a moving one Building within the sprint and then testing within the next sprint (which is a non-option because within each increment it should be in a usable condition) Build for seven days, do a code freeze, and then test for three (which is ineffective because you end up with questions such as: ‘What did the developers do for the last third of the sprint?’ And, ‘What do the quality specialists do for the first two-thirds of the sprint?’ etc.) Implementing “Wagile” (Waterfall-Agile), where you nail the requirements and then iterate through the delivery of the requirements through the sprint Extending the sprint because the work isn’t done (this is the best time to stop and have a retrospective) Dan’s recommendations for new teams looking to get ‘done’ every increment: As a Scrum team, collaborate to break your product backlog items down into smaller pieces (small batches are going to move through the sprint faster, and a smaller product backlog item will get delivered more quickly than a large product backlog item [it’s far more valuable to have 9 things at 100% and 1 at 0% than to have 10 backlog items at 90%]) Make sure that everyone on the team is really focused on quality Really maximize the amount of work not done; ruthlessly focus on meeting the acceptance criteria for your product backlog items and no more than that Pull your testing forward An activity that can be super valuable for Scrum teams is to have a subset of the team (representing quality, development, and the product owner) to get together and define what the test cases are that are ultimately going to have to pass Look for tools to support the people and interactions — tools can really help your Scrum team move forward rapidly (tools that can automate the unit tests that need to execute are especially beneficial) Encourage more self-organization and look for ways to increase more collective code ownership within your team (activities like paired programming and mobbing can help with this) Dan wants to hear from you! What ideas have you tried and seen work for getting code to ‘done’ within a sprint? What have been some things you’ve tried and haven’t worked? Would you be willing to start taking more notes throughout your day and then give yourself some time to reflect on those and identify your own areas of growth? And, if you do, what did you find out?   Mentioned in this Episode: The Scrum Guide “Wagile” (Waterfall-Agile) Pair Programming Mob Programming Agile Coaches’ Corner Ep. 45: “The Benefits of Mob Programming with Chris Lucian”   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!

We, as humans, are really intolerant of uncertainty to a large degree. We actually are inherently set up to dislike uncertainty in most situations.   So how do uncertainty and our ability to be able to deal with it have anything to do with agility and my everyday work team? Well, Dan thinks it has everything to do with it! Uncertainty and our ability to cope with change affect how teams function, how people respond, and even how the team plans projects in the first place.   In this episode, Dan jumps right into what uncertainty is (and why we, as humans, are rather intolerant of it), how we can better cope with uncertainty, how it relates to agility, and how agility can be used to address uncertainty!   Key Takeaways How do we respond to uncertainty? As the uncertainty of an outcome approaches the 50% mark (i.e. there’s a 50% chance that an outcome could be either negative or positive), that is when our stress response is highest If we already know the outcome (be it positive or negative), there will not be much of a stress response either way — it is with the uncertainty that it is the highest The five coping techniques as outlined in “5 Ways to Manage Your Fear of Uncertainty”: 1. Commit to gradually facing uncertainty 2. Connect to a bigger purpose 3. Don’t underestimate your coping ability 4. Bolster resilience by increasing self-care 5. Appreciate that absolute certainty is impossible How to address uncertainty with agility: Shifting away from plan-driven software into a more agile approach can bring the fear that there is a lot more uncertainty in delivering the software — however, agility actually helps us face uncertainty by slicing capabilities and through establishing feedback loops On the technical side of agility, uncertainty is also addressed through automated unit testing and test-driven development Frequent code check-ins are also valuable in addressing uncertainty In terms of connecting to a bigger purpose to address uncertainty, think of the scrum product owner as a chief storyteller (their job is to articulate the purpose and help those on the team connect their contributions on a daily basis to the greater vision of the product overall) ‘Don’t underestimate your coping ability’ when applied to agility can be thought about as the ability to deal with things when they don’t go well When people underestimate their ability to deal with software that may need changes down the line, they’ll overbuild software — so it’s important to remember: YAGNI (You ain’t gonna need it!) Most importantly, remember: “You don’t want to sacrifice the good enough for the perfect” — you can always change the code down the line, it is not detrimental Bolster resilience by increasing self-care by sleeping well, taking a nap at work (if you can), and taking a break when you’re feeling stressed You can also bolster resiliency by growing your technical chops (through coding katas), looking for opportunities to engage with the broader community (through code camps or meetups focused around your particular domain), and looking for opportunities to play at events like Global Game Jam (because social connections often bring you new opportunities and new ideas you can leverage on your teams as well) It is important to remember that absolute certainty is impossible; there is no way of knowing our code will meet the needs of a user forever — in fact, it’s quite impossible to have the perfect solution that will work forever (so roll with the changes as they come in and simply embrace it!)   Mentioned in this Episode: “5 Ways to Manage Your Fear of Uncertainty,” by Jelena Kecmanovic (Fast Company) “Computations of Uncertainty Mediate Acuate Stress Responses in Humans,” by Archy O. de Berker, et al. (Nature Communications) Agile Coaches’ Corner Ep. 49: “Concepts Around Agile: Common Misunderstandings and How to Correctly Apply the Agile Manifesto Principles” Coding Katas “YAGNI — You Ain’t Gonna Need It” (DevIQ) “School’s Out,” by Alice Cooper Global Game Jam Lego Serious Play   Dan Neumann’s Book Pick: Lego4Scrum, by Alexey Krivitsky   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

Today on the podcast, your host, Dan Neumann, is going to be exploring concepts around Agile. This is a very important topic as a lot of times we go into an organization and find that there’s a lack of clarity or a lack of common understanding about what agility really is. Often, it’s the agile itself that is confused with a popular framework on the market, or, it is seen to be implementing a different methodology than what they already have.   In this episode, Dan will be exploring a couple of these misunderstandings around implementing agility, what exactly defines agile, and some of the principles behind the Agile Manifesto and how to correctly engage with them Download the Manifesto for agile software development and principles  Key Takeaways What defines Agile: As the Agile Manifesto states: “We’re uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value: “Individuals and interactions over processes and tools “Working software over comprehensive documentation “Customer collaboration over contract negotiation “Responding to change over following a plan “...While there is value in the items on the right, we value items on the left more” I.e. while there is value in processes, tools, documentation, contracts, and plans, the Agile Manifesto simply places more value on individuals and interactions, working software, customers collaboration, and responding to change These agile values have allowed the agile approach to be more successful and a better way of delivering software than many alternatives Agility is not binary; it’s not that you are agile or you are not agile — think of it more like a spectrum Common protests and misunderstandings about Agile: Sometimes the phrase, ‘it’s not agile,” is thrown around like a weapon — but in the manifesto itself there is nothing about how the plan is to be displayed; it’s up to the people doing the work to determine how much documentation is appropriate Some argue that agile is simply hip and trendy for websites or that it only makes sense for delivery of a certain type of system, yet, amongst the names of the signatories on the Agile Manifesto there are people that do a variety of work (from extreme programming to Scrum to embedded software to financial systems) A common protest is: “We can’t be agile because we do _______,” but regardless of the type of work you do, you can still place value in the items on the left over the right You don’t have to be doing Scrum or paired programming to be agile Three of the twelve principles behind the Agile Manifesto and how to correctly engage with them: The second principle: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” How to engage with it: In some organizations, change occurs simply because their opinions change — but it’s key to really ‘welcome change’ when there is a substantial positive benefit from making it The sixth principle: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” How to engage with it: though you can email and use messaging out of convenience, it is really important to engage in face-to-face conversation whenever you can (especially when communication seems to be going off the rails) The tenth principle: “Simplicity — the art of maximizing the amount of work not done — is essential.” What this principle means: Software development tends to be laser-focused on getting the requirements from the customer and doing all of the things that the customer needs… but the team tends to take an architecture mindset forward and overbuild (all these extra complexities create a lot more code to maintain and defers risk); AKA ‘gold-plating’ How to engage with it: If you want to pursue more agility, one way to do that is to start looking with a critical eye at what’s being asked for and take a look at how you’re implementing it and really try to figure out where there are opportunities to not do something or not do something yet Remember: Delivering working software for your customer is the highest priority rather than serving the architecture   Mentioned in this Episode: The Agile Manifesto Principles behind the Agile Manifesto Slack Microsoft Teams Azure DevOps Trello Boards Gold Plating   Dan Neumann’s Book Pick: The Truth About Animals: Stoned Sloths, Lovelorn Hippos, and Other Tales from the Wild Side of Wildlife, by Lucy Cooke   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 his collaborator, Sam Falco! Together they’re going to be tackling three Scrum-related questions that they dug up on Quora.   Sam finds himself running into these particular questions fairly frequently. In fact, every new client seems to have a set of similar questions! So if you’ve ever pondered, “What is better: one-week or two-week sprints,” “What is the scrum master’s role,” “What are the tasks that a scrum master has to perform,” or “What are the first things a scrum master should do when starting at a new organization?”... tune in!   And if you have any questions you’d like to hear answered in a future episode, you can email them to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!   Key Takeaways “Do you prefer one-week or two-week sprints? And why?” The Scrum guide says up to a month Sam doesn’t have a preference between one-week or two-week sprints as it depends on what the situation (and organization) calls for The key is to balance how much time it will take for the development team to do the work with the risk the organization is willing to absorb by not releasing (i.e. if an organization can wait three weeks without messing with the scrum team’s sprint goal — then three weeks is a good length) Sam recommends that teams brainstorm their definition of ‘done’ Either way, it’s important for the organization and team to maintain focus for the sprint duration, no matter the length A short sprint means there’s less to plan, less to review, less retrospective, and it scales more linearly All-in-all: it really depends! “What is a scrum master role? And what are the tasks that a scrum master has to perform?” Scrum masters are responsible for coaching the product owner, the development, and the organization Through transparency, inspection, and adaptation they should be working to improve the system over time They should be always be asking: ‘What value are we getting out of this activity?’ They have to remove impediments for the scrum team (once it is clear that the team cannot clear them) They must coach and protect the team They should help those outside of the team to understand how to interact with the team They need to coach the team and the organization how to work in Scrum They need to work with the organization on how to spread Scrum (as well as agile values and principles) The scrum master has to do whatever is necessary to help the team be successful “What are the first things a scrum master should do when starting at a new organization?” When you’re coming into a new organization as a scrum master, you should give the team that you’re going to work with a reason to trust you (Sam recommends creating a “mind map” of yourself and modeling some vulnerability) Have a group AMA as well as one-on-ones with each member of the team to build trust Ask the team what their challenges are, listen to them, and address those first Build a report with the dev team and the product owner You should be networking within the organization and learn who’s who If it’s a completely new organization, you want to establish good Scrum practice from the get-go, explain the ‘why’ behind the Scrum Guide, and make sure that the team is engaging in good Scrum practice   Mentioned in this Episode: Quora Mind map Agile Coaches’ Corner Ep. 1: “Do Scrum Well Before Scaling!” Deep Work: Rules for Focused Success in a Distracted World, by Cal Newport Agile 2019 Conference Quiet: The Power of Introverts in a World That Can't Stop Talking, by Susan Cain Quora Questions: “Do you prefer one-week or two-week sprints and why?” Asked by Sara Morsi “What is a scrum master role? What are the tasks that a scrum master has to perform?” Asked by Rashmi Pathak “What are the first things a scrum master should do when starting at a new organization?” Asked by Alex Dolphin   Sam Falco’s Book Picks: Arcade Perfect: How Pac-Man, Mortal Kombat, and Other Coin-Op Classics Invaded the Living Room, by David L. Craddock (Author) and Milan Jaram (Illustrator) Digital Minimalism: Choosing a Focused Life in a Noisy World, by Cal Newport   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

Joining Dan Naumann today is AgileThought colleague and return guest, Sam Falco! Sam is an Agile Coach and Certified Scrum Professional with an extensive background leading Agile development teams.   Today they’re discussing under-promising and over-delivering: the what-not-to-dos for Scrum teams, their leaders, and the business they work for. Every now and then when Sam is teaching Scrum or coaching people on sprint planning he’ll say, “Select what you think you can do.” However, a lot of beginning Scrum teams will bite off more than they can chew because they’re way too optimistic. He often cautions to dial it back and then will hear the phrase in return, “Oh, we get it! Under-promise and over-deliver.” But that is as much of a lie as, “Sure, we can get that done,” and then not delivering. Businesses pick up on this dishonesty and it creates a tumultuous relationship between the development team, the leadership, and the business.   Tune in to get Sam’s key insights on how to build trust between the team and the business, the to-dos and not-to-dos for scrum teams and leadership, his cautions for new scrum teams and leaders, and his advice and actionable steps for building a healthy relationship between the team, the leader, and the business!   Key Takeaways “Under-promising and over-delivering” and other unhealthy Scrum team mentalities perpetrated through the team or through the leadership: When the business fears that the team is under-committing or sandbagging the estimates they’ll create stretch goals for the team (which are often unhelpful) Theory X: The belief that people will not perform unless you force them to do so; that workers are lazy so you have to put systems in place to keep them working If the leader is making crazy demands, the team is going to end up overcommitting or sandbagging What healthy Scrum teams and leadership looks like: Theory Y: Assembling together the people who want to help you accomplish your goals, give them the barometers, and then letting them do it They have an established sprint goal There is collaboration between the development team and the product owner The product owner and development team are collaborating to come up with product backlog items that are aligned with the sprint goal The leader or business does not drive the team as hard as they can to get as much as they can (which can lead to sandbagging) Sam’s cautions to new Scrum teams and leaders: New Scrum teams need time to learn what they can do New Scrum teams tend to overcommit and add way more than they actually can do Dial it back a notch as a team — you can always add something later if you find you go through something too fast Sam’s principles for successful teams: Technical excellence enhances agility (if you are always providing a done increment, you are always in a position to release and always in a position to pivot or change direction) A professional Scrum team that really observes Agile principles and values will be the most successful at knowing exactly what they can accomplish and being able to deliver on it Actionable steps for building a healthy relationship between the team, the leader, and the business: Realistically forecast what you know you can deliver If you are on a development team and you’re using Scrum, give honest estimates and have the courage to say, ‘No, we will not commit to doing more than we can do.” Follow the three pillars of Scrum: transparency, inspection, and adaptation Establish a sprint goal that is meaningful between the business and the technology team Do enough planning during the sprint planning to build a credible forecast The business should be asking for the ‘what’ that they want, and as the technology team, give them some alternatives as to ‘how,’ then collaborate together to figure out the best option Have a well-established definition of ‘done’ that everybody understands, agrees to, and adheres to Never sacrifice your quality goals Use the ‘fist to five’ to vote on how confident the team feels on accomplishing a set goal As you go through the sprint, be honest with where you’re at In sprint review, discuss how problems were solved as well as the difficulties that were encountered (because stakeholders need to know that this is not magic) If you did not deliver, that should be the subject of your sprint retrospective   Mentioned in this Episode: The Agile Manifesto Three Pillars of Scrum Fist to Five   Sam Falco’s Book Pick: Bad Blood: Secrets and Lies in a Silicon Valley Startup, by John Carreyrou   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!

For this week’s episode, your host Dan Neumann is shaking things up! He’ll be answering some of the frequently asked questions that often come up in his work as well as some miscellaneous questions on Quora on the themes of Agile and Scrum.   In his coaching, Dan often finds that there are a lot of misconceptions, questions, or themes that continuously come up. Throughout this podcast, he’s hoping that the selected questions today will add some value to your own practice! Some of the questions include: “What resources would be good reading for an Agile Scrum Master,” “What is a road map in Agile,” “In practice, does waterfall planning ever accurately predict (or guarantee) completion dates for tasks and projects,” and more!   If you have any questions you’d like to ask for yourself, you can email them to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!   Key Takeaways What resources would be good reading for an Agile Scrum Master? Agile Project Management with Scrum, by Ken Schwaber (Very approachable for those even brand new Agile and Scrum) Anything by Mike Cohn, including his blog on Mountain Goat Software Essential Scrum: A Practical Guide to the Most Popular Agile Process, by Kenneth S. Rubin Listen to this podcast, of course! You can tweet or email in your own questions to have them answered in a future episode Always be sure to ask others in-person what they suggest and also to just simply pick up books and resources in whatever current challenges you may be facing For team dysfunction, check out the book: The Five Dysfunctions of a Team: A Leadership Fable, by Patrick Lencioni, as well as his follow-up book: Overcoming the Five Dysfunctions of a Team: A Field Guide for Leaders, Managers, and Facilitators If you’re interested in building your skills as a coach, read: Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, by Lyssa Adkins One of the opportunities for Scrum Masters to really help their teams is in facilitating effective retrospectives — in Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen, they lay out a five-step framework for an effective retrospective *Dan considers this a must-read! Dan’s final tip: always keep learning Can a product owner change a sprint backlog any day? The product owner’s role is to optimize the product backlog for value Hopefully, the product owner is participating during the sprint, but really the sprint backlog is the domain of the development team, and one would not expect to see them changing the sprint backlog day-in and day-out The product owner’s role is in the product backlog and to accept items as they are being delivered in the sprint, to clarify questions, and to make sure that sprint goal is achieved The sprint backlog will usually change throughout the sprint but it would be done in collaboration with the scrum team always keeping the sprint goal in mind What is a road map in Agile? A road map is simply a plan on how to get from one point to another Part of the mindset and approach to Agile road maps is really realizing that we’re not able to predict the future to a high degree of certainty or very specifically and that we need to be able to respond to change In practice, does waterfall planning ever accurately predict (or guarantee) completion dates for tasks and projects? Does it ever? Yes, there are times when waterfall or highly predictive planning can accurately predict completion dates for tasks and projects The scenarios or conditions under which it happens tend to be those that have a high degree of certainty about the capabilities that are needed If you have a team that’s done a particular type of development before with technology that they’re using again and really well-understood requirements, waterfall planning can accurately predict dates for tasks and projects The less certainty there is, that’s where waterfall planning breaks down   Mentioned in this Episode: Quora Agile Project Management with Scrum, by Ken Schwaber Mike Cohn’s Amazon Book Page Mike Cohn’s Blog on Mountain Goat Software Essential Scrum: A Practical Guide to the Most Popular Agile Process, by Kenneth S. Rubin The Five Dysfunctions of a Team: A Leadership Fable, by Patrick Lencioni Overcoming the Five Dysfunctions of a Team: A Field Guide for Leaders, Managers, and Facilitators, by Patrick Lencioni Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, by Lyssa Adkins Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen Agile Coaches’ Corner Episode: “Creating Effective Retrospectives with Sam Falco” The Agile Manifesto Quora Questions: “What resources would be a good reading for an Agile Scrum Master?” Asked by Alex Shaw “Can a product owner change a sprint backlog any day?” Asked by Mohammed Saiful Alam Siddiquee “What is a road map in Agile?” Asked by Maxime Sauvaget “In practice, does waterfall planning ever accurately predict (or guarantee) completion dates for tasks and projects?” Asked by Alan Pita   Dan Neumann’s Book Picks: Essential Kanban Condensed, by David J. Anderson and Andy Carmichael Making Work Visible: Exposing Time Theft to Optimize Work & Flow, by Dominica DeGrandis   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’s guest is Chris Lucian, the Director of Software Development at Hunter Industries and co-founder of the mob programming movement! Chris is passionate about the advancement of software craftsmanship and machine learning. He seeks the continuous improvement of himself, his family, his company, and his community. He believes that we can explore the unexplored potential in all things when looking at our processes with automation and creativity in mind.   In this week’s episode, Chris joins Dan to discuss mob programming. He shares the origin story behind mob programming, what it is and how it is utilized and dispells some of the general misconceptions around it. Chris also highlights many of the key benefits of mob programming and explains some of the best practices!   Key Takeaways Key takeaways from the origin story behind mob programming: After getting hired into an organization he was shocked by how everybody was working separately in cubicles and soon developed mob programming After implementing mob programming, their quality went through the roof and their cycle time went from a year and a half to twice a day and they stopped getting bug reports from production What is mob programming? A software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer This approach relies on face-to-face and side-by-side communication, team alignment, collaboration, and whole team involvement What are coding katas? The intentional practice of your coding craft Practicing together by writing code through games such as the Tic Tac Toe Game and the Bowling Game (linked below) Helps to build a habit or reflex out of coding Misconceptions around mob programming: When multiple people are working on a single piece workflow it will cost more for the company It is a waste of time to implement for the ‘simple stuff’ The benefits of mob programming: Paired programming helps mitigate risk from siloing and provides an increase in quality High-bandwidth learning The code moves all the time Really optimized for flow efficiency with less time being spent on waste activities like bug fixes Removing impediments becomes really fast A higher consciousness of experiments on the team to run about how to make things better and faster Mobbing on the simple stuff incentivizes programmers to make all that simple stuff go away permanently Physical cost-wise, four cubicles costs more than a single mobbing station with a high-end computer and two 80” screens Standup meetings become eliminated because the team is already aligned Group consciousness is constantly being developed Psychological safety and feedback becomes necessary through mob programming (which are critical components to a successful team) The codebase keeps moving forward and nothing gets in its way Mob programming best practices: Dedicated learning time Do frequent retrospectives Don’t just ‘try’ something; frame it as an experiment (regardless of the outcome, it provides invaluable learning)   Mentioned in this Episode: Chris Lucian Hunter Industries Mob Programming Agile Manifesto Woody Zuill Agile Coaches’ Corner Ep. 28: “Misconceptions and Interpretations of ‘The Agile Manifesto’ with Arie van Bennekum” Mob Mentality Show (Youtube Channel) Tic-Tac-Toe Kata Game Bowling Game Kata Twitter @ChristophLucian Google Study on the Top 5 Traits of Successful Teams Conway’s Law Companies that are Mob Programming Mob Programming RPG by Willem Larson Trello Board — Software Profession Resources Harvesting Mob Programming Patterns (A publication taking a look at the mob programming patterns discovered by IBM and LendingHome) Scrum Gathering Tokyo 2019: “Learning to Experiment” (Chris’ Keynote)  Agile Coaches’ Corner Ep. 5: “Exploring an Experimental Mindset with Adam Ulery” Linda Rising   Chris Lucian’s Book Pick: Thinking, Fast and Slow, by Daniel Kahneman   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’s guest is Jenny Tarwater! Jenny is a Collaboration Coach and owner of Blueshift Innovation, as well as the co-organizer of the Lean Agile KC Conference and Agile Game Night. On top of that, she is also the International Program Director for Launching New Voices for Women in Agile. The focus of today’s podcast is going to be all about the new Women in Agile initiative, Launching New Voices. As an expert on the topic, Jenny explains what the initiative is all about, how it is making a difference in the space, and how they are helping new voices step up and share their stories and experiences. She also highlights many success stories and the kinds of outcomes they have seen from the program and how you can get involved for yourself!   Don’t miss this week’s episode to learn about how Launching New Voices is empowering new speakers and providing powerful experiences for them to grow and succeed!   Key Takeaways  What is ‘Launching New Voices’ initiative? They are shedding light on new voices who are showcasing new ideas They are lowering the barrier for entry for those who have a message or a story  to tell through providing a better onramp to that stage It is an effort to break outside the traditional networks A chance to step out of the safety of your network and into new communities A program that gives service to the new voices that are being launched and provides new experiences for them A way to increase diversity and inclusion How Jenny is helping these new voices become more comfortable through Launching New Voices and Women in Agile: Through providing classes and training on public speaking for those new to speaking By providing opportunities and experiences for new speakers (specifically, giving them an opportunity to speak at the Women in Agile 2019 Conference and through pairing them with an experienced mentor) Success stories and outcomes from bringing new voices forward: Reignites the passion of the mentors and new voices alike The proteges become very recognizable Gives new voices incredible opportunities for networking as well as new speaking opportunities Provides multiple pathways to continue to foster these new voices after they speak at the conference Where to learn more or become a ‘new voice’ yourself: If you’re a protege or mentor, you can sign up on WomeninAgile.org to learn more For conference organizers, consider a Launching New Voices program at your conference Email NewVoices@WomeninAgile.org or contact Jenny personally through her LinkedIn or Twitter Other ways to get involved if you don’t have a Launching New Voices program near you: Join or create a meetup — they’re a great way to present new ideas and experiences to a smaller group   Mentioned in this Episode: Blueshift Innovation Lean Agile KC Conference Women in Agile Women in Agile’s New Initiative: Launching New Voices The Agile Alliance’s Women in Agile Initiative Women in Agile 2019 Conference NewVoices@WomeninAgile.org Jenny Tarwater’s LinkedIn Jenny Tarwater’s Twitter @JennyKCMO Agile Coaches’ Corner Ep. 11: “#WomenWhoCode — Betty’s Tips for Breaking into a Male-Dominated Industry”   Jenny Tarwater’s Book Pick: 7 Rules for Positive, Productive Change: Micro Shifts, Macro Results, by Esther Derby   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 Agile Coaches’ Corner, your host Dan Neumann and his AgileThought colleague, Sam Falco, will be taking a look at the Product Owner role in Scrum! The Product Owner Role sometimes gets overlooked in a lot of discussions around Scrum — yet, they’re one of the most important, complex, and crucial roles. They’re the visionary behind the product. Primarily, their responsibility to the Scrum team is to maximize the value of what the development team creates.   Tune in to hear Dan and Sam’s conversation to get more insight into the incredibly important Product Owner role — what it is, the challenges of being one, the valuable traits and skills for a PO to have, and some of the anti-patterns around the role!   Key Takeaways What is the Product Owner Role in Scrum? It is one of the three roles of Scrum (product owner, scrum master, and the development team) They’re the visionary behind the product They’re a crucial reason to why we have Scrum teams in the first place — they’re feeding the Scrum team the most valuable backlog items to turn into an increment of product every sprint The primary role of the Product Owner is to maximize the value of what the development team creates It’s important that it’s only one person; not a committee Challenges of the Product Owner Role: Managing and representing the opinions and voices of the dev team and stakeholders by distilling them into a coherent product backlog that’s optimized for value Valuable traits for a Product Owner: Someone with a distinct understanding of the market and a vision for a product that they want to bring into the world An entrepreneurial mindset Someone with very deep domain knowledge and business knowledge Understands the customers (or potential customers) Decisiveness Open-mindedness Strong leadership skills and the ability to motivate others Important skills for a Product Owner to have: Domain and business knowledge The ability to write a good business proposal as well as a strong canvas that articulates to funders what it is you’re trying to accomplish A willingness to test your hypothesis and do market research Communication skills and articulating things in a way that makes sense to your development team Negotiation skills Having a well-crafted and well-ordered backlog Being able to define the sprint goal Being able to communicate the vision and having the organizational skills to put the backlog in a good order so the dev team, customers, and stakeholders always know what’s next Technical skills (though it is not a must-have, it is helpful for them to have an understanding of the technology they’re working with) — but be careful, a PO with technical chops can sometimes interfere with the dev team Anti-patterns within organizations that are not setting up their Product Owner for success: Having someone without the right traits and skills in the Product Owner role Having a proxy PO stand-in for the real Product Owner, which jumbles the message and leads to “answer shopping” Having the role split into two people (where one becomes the ‘business’ PO owner and the other person becomes the ‘technical’ PO), which affects team self-organization and leads to uncertainty Product Owner anti-patterns: Rigidity Disregarding estimates Product Owner is an ‘order-taker’; simply taking notes and doing everything that is said (which causes issues because they cannot articulate a clear vision) When a Product Owner is not valuing everyone’s opinions equally (and instead, giving more value to those who are loudest or had the last say) Presenting a release plan to stakeholders that is wildly at odds with what the dev team can accomplish and expecting the dev team to live up to that Unbalanced focus and either being too involved with the dev team or not enough Spending too much time with the stakeholders Only showing up for sprint reviews   Mentioned in this Episode: Scrivener User Stories The Professional Product Owner: Leveraging Scrum as a Competitive Advantage, by Don McGreal and Ralph Jocham Thinking in Bets: Making Smarter Decisions When You Don't Have All the Facts, by Annie Duke   Sam Falco’s Book Pick: Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers, by Alexander Osterwalder and Yves Pigneur   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!