POPULARITY
This week on the podcast, Dan Neumann is joined by his co-host and colleague, Sam Falco. They are joined by special guest, Gene Gendel, an Agile Coach, Trainer, and Organizational Design Agent. He is a proud member of the Scrum Alliance Certified Enterprise Coaches (CEC) and is Certified in Agile Leadership (CAL), Large Scale Scrum (CLP-LeSS), and Scrum @ Scale (S@S). Gene’s focus is on helping organizations and teams with improving system design and organizational structure and overall efficiency — which he engages in at all organizational levels (senior leadership, mid-level management, teams, and individuals.) Today, Dan, Sam, and Gene will be exploring the Large Scale Scrum Framework also known as LeSS! They’ll be giving an overview of the framework, going over some of the lesser-known aspects, debunking some of the misconceptions around it, and highlighting the types of organizations and organizational challenges it is best suited to address. Gene also provides many key insights and tips for the framework! Key Takeaways What is Large Scale Scrum (LeSS)? It was initially called LSS (with the ‘e’ added later because “less is more!”) It is Scrum It is not multiple teams doing their own, independent Scrum; It is multiple teams working in the same Scrum, for the same Product Owner, on the same wider defined product, on the same cadence An organizational design framework It is not a way to scale up or make things more complex It is often referred to as a de-scaling framework as it requires the removal of organizational overhead in order to scale up Agility Highlights organizational problems and asks you to solve them How to address fear and resistance when it comes to implementing LeSS: Mid- and first-level management can be resistant to anything that is bringing about change or uncertainty — but not to worry: LeSS will not change your organization in a broad and shallow way; it is meant for deep and narrow organizational changes that take months to years to succeed The type of organizational challenges LeSS is best-suited to addressing: When the organization needs to get many teams working in the same direction to deliver on a project, product, or significant capability How does LeSS help teams coordinate across their boundaries in order to pull together in the same direction? Since there is so much transparency and visibility between the various teams in various channels with LeSS, there is almost no additional need to coordinate outside of those events Every team in a LeSS product group is almost a clone of another team Other important aspects of the LeSS framework: It is highly encouraged to communicate in-person with one another The Scrum Master is a full-time role (if a company implements LeSS they should be prepared to go to HR and makes sure that a Scrum Master is entered into the database as a role on par with any other role) LeSS managers are capacity builders, not task managers LeSS introduces a concept called ‘undone work’ which is a necessary evil at the beginning steps of LeSS reduction (the goal of LeSS is to shrink the undoneness to null over time) The LeSS framework wasn’t created reactively to meet market demand; it was very proactive and has almost a decade of experiments and experiences documented behind it In order for a LeSS product group to be formed you need to properly define the product Mentioned in this Episode: Large Scale Scrum (LeSS) Larman’s Laws of Organizational Behavior The Scrum Guide The Green Book: Collection of Independent Essays About Agility, by Gene Gendel Gene Gendel’s Book Picks: Taiichi Ohno’s Workplace Management, by Taiichi Ohno Large-Scale Scrum: More with LeSS 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!
In this podcast Shane Hastie, Lead Editor for Culture & Methods, spoke to Dave West, Chief Product Owner of Scrum.org about the state of Scrum, the latest revision to the Scrum Guide, the rise of Digital and the way Scrum.org maintains its courseware. Why listen to this podcast: • Scrum continues to be the dominant force in agile/digital/lean startup approaches • As complexity grows in our world the value of Scrum continues to grow • If you’re not doing Scrum per the book it doesn’t mean you’re “wrong”, just don’t call it Scrum • It’s not optional to improve how you work – it’s mandatory! • Scrum is fundamentally about dealing with complexity and improving productivity • Digital is about building organisations that are very different and able to take advantage of new technologies with new business models • Organisations need to move very strongly towards a product mindset and a product structured organisational architecture More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2xjpDDv You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2xjpDDv