Podcasts about don mcgreal

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!

On today’s podcast, Dan Neumann is joined by his collaborator, Sam Falco! Today they will be comparing a product-focused approach versus a project-focused approach and highlighting some of the major differences. They also cover how to apply a product mindset to a project-focused organization and offer some key tips on how to effectively implement either!   Key Takeaways What defines a project-based approach? A defined start and a defined end Success is defined at the beginning by doing the project within scope, budget, and within the estimated time and to deliver on that Check off the tasks and get to the end This approach works best in best-practice or turnkey solutions where a defined process is always going to give you the same outcome The focus is on completing tasks What defines a product-based approach? No defined beginning and end Starting with an undefined want or need Delivering in increments Instead of asking, ‘Did we do all the things?’ success is defined around user adoption and user retention as well as revenue increases and/or cost savings Think of the three Vs: Vision to Value to Validation (these three Vs are also aligned with the three pillars of empiricism [which is what Scrum is based on]: transparency, inspection, and adaptation) With more complex work like software development, a product-based approach tends to work the best (as you will generate less waste and be able to change course as needed) Focused on achieving outcomes What exactly is a product? Anything that can be put out into the market and could satisfy someone’s needs or wants Something that will generate a benefit for the producer of the product (whether that is revenue, new customers, cost savings, etc.) Once that value is created, you want to release frequently and get feedback from the consumers of the product The mindset of product and some additional key pieces of information: Creating a sustainable pace (don’t bombard people with updates nor release too infrequently) A product mindset can be applied to a project-focused organization Remember: mindset is not just the way we think about something; it’s thinking that drives our actions (so you can still be in a project environment but have a product mindset) Getting a working piece of software into the hands of your customers every sprint rather than defining everything upfront   Mentioned in this Episode: Agile Coaches’ Corner Ep. 56: “Scrum and Agile Q & A with Christy Erbeck” The Professional Product Owner: Leveraging Scrum as a Competitive Advantage, by Don McGreal and Ralph Jocham Relentless Forward Progress: A Guide to Running Ultramarathons, by Bryon Powell How to Measure Anything: Finding the Value of Intangibles in Business, by Douglas W. Hubbard Agile Coaches’ Corner Ep. 27: “Deep Dive on Scrum Values with Sam Falco” Sam Falco’s LinkedIn   Sam Falco’s Book Picks: Blink: The Power of Thinking Without Thinking, by Malcolm Gladwell 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!

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!

Joining Dan Neumann today is return guest — and his colleague at AgileThought — Sam Falco! Sam is an Agile Coach and Certified Scrum Professional with an extensive background leading Agile development teams.   In today’s episode, they will be discussing coaching around resistance. Sam began developing this topic a couple of years back when he had seen some books and articles about overcoming resistance and how to defeat resistance. It had always struck him as kind of psychologically violent, very prescriptive, and not too collaborative. When he thought about his own experiences with resistance — both when he resisted some sort of change and his experiences coaching change — he discovered that it should not be thought as something to be overcome, but instead, as a useful red flag.   Sam further explains what coaching around resistance is, how to get people to talk about their emotions when they’re resistant, how to become an effective coach for leading changes or a transformation, and how to build the skills that are key to coaching around resistance. They also discuss the different levels of relationship that are important when coaching around resistance, the different types of inquiry you can apply in your coaching, and overall, what you should keep in mind while coaching.   Key Takeaways What is resistance? A natural reaction to an emotional process of adapting to difficult change What is coaching around resistance? It is when you act with empathy and help others to — not overcome or defeat something — but to work past what is blocking them Treating the underlying cause rather than ignoring it or bandaging over it How do you get people to talk about emotion (in regards to resistance)? Use humble inquiry (which is asking for information in the least biased, least threatening way which helps to build trust) Access your ignorance Ask in a neutral way Sam’s advice for being an effective coach for leading change or a transformation: Consider the relationship you have with this person (the four levels of relationship that Edgar Schein identifies are: ‘minus one’ relationship, transactional relationship, personal relationship, or intimate relationship) with the goal being ‘personal’ Have honesty about the mutual problem or the experience that is happening Honor commitments and promises Find that level of comfort where you both trust each other to be open and truthful Share information (which can help foster that personal relationship) Use relationship/team building exercises such as The Line Journey or Personal Maps Model the behavior you’re expecting from them Build a rapport so they’re open, transparent, and willing to share the true challenges that they may have Live by Scrum values (which helps to build the relationship to the right level) Use humble inquiry to build trust Use diagnostic inquiry, confrontational inquiry, and process-oriented inquiry at your discretion How to coach around resistance: Make sure to ask more questions Leave more space for the other person to talk Go beyond the mechanics; which includes the values of Scrum How do you build these skills? Start by trying them on/practicing with someone who you already have a good, trusting, personal relationship with   Mentioned in this Episode: Sam Falco (LinkedIn) Paul R. Lawrence Flawless Consulting: A Guide to Getting Your Expertise Used, by Peter Block Humble Inquiry: The Gentle Art of Asking Instead of Telling, by Edgar H. Schein Humble Consulting: How to Provide Real Help Faster, by Edgar H. Schein The Journey Line Exercise Mind Map Personal Map Managing for Happiness: Games, Tools, and Practices to Motivate Any Team, by Jurgen Appelo The Four Forms of Inquiry Scrum Values The Situation Behavior Impact Framework (SBI Model)Agile Coaches’ Corner Ep. 27: “Deep Drive on Scrum Values with Sam Falco” Nimble: A Coaching Guide for Responsive Facilitation, by Rebecca Sutherns   Sam Falco’s Book Pick: The Professional Product Owner: Leveraging Scrum as a Competitive Advantage, by Don McGreal and Ralph Jocham   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!