Podcasts about ralph jocham

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!

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!