Podcasts about scrum product owner

Cost of Delay, auf Deutsch Verzögerungskosten, beschreibt die wirtschaftlichen Verluste, die entstehen, wenn ein Produkt oder Feature später als geplant auf den Markt kommt. In der neuen Folge von der Produktwerker diskutieren Tim und Dominique, warum dieses Konzept für Product Owner zentral ist und wie es uns bei strategischen Entscheidungen helfen kann. Dominique definiert Cost of Delay als die Summe aller wirtschaftlichen Kosten, die durch Verzögerungen entstehen. Das reicht von entgangenen Umsätzen und Marktanteilen bis hin zu Lizenz- oder Wartungskosten für alte Systeme. Ein Beispiel zeigt, wie ein verspäteter Systemwechsel zu Millionen Euro zusätzlichen Lizenzgebühren führen kann. Aber auch weiche Faktoren wie verlorene Marktreputation oder Kundenzufriedenheit können in die Bewertung einfließen. Besonders praktisch wird Cost of Delay bei der Priorisierung von Backlog-Items. Features können wie verderbliche Waren betrachtet werden: Je später sie geliefert werden, desto geringer ihr Nutzen. Um das zu quantifizieren, benötigt man eine klare Formel. Ein gängiger Ansatz ist, die Kosten pro Zeiteinheit zu berechnen, zum Beispiel pro Woche oder Sprint, und diese durch die Größe der Arbeit zu teilen. Dieser Ansatz ähnelt dem Konzept Weighted Shortest Job First (WSJF). In der Praxis ist jedoch nicht immer alles messbar. Dominique und Tim betonen, dass Schätzungen oft auf Annahmen basieren müssen. Dabei geht es nicht um absolute Genauigkeit, sondern um eine Diskussion, die ein gemeinsames Verständnis schafft. „Es ist besser, mit unscharfen Daten zu arbeiten, als gar keine Grundlage zu haben“, so Dominique. Wichtig sei es, Annahmen zu dokumentieren und regelmäßig zu überprüfen. Darübe rhinaus ist ein weiterer spannender Aspekt die enge Verbindung zwischen Cost of Delay und der Produktstrategie. Unternehmen müssen abwägen, ob sie lieber schnell liefern oder auf Perfektion setzen wollen. Diese Entscheidung hat nicht nur Einfluss auf die Priorisierung einzelner Aufgaben, sondern auch auf die langfristige Marktpositionierung. Die Folge schließt mit wertvollen Tipps für den Einstieg in das Thema Cost of Delay. Tim und Dominique raten dazu, sich zunächst auf einfache Annahmen zu stützen und diese regelmäßig zu überprüfen. Denn nur wer die Kosten von Verzögerungen versteht, kann nachhaltig erfolgreiche Produkte entwickeln. Passend zur aktuellen Folge empfehlen wir euch übrigens noch diese Folge, weil sie thematisch sehr passen und in der Folge referenziert werden: - Technische Schulden und wie wir als Product Owner damit umgehen (https://produktwerker.de/technische-schulden/) - Flow Metriken für Scrum Product Owner (https://produktwerker.de/flow-metriken/) - Product Principles (https://produktwerker.de/product-principles/) - Produktstrategie in die Praxis bringen (https://produktwerker.de/produktstrategie-in-die-praxis-bringen/)

Why Scrum Product Owner Certifications ARE Worth It.. Are you ONLY learning what the book says? Or are you really learning practical application of what the book says? How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

In this special episode, we bid farewell to Simon Hilton, who has expertly guided our podcast, and welcome Dee Rhoda as the new host. With over 15 years in IT and a deep commitment to Agile practices, Dee brings a wealth of experience transforming teams and supporting Scrum frameworks. As a certified ScrumMaster and Scrum Product Owner, she's passionate about helping teams and organizations succeed through effective Scrum practices. Join us for a reflective conversation on past episodes and an inspiring look at what's next for the Comparative Agility Podcast.

In this episode, Dave West, CEO of Scrum.org, joins host Ruud Adriaans live from the product owner event 2024 in Rotterdam, the Netherlands, to discuss how the Agile Product Operating Model is reshaping the role of product owners. Dave shares key insights into the differences between this new model and traditional Scrum, as well as the essential skills product owners will need to thrive in this evolving environment. He also explores the potential impact of AI on roles like product owners and scrum masters, offering practical advice on how to prepare for the future of work. In this episode, we cover: Evolution of Scrum, Agile Product Operating Model, Scrum, Product Owner, AI, Scrum Master, future of work, skills development, Agile transformation About this podcast: In the Product Owner podcast, we speak with an interesting guest from the world of product management every week, diving into real experiences, lessons, and tactics from product owners, entrepreneurs, and specialists. The Product Owner podcast is an initiative by Productowner.nl.

Stephanie Cully: How To Lead with Empathy, The Story of an Open-Minded Scrum Product Owner Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Leading with Empathy, The Story of an Open-Minded PO In this episode, Stephanie discusses her experience with an exceptional Product Owner (PO) who, despite having no prior experience in Agile and Scrum, demonstrated a remarkable willingness to learn and adapt. The PO's approach was characterized by asking questions, seeking help, and engaging in training sessions to better understand Agile practices. This openness extended to discussions about customer pain points and the user journey, contributing significantly to the team's ability to deliver effectively. The PO's caring attitude towards the team and flexibility in adapting to the developers' needs further exemplified the qualities of a great PO. The Bad Product Owner: Addressing the Root Causes of an Absent PO In this segment, Stephanie shares an experience with a Product Owner (PO) who was essentially absent, leaving a Business Analyst (BA) to handle product prioritization. The BA inadvertently compounded the issue by taking on the PO's responsibilities instead of addressing the root cause together with the team and the PO. Stephanie intervened to emphasize the importance of understanding why the PO was unavailable, revealing that the PO was overwhelmed with multiple roles. Through facilitating direct conversations among the BA, developers, and stakeholders, Stephanie highlighted the need for clear roles and effective time management in agile teams. If you are facing a similar situation, where the PO is mostly absent, you may want to review our Sprint Checklist, which helps you have a coaching conversation with the PO, and define clear expectations about participation in the work with the team.   [IMAGE HERE] Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate.   About Stephanie Cully Stephanie Cully is a Scrum Master, and CEO of Scrum Life Consulting. Stephanie founded Scrum Life with a mission to help Scrum Masters overcome self-doubt and land the role. You can link with Stephanie Cully on LinkedIn.

Johannes Andersen: Collaboration Over Isolated Performance, Lessons Learned as a Scrum Product Owner Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Johannes shares a personal story of his struggles as a Product Owner (PO). In his early career, Johannes believed he needed to have all the answers and provide detailed requirements alone; but he quickly found that it was not so easy to define all the features by himself. This experience taught him the importance of involving the entire team in writing user stories, highlighting that collaboration, not individual effort, leads to success. Johannes emphasizes focusing on outcomes, encouraging POs to ask goal-oriented questions and to view technical solutions through the lens of their importance. He recommends resources like Mike Burrows' list of questions to foster effective communication and collaboration.   [IMAGE HERE] Recovering from failure, or difficult moments is a critical skill for Scrum Masters. Not only because of us, but also because the teams, and stakeholders we work with will also face these moments! We need inspiring stories to help them, and ourselves! The Bungsu Story, is an inspiring story by Marcus Hammarberg which shows how a Coach can help organizations recover even from the most disastrous situations! Learn how Marcus helped The Bungsu, a hospital in Indonesia, recover from near-bankruptcy, twice! Using Lean and Agile methods to rebuild an organization and a team! An inspiring story you need to know about! Buy the book on Amazon: The Bungsu Story - How Lean and Kanban Saved a Small Hospital in Indonesia. Twice. and Can Help You Reshape Work in Your Company.   About Johannes Andersen Johannes comes from a finance and fintech background, and is now an enterprise agility maestro at a leading telco in Copenhagen! He focuses on optimizing the flow from strategy to execution, championing portfolio management with a keen eye on doing the right things, even if imperfectly. Johannes is an international speaker on product development topics. You can link with Johannes Andersen on LinkedIn.

Freddie Brown Jr: Inspiring Excellence, How the Commitment and Clarity Transforms the Performance of the Scrum Product Owner Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Inspiring Excellence, How the Commitment and Clarity Transforms the Performance of the Scrum PO In this segment, Freddie highlights the exceptional qualities of a great Product Owner (PO), Sara. She exhibited visionary leadership, with a clear and effectively communicated product vision. Her ability to inspire the team and her commitment to the product's success were some of the most important qualities highlighted by Freddie. Sara's enthusiasm for the work, skill in defining and explaining requirements, and prompt feedback to the development team set her apart as an exemplary PO. The Bad Product Owner: Collaboration Over Dictation, Tackling the Micro-Manager Scrum PO Challenge In this segment, Freddie discusses the challenges of dealing with a micro-managing Product Owner (PO) who dictates team processes and avoids accountability. This PO type often over-commits work, ignoring team capacity. Freddie suggests that Scrum Masters should foster a collaborative environment, seek to understand the team's feelings towards the PO's behavior, and communicate with the PO to get to the root cause of their behavior's. He emphasizes the importance of helping the PO explain their goals to the team, to create alignment and avoid misunderstandings.   [IMAGE HERE] Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate.   About Freddie Brown Jr. Meet Freddie Brown Jr, the Agile Genie! With a magic brain that grants your corporate wishes faster than Aladdin's lamp, he transforms chaos into strategic brilliance. He's the genie you never knew you needed, making agile dreams come true – all with a sprinkle of humor that's truly magical!

Viktor Didenchuk: Effective, Protective, Result-Oriented, The Traits of a Successful Scrum Product Owner Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Effective, Protective, Result-Oriented, The Traits of a Successful PO When describing a great Product Owner and how they work, Viktor focuses first on effective communication; a great PO must clearly articulate what's working and what isn't to the team and stakeholders while fostering a reflective environment. Secondly, protection is essential; they must safeguard the team and product vision amidst constantly evolving technology, resisting the urge to chase every new trend. Finally, being result-oriented is vital; a great PO has a clear understanding of the desired outcomes and end state of the product. Viktor encapsulates this with the mantra, "It's always the leader who is wrong, and it's always the team who wins." The Bad Product Owner: The Blind PO, Focusing On Short-Term Requests Instead Of The Overall Product Vision Viktor discusses a common anti-pattern in product ownership: the 'blind PO' who lacks a clear vision. This type of PO is overly preoccupied with politics and managing stakeholder requests, neglecting the broader product vision. They often focus solely on satisfying immediate customer demands, which can work for some but not all scenarios. This approach can lead to team demotivation. Viktor emphasizes the need for POs to reflect, ask probing questions, and truly 'own' the product, considering long-term goals and the product's overall direction, rather than just short-term customer requests.   [IMAGE HERE] Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate.   About Viktor Didenchuk Viktor began his career as a Software Engineer in the mid 2010's, before discovering a passion for coaching and facilitating value delivery. He currently serves as a Scrum Master at Lloyds Banking Group, the UK's largest retail bank, where he contributes to the Agile transformation of a 60,000+ employee organization, navigating and sharing the challenges encountered. You can link with Viktor Didenchuk on LinkedIn. 

Kulsoom Pervez: From Interference to Empowerment, Overcoming Micromanagement Tendencies in a Scrum Product Owner Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Customer-Centric Product Owner, Focused On Clear Prioritization And Collaboration With The Scrum Team Kulsoom shares insights on the traits of a great Product Owner (PO), that excelled by staying close to the customer, understanding market needs, and bringing valuable insights to the team. This PO consistently communicated the vision and roadmap, while also being receptive to suggestions from the team. Notably, the PO's ability to prioritize work effectively involved mastering the art of saying "no." This PO's strengths included building strong relationships with the team and maintaining an open-minded approach, which facilitated a smooth and productive partnership, making the Scrum Master's role more effective and the overall team dynamic more cohesive and successful. The Bad Product Owner: From Interference to Empowerment, Overcoming Micromanagement Tendencies in PO's Kulsoom discusses a Product Owner (PO) that tended to micromanage the team and focused excessively on details, neglecting the broader vision and roadmap. This over-involvement extended to interfering with estimations and pushing work onto the team rather than allowing them to pull it, often losing sight of priorities. Kulsoom advises a non-judgmental approach to understand the root causes of this behavior, such as the PO's work environment, their trust in the team, or underlying challenges they face. She emphasizes the importance of including the PO in retrospectives to build trust and address these challenges effectively.   [IMAGE HERE] Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate.   About Kulsoom Pervez Kulsoom is passionate about constructing sustainable, resilient, and high-performing teams, consistently delivering value to customers through the transformative power of Agility. She embodies a leadership style that inspires, empowers, and fosters the growth of her colleagues. Kulsoom enjoys reading and has also dabbled in blogging. You can link with Kulsoom Pervez on LinkedIn.

Felix Rink ist wie versprochen zum zweiten Mal Gast im Produktwerker Podcast. Er spricht mit Oliver über Flow Metriken und in wie weit diese für Produktmenschen hilfreich sein können. Nachdem die beiden vor einigen Wochen über Sinn und Unsinn von Vorhersagbarkeit in der Produktentwicklungen philosophiert haben, wird es in dieser Episode also wesentlich konkreter. Zu Beginn der Folge klären Oliver und Felix, was Flow überhaupt ist und welche Voraussetzungen erfüllt sein müssen, damit man Flow messen kann. Der Kanban Trainer bricht die Flow Metriken im Anschluss auf die vier wichtigsten Basis Metriken herunter. Besonders wertvoll für den eigenen Kontext sind Felix Ideen und Anregungen, in welchen Scrum Events und bei welchen Praktiken und Artefakten diese Flow Metrics die Verantwortlichkeit eines Product Owner unterstützen können. Im Detail geht es um das Sprint Planning und das Sprint Review, sowie die Arbeit mit dem Product Backlog. Wie gewohnt schließt die Podcastepisode mit Tipps und Tricks für deine tägliche Arbeit als PO ab. Felix empfiehlt in der Episode, Actionable Agile für Flow Metriken oder die Monte Calo Simulation einzusetzen. Actionable Agile - https://www.actionableagile.com Es gibt wie erwähnt auch Excel Alternativen. Felix empfiehlt zwei Templates: https://github.com/SkeltonThatcher/bizmetrics-book#example-spreadsheets https://www.focusedobjective.com/pages/free-spreadsheets-and-tools

BYNTK Cover featuring Yadira Caro Yadi Caro has been working with teams of developers and engineers for over a decade with US military organizations. Her expertise is to work with teams and customers solving organizational business processes and creating technical solutions. Her certifications include Organizational Behavior (Harvard), Project Management Professional (PMP), Scrum Product Owner, Certified Knowledge Manager, Lean Six Sigma, and Business Analytics (MIT).  She has worked with hundreds of customers across the world as she fluent in Spanish and Portuguese. While she continues her work as a consultant in the Defense industry, Yadi also provides training and coaching to help teams and individuals master the "soft" skills they need to succeed. She also recently completed an ADHD (Attention Deficit Hyperactivity Disorder) and Life Coach Certification Program, which enriches her experience to coach neurodiverse individuals.  Connect via LinkedIn Discover Hardcore Soft Skills Podcast

Photo by Blondinrikard Fröberg on Flickr under CC by/2.0 As a job candidate, it's up to you to shine the spotlight on the skills and experiences you've had that are relevant to the job or company you are interviewing for. Too often, candidates prepare scripted answers and don't adapt them to the specific interview questions, company or interviewer. On this episode, I share some advice on effectively communicating during job interviews. Take a moment It is not enough to have a dozen well-rehearsed stories that illustrate examples in response to the interview questions you anticipate. Invariably, you will get asked a question that you haven't prepared for. In a few seconds you will have to decide which story fits the question best and start your answer. The danger is that you will tell the story as you've prepared it without tailoring it to your audience or the exact question. Interviewers remember when a response doesn't answer their question. But they don't remember that you took an extra few seconds before starting your response. Focus on what your audience wants to hear The AIM framework from Lynn Russell and Mary Munter is a great tool to employ when preparing any communication, including job interview responses. The acronym stands for Audience, Intent, Message. The audience is the person or people receiving the communication. The intent is both your intent: what you want to happen, and the intent you want to create in your audience. The message is both the delivery mechanism and the content. When preparing for any interview, take the time to really think about your audience. Are you speaking with the recruiter, or the hiring manager? These are two different audiences, and your intent will be different. For the recruiter, your intent is to communicate that you are a strong candidate with relevant skills; you want to advance to the next round of interviews. The recruiter needs to believe that you are the right choice for the role she is trying to fill. For the hiring manager, your intent is to communicate that you have the relevant skills, right fit with the team, and ability to do the job; in this case, you want to get the offer. The hiring manager needs to believe that you are capable of doing the job, fitting in with the team, and growing to be a valuable asset to the company. Start with “the end in mind” Reminding yourself of your intent before preparing, and before your actual performance (the interview) will help you shine the spotlight on the right facets of your experiences and respond appropriately to questions that you did not expect. This starts with the most common interview question: Tell me about yourself. The interviewer wants to know just the relevant details about what you've done that led you to this company and this role at this moment. For example, the fact that you used to build Contact Relationship Management systems for nonprofit organizations may have nothing to do with the work you do today. Your ability to analyze voter data and cut turf for political canvassers? Irrelevant. Scrum Master and Scrum Product Owner certifications? Who cares. But throughout your career, maybe you've always been committed to helping the people around you and your clients communicate more effectively. BINGO. I might be talking about myself here... When answering behavioral interview questions ("Tell me about a time when…") don't get sucked into the trap of sharing a very procedural (and generic) explanation of the situation, and what you did filled with every detail you can think of.  Think about your intent: why are you telling this story? What does it demonstrate about how you think and work? What skill or competency does it demonstrate that is relevant to the role or company you are interviewing for? It's all about structure and focus And remember that the human you are talking to is hardwired to look for structure. Stories have a beginning, middle and end. Gustav Freytag mapped out the classic narrative arch: Introduction, Initial incident, Rising Action, Climax, Falling Action, Resolution, Denouement over 160 years ago. People retain structured information 40% more reliably and accurately than information that is not structured. When you are answering a question, make sure that the content fits into a structure and is relevant to the audience and the question. There are many interview answer structures or frameworks: STAR is the most common: Situation Task Action Result, but I like CAR: Context (or Challenge) Action Result. These are not the only two that are out there: sometimes you want to add a learning or a take-away (CARL or CART) at the end, or a summary at the beginning (SCAR). Consider the level of detail, language and analogies that may be relevant to your audience. For example: if you are interviewing for a data analytics role, you might focus on the part of the story where you extracted insights from data. If you are interviewing for a role that focuses on interaction with customers and clients, you might focus on that part of the story where you determined what your client (internal or external) really wanted to know from the data and how you delivered the insights on-time. If you are interviewing for a role that requires cross functional collaboration, you might focus on how you worked with multiple teams to pull together the dataset you needed. Think of these as different facets of a multi sided die. The die is the experience or story, but depending on what question you are asked and what role you are interviewing for, you will expose different facets. That's how you can shine the spotlight on the parts of your experience that are most relevant to your audience and, ultimately, land the job!  

Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, we share two retrospective formats. The one that Matthias likes to use as the Product Owner, is the Client - Team retrospective, where the goal is to engage with the client and try and build a better relationship between Client and Team.  Because Matthias is a Product Owner, we dive into his definition of a successful Product Onwer. He shares the importance of understanding the responsibilities that the Product Owner has, as well as the PO's role in helping people achieve something great, instead of telling them what to do. In this segment, we also talk about the importance of setting great Sprint Goals, and Matthias shares with us a video that helps explain the importance of knowing how to communicate requirements as a Product Owner.  Featured Retrospective Format for the Week: The Meme Agile Retrospective, a fun and engaging format Matthias prefers to focus on the core aspect of the Retrospective practice, helping the team stay constructive and productive. He likes to change formats regularly, and recommends the “meme retrospective” as a fun and active retrospective format that invites the team members to actively contribute to the retrospective.  Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!   About Matthias Kostwein Matthias is a Project Manager, turned Programmer, turned PO, turned Client Service Director with a varied background in different industries from Mechanical Engineering to IT Agencies. Throughout all of his journey, Agile has been part of his work life, even before he knew what Scrum was. You can link with Matthias Kostwein on LinkedIn. 

Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Matthias joined, as a Product Owner, a project that was in trouble. A former Product Owner had quit, the team was having trouble predicting what they could deliver. On top of that, the Scrum Master and the Tech Lead did not see eye-to-eye. In this messy situation, Matthias had to help out the team and the Scrum Master recover! Luckly, Matthias had enough experience as a Scrum Master to help mediate the conflict! Listen in to learn how Product Owners can be critical partners to the Scrum Master when things aren't working well!    About Matthias Kostwein Matthias is a Project Manager, turned Programmer, turned PO, turned Client Service Director with a varied background in different industries from Mechanical Engineering to IT Agencies. Throughout all of his journey, Agile has been part of his work life, even before he knew what Scrum was. You can link with Matthias Kostwein on LinkedIn. 

Wir sprechen in unserem Podcast über Product Owner und meinen damit implizit Scrum Product Owner. Doch was ist eigentlich mit Kanban und Product Ownern? Kennt Kanban POs? Über diese und viele weitere Fragen spricht Tim in dieser Folge mit Michael Mahlberg, Geschäftsführer von The Consulting Guild GmbH. Als Berater und Begleiter in großen Veränderungsvorhaben und ausgewiesener Kanban-Experte teilt Michael zu Beginn dieser Episode seine Sicht auf die Unterschiede zwischen Scrum und Kanban. Kanban ist Change und startet bei dem, was schon da ist und lässt sich wunderbar mit Scrum verbinden. Die beiden stellen fest, dass die Definition von "Product Owner" sehr schwammig ist. Diese Unschärfe bezieht sich nicht nur auf die dreiviertel Seite an Beschreibung im Scrum Guide, sondern auch in der Interpretation vieler Organisationen. Es gilt, die Frage zu beantworten: Welche Art von Product Owner wollen wir in dem jeweiligen Kontext einsetzen. Michael führt anschließend aus, was Kanban generell zu Rollen sagt. Und ergänzt seine persönlichen Beobachtungen aus der eigenen Beraterpraxis. Wie immer schließen wir mit Tipps und Tricks für dich als PO ab. Weitere Quellen, die Michael empfiehlt, um sich noch detaillierter mit dem Thema auseinander zu setzen: - Michael Mahlberg: Why are there no Product Owners in Kanban (http://agile-aspects.michaelmahlberg.com/2019/07/why-are-there-no-product-owners-in.html) - Kanban University: The Official Guide to the Kanban Method - Buch zu Kanban-Grundlagen: Essential Kanban Condensed - Das "Blaue Buch" von David J. Anderson: KANBAN - Successful evolutionary change for your technology business Falls du Kontakt mit Michael aufnehmen möchtest, kannst du ihn gerne über Webseite seiner Firma (http://consulting-guild.de/) oder gerne auch direkt via Mail unter mm@consulting-guild.de kontaktieren.

Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Coaching a PO into a great PO! It is possible to help Product Owners improve their game, and as Scrum Masters, we should be ready to coach those PO's that want to get better. In this segment, we share the story of a PO that was able to recover from some key anti-patterns and become a great PO! The Bad Product Owner: Does Technical Background affect the PO performance? Yes and no… Here are two examples In this segment, we talk about two different types of Product Owners. One had a strong technical background, and the other one didn't. We discuss how these different types of background can negatively impact the performance of the PO. We also discuss the role of the Scrum Master in fostering and maintaining a good communication practice between PO and team! Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate. About Allison Zimmerman Allison believes that all people have the power to succeed when they work together. As a teacher-turned-scrum master, she has spent the last five years helping enterprise teams build on their strengths to deliver customer value. She also serves as a Scrum Master Community of Practice leader, supporting growth and development of scrum masters across many teams. You can link with Allison Zimmerman on LinkedIn. 

Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The great Facilitator This Product Owner had come from a Marketing Background, and had no experience with Scrum or as a PO. However, the PO was great at facilitation, and listening to the team and stakeholders. People felt heard, and understood by the PO, who was open minded! The Bad Product Owner: The career-oriented PO This Product Owner had come from a business background, and was focused on getting a promotion “out of the PO role”. The PO was using Scrumn as a means to further their own career, and that left the Scrum Master and team bitter about the way in which they were treated! Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate.   About Shahin Sheidaei Shahin Sheidaei is an Agile, Lean and Success Coach,International Speaker, Transformation Expert, and Entrepreneur.   Shahin is a passionate organizational designer focusing on organizational performance, and is also founder and principal coach at Elevate Change Inc. You can link with Shahin Sheidaei on LinkedIn and connect with Shahin Sheidaei on Twitter. 

Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   About Mickey Alon Mickey Alon is the founder and CTO of Gainsight PX, the Product Experience Platform. He is a serial entrepreneur focused on designing, building and launching innovative products that help drive business outcomes. Mickey co-authored Mastering Product-Led Growth - a book on building product-led growth strategy. He's held several executive positions at other companies, including being the CEO and co-Founder at Insightera. You can link with Mickey Alon on LinkedIn. 

Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The balance of skills that enables delivery of customer value! A great Product Owner finds a balance between helping, and attending to the customer needs, and what the team needs to succeed. Great Product Owners also build relationships with the team and their stakeholders. Even if a great PO might not be technical, they are able to create a common language with the team, so that both can inform each other and come to decisions that help the team succeed in the ultimate goal of delivering customer value!  The Bad Product Owner: The many anti-patterns that emerge when the PO does not understand their role In this segment, we discuss several Product Owner anti-patterns. We start with the problem that many people in the role don't have a deep enough understanding of the role, and it's expectations, even if they are quite clearly defined in the Scrum Guide. From that lack of understanding many patterns can emerge, from not being able to contain/manage the scope to lack of understanding that the PO is there to help the team succeed, and not to be a “demanding tyrant customer” to the team! Listen in to learn about some of the critical anti-patterns that emerge when people don't understand the PO role sufficiently well.  In this segment, we refer to the Coach Your PO e-course, which outlines some of the aspects to cover with PO's and how to do it.  Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate. About Nousheen Manzoor Nousheen believes that the future of leadership is kindness and empathy, and the same goes for any role which involves individuals and teams, like the Scrum Master role! You can link with Nousheen Manzoor on LinkedIn.

Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Enthusiastic Product Owners, and how they behave when working with Scrum teams Great Product Owners are enthusiastic about what they do, they have a clear Vision, but are able to stay curious and listen to the team, stakeholders, and customers. In this segment, we look at some of the behaviors that Product Owners like this have when interacting with the team and the Scrum master. The Bad Product Owner: Two Anti-Patterns to look out for! In this segment, we explore two Product Owner anti-patterns that illustrate how the PO role is not only critical, but can be actively destructive for a Scrum team. The first story features a Product Owner that preferred to focus on the hardware side of the product, and through their command-and-control personality tried to bully the Scrum Master into submission!  The second story is about the Product Owner that was absent, a very frequent anti-pattern for the PO role.  In this segment, we refer to our Coach Your Product Owner e-course, which helps you tackle some of these anti-patterns proactively in your role as a Scrum Master! Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate. About Shaun Bradshaw Shaun is a founder and principal of Zenergy Technologies, a modern software delivery solutions firm that specializes in Agile, DevOps, Quality, and Automation. Shaun's background in QA, testing, and metrics has played an important role in his work as an Agile consultant since he joined the community in 2008. You can link with Shaun Bradshaw on LinkedIn and connect with Shaun Bradshaw on Twitter. You can also follow Shaun Bradshaw's blog at the Zenergy Technologies site.

Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Curiosity, dedication and Vision, critical skills for great Scrum PO's Great Product Owners play a pivotal role in the success of Scrum teams, they define the Vision, and work to anticipate end user needs. But to achieve that, they - as Robbie puts it - “do all kinds of small things along the way”. In this episode, we discuss how this PO was able to put into practice some specific techniques that helped them define what needed to be done, while keeping a great relationship with the stakeholders, and keeping the trust by the team.  The Bad Product Owner: The many demands on the Scrum Product Owner role The Product Owner is a very demanding role, Robbie describes how this aspect is often misunderstood by people in the role. The demands of the PO role go far beyond the context of the product itself, and include many demands on the human relations and collaboration skills for the Product Owner.  Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate.   About Robbie Ross Robbie is an Agile Practice Manager at Jumar Technology with a passion for working with and empowering teams to foster an Agile environment at scale. He's also a Certified Scrum Master, Kanban practitioner and Agile community member helping teams release their genuine potential to deliver value. Quite a career shift since completing a Sports Science degree at University. You can link with Robbie Ross on LinkedIn and connect with Robbie Ross on Twitter. 

Fragt man drei Product Ownerinnen, was sie als ihre Verantwortlichkeit ansehen, so erhält man vier sehr unterschiedliche Antworten. In vielen Fällen ist eine Ursache für die Vielfalt der Rolleninterpretationen: Manche Product Owner arbeiten in einem Scrum Kontext und andere wiederum als SAFe Product Owner. Es ist also an der Zeit, dass Oliver und Dominique über die Gemeinsamkeiten und Unterschiede sprechen. Denn aus ihrer Perspektive ist dieses Thema eines der großen Missverständnisse in der agilen Produktcommunity. Ein Scrum PO ist etwas komplett anderes als ein SAFe PO. Und nachdem einige Beiträge und Meinungen in den letzten Wochen in die Timeline der beiden gespült wurden, ist es auch ein guter Zeitpunkt die eigene Sichtweise zu formulieren. Dominique und Oliver starten mit einer Reflexion eines Beitrags von Roman Pichler zu "Six Types of Product Owner", der in diesem Podcast schon in der einen oder anderen Episode zitiert wurde. Fokus legen beide aber auf den Scrum Product Owner und den SAFe Product Owner. Wo liegen die Gemeinsamkeiten, welche Unterschiede findet man? Nach einem Blick in den Scrum Guide und in die detaillierteren Erläuterungen in SAFe wird auf die eine oder andere Äusserung von Kollegen referenziert, u.a. Sohrab Salimi oder Heiko Stapf. Natürlich konkretisieren Oliver und Dominique darüber hinaus auch sehr klar ihren eigenen Standpunkt. Sie klären, dass in Produktwerker-Podcast sehr häufig der Scrum Product Owner im Mittelpunkt der Diskussionen steht. Wie immer schließt diese Episode mit konkreten Tipps & Tricks ab.

Der Scrum Product Owner wird oft all zu leicht auf die leichte Schulter genommen. Manche Fehler erlebe ich immer wieder! Deswegen hier die 11 häufigsten Fehler die oft falsch gemacht werden!

Als Scrum Product Owner nutze ich das Scrum Framework, um ein möglichst erfolgreiches Produkt zu entwickeln. Was ist aber mit dem dritten Teil „Owner“ konkret gemeint? Über diese Frage und damit auch die Rechte und Pflichten von Product Ownership spricht Peter „Pit“ Beck von Das Scrum Team mit Oliver in dieser Folge unseres Podcast. Pit erklärt Ownership mit der „Fähigkeit, den Besitz zu verwalten“. Also sollte ein Scrum Product Owner die Interessen des Besitzes wahren und im Sinne der Eigentümer handeln. Leider sind wir von diesem Verständnis in großen Organisationen und Konzernen meistens sehr weit entfernt. Rückhalt für POs aus der unternehmerischen Führung heraus ist eher in kleinen Unternehmen und Startups zu finden. Oliver und Pit diskutieren, wie weit die Ownership sinnvollerweise ausgestaltest sein sollte, damit der Product Owner auch wirklich erfolgreich sein kann. Einen weiteren Schwerpunkt legen die beiden auf Haltung und Fähigkeiten, die es braucht, um unternehmerisch tätig zu werden und das unternehmerische Denken auch ins Team zu bekommen. Diese Verantwortung muss man aber auch aushalten können. Denn Ownership verpflichtet. Mit dem „Eigentum“ kommen Macht und Verpflichtung. Product Owner haben also besondere Rechte und Pflichten. Daher sollte auch jede(r) selber eine bewusste Entscheidung treffen, ob man für die Übernahme bereit ist und diese auch will. Neben Tipps & Tricks reflektieren Pit und Oliver, wie es gelingen kann, mehr Product Owner mit wirklicher Ownership entwickeln zu können.

Zum Jahreswechsel werfen wir zu Dritt mal einen Blick nach vorne und schauen uns unseren Wunschzettel an. Welches sind unsere Wünsche für 2022? Na, gut - nicht irgendwelche Wünsche, sondern explizit aus dem Kontext von Product Ownern. Oliver Winter, Dominique Winter und Tim Klein haben jeweils drei eigene Wünsche in den Ring geworfen und auf einen gemeinsamen zehnten Wunsch konnten wir uns dann auch noch einigen… Entstanden ist ein interessantes Gespräch mit einem bunten Reigen von wichtigen Themen zur aktuellen Situation und Rolle von Product Ownern. Durch das Gespräch gibt es kompakte Impulse und Hinweise, wo auch ihr in eurem organisatorischen Umfeld mal hingucken könntet. Vielleicht könnt ihr einzelne Produktwerker Wünsche für 2022 dann ja bereits bei euch in der Wirklichkeit erfüllen. Unsere 10 Wünsche für 2022: 1.) Scrum nur dort einsetzen, wo Scrum auch hingehört 2.) Cross-funktionale Teams über die Softwareentwicklung hinaus etablieren 3.) Klarheit, dass "SAFe Product Owner" ungleich "Scrum Product Owner" ist 4.) Integration von Product Discovery in Scrum 5.) "Erlebnisse" als Outcome der Produktentwicklung etablieren 6.) Mehr Fokus auf Produktmanagement in Scrum Product Owner Trainings 7.) Echte Product Roadmaps! 8.) Mut, auch unpopuläre aber wichtige Entscheidungen zu treffen 9.) Mehr "JA" sagen, anstatt so viel "NEIN" sagen zu müssen 10.) Mehr Zeit für die eigene Weiterentwicklung als Product Owner nehmen Im Laufe des Gesprächs nennen Tim, Dominique und Oliver folgende Bücher bzw. Artikel: - Marty Cagan: Empowered (im Kontext der "Empowered Product Teams") - Roman Pichler - Six Types of "Product" Owners - Marty Cagan: The Four Big Risks - Teresa Torres: Continuous Discovery Habits - Jeff Patton / Jeff Gothelf: Dual Track Development - Nacho Bassino: Product Direction - C. Todd Lombardo et al.: Product Roadmaps Relaunched - Robbin Schuurman / Willem Vermaak: 50 Arten, Nein zu sagen Zudem wurde auf die beiden folgenden Podcast-Episoden verwiesen: - Verantwortung übernehmen als Product Owner (mit Andy Schliep) - Sei Dein eigenes Produkt! Und am Ende empfiehlt Tim als Content-Quelle für die eigene Weiterentwicklung unsere recht neue "Produktwerker Box" (im Menü zu finden oder direkt unter https://produktwerker.de/box/) Wir würden uns auch echt freuen zu hören, was Eure Wünsche für 2022 denn so sind! Alles nur "weiter so"? Oder woran wollt ihr etwas verändern, z.B. an der Organisation und en Rahmenbedingungen arbeiten? Und worin wollt ihr euch selbst weiterentwickeln? Wenn euch die Folge gefallen hat würden wir uns über Feedback freuen - v.a. in Spotify, in Apple Podcast oder der von euch genutzten Podcast-App sowie als Kommentar in unserem Blog-Post auf der Website.

What Does a Scrum Product Owner Do All Day? Let's explore the options this situation presents. All of this and more are discussed in today's episode of Your Daily Scrum with Todd Miller and Ryan Ripley. What do you think? Let us know in the comments! Take a Professional  Scrum with Kanban Course with Todd, Ryan, and Daniel Vacanti! https://www.eventbrite.com/e/professional-scrum-with-kanban-psk-online-certification-class-psk-i-tickets-167900832911 Buy Fixing Your Scrum: Practical Solutions to Common Scrum Problems -  https://amzn.to/3fMpH5a Join Ryan and Todd in a Professional Scrum Master course:  https://www.scrum.org/agile-humans And make sure you subscribe to the channel! DISCLAIMER: Links included in this description might be affiliate links. If you purchase a product or service with the links that I provide, I may receive a small commission. There is no additional charge for you! Thank you for supporting the channel so we can continue to provide you with free content each week! FTC DISCLAIMER: This video is not sponsored by anyone. Sharing Scrum knowledge to help you grow as a Scrum Practitioner and to solve complex problems. #scrum #agile #scrummaster See omnystudio.com/listener for privacy information.

What Does a Scrum Product Owner Do All Day? Let's explore the options this situation presents. All of this and more are discussed in today's episode of Your Daily Scrum with Todd Miller and Ryan Ripley. What do you think? Let us know in the comments! Take a Professional Scrum with Kanban Course with Todd, Ryan, and Daniel Vacanti! https://www.eventbrite.com/e/professional-scrum-with-kanban-psk-online-certification-class-psk-i-tickets-167900832911 Buy Fixing Your Scrum: Practical Solutions to Common Scrum Problems - https://amzn.to/3fMpH5a Join Ryan and Todd in a Professional Scrum Master course: https://www.scrum.org/agile-humans DISCLAIMER: Links included in this description might be affiliate links. If you purchase a product or service with the links that I provide, I may receive a small commission. There is no additional charge for you! Thank you for supporting the channel so we can continue to provide you with free content each week! FTC DISCLAIMER: This video is not sponsored by anyone. Sharing Scrum knowledge to help you grow as a Scrum Practitioner and to solve complex problems. #scrum #agile #scrummasterSee omnystudio.com/listener for privacy information.

Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Critical behaviors great PO's exhibit Great Product Owners are able to help the teams focus on the impact (and outcomes) of their work. Gonçalo shares a tip to define outcomes in a way that is easy to understand for the team and the stakeholders. We also talk about some specific behaviors that great PO's have in relation to the team. The Bad Product Owner: The “doer” PO and its anti-patterns This particular PO had a background as a Project Manager. That led him to focus on controlling the team's work and tasks, rather than the evolution and impact of the product. When PO's focus more on “delivering” and less on “impact”, this may lead to the team losing sight of the customer and their needs.  Are you having trouble helping the teamwork well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate. About Gonçalo Valverde Gonçalo is an Agile Coach from Portugal working with teams and organizations in their continuous improvement journey. As a keen amateur photographer, he learned that less is more and how constraints help one focus on the outcomes. He's also a co-organizer of Agile Coach Camp Portugal.  You can link with Gonçalo Valverde on LinkedIn and connect with Gonçalo Valverde on Twitter.

Diane H. Leonard, GPC, STSI | https://www.dhleonardconsulting.com/ (dhleonardconsulting.com) Diane is a Grant Professional Certified (GPC) and Approved Trainer of the Grant Professionals Association. Diane has recently become a Certified Virtual Presenter through https://www.espeakers.com/marketplace/speaker/profile/27305/diane-h-leonard-gpc-lst (espeakers). She is also a Scrum Trainer by Scrum Inc, Scrum Master by Scrum Inc, and Scrum Product Owner by Scrum Inc. credentialed by the Agile Education Program powered by Scrum Inc.™ Since 2006, Diane and her team have secured more than $86 million dollars in competitive grant awards for the clients of DH Leonard Consulting & Grant Writing Services. She is an active member of the Grant Professionals Association. She is a graduate of Cornell University in Ithaca, New York, with a Bachelor's of Science in Industrial and Labor Relations.  When not working with her team on grant applications for clients, Diane can be found in the 1000 Islands, out for a run, or drinking a strong cup of coffee. https://resources.foundant.com/education-webinars-for-grantseekers/being-an-agile-leader-in-your-nonprofit-regardless-of-your-title (Being an Agile Leader webinar ) https://resources.foundant.com/education-webinars-for-grantseekers/you-are-not-alone-burnout-is-real-relevant-and-recoverable (Webinar on preventing burnout) https://www.amazon.com/Happy-Healthy-Nonprofit-Strategies-without/dp/1119251117 (Healthy Happy Nonprofits book) https://info.foundant.com/2021-10-08AgileinNonprofitsSummit_RegistrationLP.html (Upcoming Agile Summit) Agile Blogs from DH Leonard Consulting & Grant Writing Services DH Leonard's Agile in Nonprofits website https://www.amazon.com/Scrum-audiobook/dp/B00NHZ6PPE/ref=sr_1_2?dchild=1&gclid=CjwKCAjw7rWKBhAtEiwAJ3CWLIPVTwqaFkLUPFSwYZZ5G7LbCSnw0uu781ESZGXxm3iykxAXaNwjcBoCC1cQAvD_BwE&hvadid=241618947090&hvdev=c&hvlocphy=9021324&hvnetw=g&hvqmt=e&hvrand=18386138660889644940&hvtargid=kwd-333795142695&hydadcr=22597_10356339&keywords=scrum+the+art+of+doing+twice+the+work&qid=1632499702&sr=8-2 (Scrum: The Art of Doing Twice the Work in Half the Time) Contact Info: Twitter: @innonprofits  Facebook: https://www.facebook.com/agileinnonprofits/ (Agile in Nonprofits) Diane'st email: diane@dhleonardconsulting.com  Want to see additional resources? https://resources.foundant.com/ (Visit resources.foundant.com) https://www.foundant.com/events/nonprofits/ (Register for a webinar) and your question might be heard in a future episode! Brought to you by Foundant Technologies.

If you're someone who is comfortable with the “business side” of projects, you are probably the right person to aspire to achieve a #Certified #Scrum #Product #Owner® (#CSPO®) #certification. While the #Certified #Scrum Master® (#CSM®) helps the #Scrum Team work together to learn and implement #Scrum, as a #CSPO, you create the product vision, order the Product Backlog, and make sure the best possible job is done to delight the customer. Benefits of a #Certified #Scrum #Product #Owner certification: Expand your career opportunities across all industry sectors adopting #Agile practices Demonstrate your attainment of core #Scrum knowledge Learn the foundation of #Scrum and the scope of the #Product #Owner role Engage with #Agile practitioners committed to continuous improvement In addition to fulfilling the role of #Product #Owner on a #Scrum Team, your #CSPO #certification gives you an initial two-year membership with #Scrum Alliance®. Join local user groups and online social networks, gain access to deep discounts on Gatherings, and more. REQUIREMENTS Attend an in-person, 16-hour course taught by a #Certified #Scrum #Trainer® (#CST®). After successfully completing the course, you will be asked to accept the #CSPO License Agreement and complete your #Scrum Alliance membership profile. #scrumorg #agile #scrummaster #scrum #productowner #scrumalliance #productmanagement #psm #agilecoach #scaledagileframework #devops #scrumtraining #productmanager #itbusinessanalyst #businessanalyst #agileproblems #itbusinessowner #developmentteam #scrumteam #agileprocess #scrummasters #scrumdotorg #agil #certificacaoscrum #retrospectivas #teambuilding #agiledevelopment --- Send in a voice message: https://anchor.fm/aleph-global-scrum-team/message

Being a professional #Product #Owner encompasses more than writing requirements or managing a Product Backlog. Product Owners need to have a concrete understanding of all product management aspects, including but not limited to product ownership, that drive value from their products. #Professional #Scrum #Product #Owner (PSPO) is a 2-day course that focuses on all of these areas to teach students how to maximize the value of products and systems. #PSPO is the cutting-edge course for Product Owners, #Agile product managers, and anyone responsible for a product's success in the #market. In this course, students will develop and solidify their knowledge of being a #Product #Owner through instruction and team-based exercises. The breadth of the role's responsibilities in delivering a successful product will become more clear from an #Agile perspective. Metrics are identified to track the creation of value and the successful delivery of the product to the #marketplace. The course also includes a free attempt at the globally recognized #Professional #Scrum #Product #Owner I #certification exam (#PSPO I). What You Will Learn Over the 2 days, students will develop and solidify their knowledge of being a #Product #Owner through instruction and team-based exercises. The breadth of the role's responsibilities in delivering a successful product will become more clear from an #Agile perspective. Metrics are identified to track the creation of value and the successful delivery of the product to the marketplace. The #PSPO course is much more than just a set of slides and an instructor. In this course, students work on real-life cases with other classmates together as a team. This course is made up of discussions and hands-on exercises. #scrumorg #agile #scrummaster #scrum #productowner #scrumalliance #productmanagement #psm #agilecoach #scaledagileframework #devops #scrumtraining #productmanager #itbusinessanalyst #businessanalyst #agileproblems #itbusinessowner #developmentteam #scrumteam #agileprocess #scrummasters #scrumdotorg #agil #certificacaoscrum #retrospectivas #teambuilding #agiledevelopment --- Send in a voice message: https://anchor.fm/aleph-global-scrum-team/message

Episode Summary: In this episode, Raymond and I explore: If it's possible for organisations to be 100% agile, Why a human-centred approach to product design is key How one can get started with their agile journey... and much more.   Guest Bio: Raymond Chike has over 15 years diversified experience in the Financial, Retail, Utilities, Energy, Consulting and Charity sectors. Proven record as a problem solver and aggressive commitment to continuous learning. Bringing together Human, Digital and Physical Interactions while enjoy working with businesses create innovative solutions, products and services. By recognising customer needs, validating new product and service concepts, assisting teams in developing mvp, and assisting organisations in transitioning to adopting new ways of working in a holistic human-centric way.   Raymond's Social Media: LinkedIn: https://www.linkedin.com/in/chykeray/   Design Thinking Squad Meetup https://www.meetup.com/Design-Thinking-Squad-Gloucestershire/   URLs and Resources Mentioned Books/ Articles: User Story Mapping by Jeff Patton The Startup Way by Eric Reis Lean Startup by Eric Reis Lean UX: Designing Great Products with Agile Teams by Jeff Gothelf and Josh Seiden Lean UX: Applying Lean Principles to Improve User Experience by Jeff Gothelf and Josh Seiden Impact Mapping by Gojko Adzic Raymond's LinkedIn post on relationship between Design Thinking, Lean and Agile: https://www.linkedin.com/feed/update/activity:6505691705440894976/   Interview Transcript  Ula: 00:26 Hey everyone! How are you doing today? Can you believe it? We're nearly at the end of Season 1 of the Agile Innovation Leaders podcast and this is our 9th episode. A massive thank you and shout out to all of you who have taken the time to listen, support, to write, to encourage… I am very, very grateful. It never ceases to amaze me that you guys are listening from all over the world; from places and countries like New Zealand, Australia, Singapore, India, Nigeria, Kenya, Ghana, France, South Africa, Canada, USA, Brazil, Switzerland, Norway… of course United Kingdom where we live and many other places where I've not mentioned. I do appreciate the engagement – thank you so much. Keep it coming and keep getting in touch. Now, in the course of launching the podcast, I've also had a number of you get in touch with me to say, ‘Hey, we really are interested in this ‘Agile' thing. How can we learn more about it? How do we get started?' And for some of you, you've had some sort of Agile initiatives going on in your organization and you don't know how you can make this better, make it work because it's not working as well as it should. Well, if you fall into any of these categories, today's episode is for you. I'm pleased to introduce my guest. He is nobody else other than Raymond Chike. A seasoned Agile Innovation professional with over 15 years of diversified experience in multiple sectors – Financial, Retail, Utilities, Energy, Consulting and Charity. And he is a big proponent of design thinking and basically blending agile, lean start up thinking, UX design and design thinking to provide a rounded and human-centered way of working. You just have to listen to this episode! So without further ado, my conversation with Raymond. Enjoy! Ula: 03:04 Raymond, thanks for making the time for this conversation. It's great to have you on the show. Raymond: 03:09 You're welcome. I'm excited as well Ula: 03:11 Great. Now let's kick off. We want to know who Raymond is as an individual. Can you tell us a bit about yourself, and how your life experience has led you to choosing a career as an agile professional? Raymond: 03:25 My story is one of those I'm passionate about telling people. So, I'm a native of Nigeria, back in Africa. And I think the whole journey started off as me looking at the whole world in perspective. And I thought to myself, I want to see how things get done in the Western world – United Kingdom and America and all that. That led me to journey into the UK. So, on coming here, I found my first contract was more of an IT security administrators service contract or something like that. And along the line, I started noticing that I was good at connecting the business and the technology. Little did I know that that was what business analysis was. Then, business analysis became popular, but already I'd found out I was naturally a Business Analyst. But then I thought, ‘Okay, let's go on that journey.' And while in the journey of a Business Analyst, I started realizing that things took too long to happen. So, people are building (a) project and before the project finishes, in two years, the world has moved on. And I said, what is the best way of doing things quicker. I mean, that was where agile started coming up in my mentality. Then I thought, ‘Alright, I think I've got an agile mindset as well.' So, I think I'll take a perspective from a natural point. So, professionally, that's how I found my way/ journey into the Agile world. I live in the UK, permanently now for 14 years, 15 years or so. I've got (a) family, as well. So, my primary location is around Southwest of Cheltenham, but most of my consultancy has been around London, and I travel around anyway. I think. Yeah, that's me in a nutshell, and that's my passion. And, then yeah. Ula: 05:11 That's quite an interesting story. It's funny, because we all start off one way, but the thing about us as humans is that there are things about yourself, you know, your natural inclinations or giftings, or things you're really good at, you wouldn't know until you actually get started. So, it's interesting you recognised the knack (i.e. abilities) and probably people around you also recognise the knack whilst working as an IT Security Specialist, that you also had the ability to connect business with technology. Just out of curiosity, what was your educational background? Raymond: 05:46 Yeah, I graduated with a first degree in Electrical/ Electronics Engineering. Ula: 05:50 Oh, okay. Raymond: 05:51 And… yeah, that is me really. I haven't furthered anyway in terms of educational academia. I've surrounded myself with lots of training and certifications… I've gone, I mean… I don't know if I have enough time to start to name them. But, that's my educational background anyway. Ula: 06:11 I mean, education is not necessarily having more degrees or as many degrees as a thermometer. I'm also Nigerian and I also got my first degree - funnily also in Electronic Engineering. Raymond: 06: 21 Really? Ula: 06:22 Yeah, yeah. Raymond: 06:23 What a coincidence! Ula: 06:26 From your profile, I can see that you are quite big on marrying agile thinking with lean, UX design and design thinking. I'm a big fan of that, because it's really about focusing on what value you're bringing to the customer, whether it's internal or external, and ruthlessly eliminating anything that the customer does not value and is not willing to pay for. So, what are your thoughts on marrying design thinking with lean methodologies? Raymond: 06:56 My thoughts are certain in the sense that it must be married. Looking at the world we live in now, (we're) in an adaptive world. I think the most important service to me is customer service. At the heart of every product, at the heart of everything we do, if we can't link it to customer service, then we just building what we think we like, yeah? And before you can build something for a customer, I always look at it in this perspective, you have to design that thing, you have to then build it, and you have to engage with the people to use the product. And that's the heart of Human Centered Design, or rather you can call it Customer Centric way of doing something. So, that is me thinking about how you bring together the human perspective, and link it with the digital and the physical interaction. Now, this is where you need to combine a whole lot of techniques and thinking and I always say it this way, ‘Agile is not a way of working, agile is a way of thinking than the way working.' Because your behavior modification cannot change if your mind is not transformed. So, at the center and the heart of agile, is the thinking. The same applies to design; at the center and heart of design is thinking - Design Thinking, Agile Thinking. So, call it this way: Design Thinking, Lean Thinking, and Agile Thinking. And to marry them is - Design Thinking makes you get to the heart of the customer. Like, ‘What is the problem you're about to solve? What is the pain point? Empathy. What is this? Why are we doing this thing? What is the problem? The pain point; you empathise with the customer. Now, at that point of empathy - this is where you begin to think about Lean. Where Lean thinks, ‘All right, I think I've empathised (with) this problem and I understand this thing – I feel I understand it.' Then, what's the barest minimum I can test to see it's working? This is where Lean Thinking comes in, right? So, then when you use the Lean Thinking and it works or you get good feedback (you say), ‘Okay, okay. I think we now see a way this is gonna work.'  ‘Okay, let's produce it in some sort of scale now and still get feedback and learn.' This is where you now bring in the principles on Agile, like the Scrum, and the Kanban, or the Extreme Programming, or SAFe (Scaled Agile Framework). Then you now want to say, ‘Okay, this thing is getting bigger now; we're about to blow up now', so you want to scale. You scale the product, you engage with the people, then you might… So this is the journey of a product from its inception of human-centric pain point up to the development, and this is how I marry Design Thinking, Lean Thinking and Agile Thinking. Ula: 09:41 Wow, (I've) never really heard it put this way. But it does make sense and I do agree. So, would you say that Design Thinking is the same thing as User Experience design? Raymond: 09:51 It's an interesting conversation but it's not the same. But what I usually say - Design Thinking is a big umbrella. Like, you'd say, Agile thinking. So if you… Like, what you've asked me now is like, ‘Is Agile thinking the same as Scrum Master?' It's like, ‘Oh no, Scrum Master sits under Agile.' That's the same question. Design Thinking involves a lot of skills. Ula: 10:16 Yes Raymond: 10:17 Now, it depends on the way you want to go with it. If you want to do a short design… bear in mind it's a (way of) thinking. Ula: 10:23 Yeah Raymond: 10:23 If you now want to bring it to reality, in terms of skill you might want to map it to, say, a researcher can be involved. A researcher... Now does that mean you cannot be a researcher? You can be (one) but in a professional office, maybe there's a (dedicated) researcher. Okay, UX design - alright, what makes you think you're not a UX designer? Okay, I want to develop an app. I can just sketch something on paper with a wireframe and I've got some understanding of UX concepts. Now, that's my minimum viable (product). Maybe I need a professional UX designer to a prototype for me. Okay, then you need a UX (designer) it might be - depends on the product. If my product is around…  (say,) building a bottle, I don't need a UX designer for a bottle. I might just go get a fabricator to make a bottle, you see what I mean? So regardless of the product, the principles stand. But when you talk about the product you want to do maybe a web design, then the skill set comes into play. That is why the UX design now is a skill. Yeah, that's a connection. So, it's like Agile - is Agile the same as… product owner? No, within agile umbrella, we might need a product owner, we will need a scrum master. Okay, maybe we don't need an engineer really. Okay, okay. While you're developing an agile product, what if the product is a pharmaceutical product? Do you need a developer? No, you need the scientist. So, you see the point. So, the takeaway, because when we talk about Lean agile, people just focus straight ‘Oh! (We're building a) website, app?' Ula: 11:49 Software development… Raymond: 11:50 But… it's not about websites. It's not about apps, not about it. What if it is a pharmaceutical company developing a prosthetic leg or pharmaceutical company developing a fake eyeball, what do you say then, you know? So, I try to get people away from products first, think about the human-centric way of connecting digital and physical interaction, then I think everything will fit into place. Ula: 12:15 It's interesting how you've highlighted the fact that there are general principles underpinning Agile thinking or Design thinking and the principles are separate from the products. Now the products could vary, the principles remain pretty much the same. But now depends on the context - which you can now adapt it (the principles) to the context of the product or service probably that you're providing to the end user or the customer. Am I right? Raymond: 12:44 That's right, well-articulated. Ula: 12:47 Okay, well, thanks. That's interesting. You said that there is this misconception that agile is about the things people do. Now, based on what you're saying that agile is first a mindset so and the International Consortium for Agile, or the ICAgile organization, they said on their website, it's about first being agile, before you do agile. Raymond: 13:11 That's right. Ula: 13:12 So, what would you say are the steps then, towards being agile and when would you know that you are truly agile from a ‘being' standpoint? Raymond: 13:24 Okay, I think the best way to say (it is) this way: there is nobody that's 100% agile. Ula: 13:30 Hmm! Interesting. Yeah. Raymond: 15:31 Definitely, nobody, nobody. Because why I say that is, if you are 100% agile, it's like… if you say yes, I am 100% agile, it does not marry up with the name agile itself, because agile itself means changing. So, you say you're 100% changing. So, I am 100% changing, so you're still changing. So, what agile, what I try to say about agile is (it's) about how we're learning that's Agile. So, (it) automatically tells you, you are constantly learning. So, have you learnt? No, you are constantly learning. So, the thing at the core of Agile is a mindset, your mind has to be ready. That's the height of it is your mindset knows that things must change. The principles and the values lie within and the practices follow and the tools and processes that help it. So, but you need to get at the heart of it that it… So basically, the world, is ruled by companies who learn faster. That's it. So, how are you learning faster? That's why agile comes in. So, are you… if Facebook comes tomorrow and said, ‘We are now agile; we are the best agile (practitioners)', that's wrong, because they're still going to have challenges that come up tomorrow that they'd have to think and say, ‘Guys, what's the next solution here?' Ula: 14:46 True Raymond: 14:46 This is where I feel agile is just, agile in itself is even a part of a product. As I've just explained Lean, design thinking, lean and agile… all that stuff. So, it's a complete mindset shift. But we there yet? We're not always going to be there in terms of 100%. But we are on a journey. Ula: 15:06 Yeah Raymond: 15:06 So, we're on a journey… we're not definitely going to be ‘there'. So, to answer your question, I don't think anybody's 100% agile. But I guess the thing is, to what degree of Agile are you? To what degree of learning or what degree of flexibility? What degree do you apply the principles better? I think that's the key message. And I mean, the only way to answer that is more of your outcomes, really? So, when you check into your outcomes, you know if you are really, truly agile and how responsive you are to the market and how adaptive you are. Ula: 15:41 Well put. So you said, yes, no one is 100% agile. You're constantly learning and that's probably why agile and lean - they're complimentary because lean is also about continuous improvements and focusing on improving processes to achieve certain goals. What would you say about the frameworks then? Is it possible to purely apply one framework in an organization's operating context, to the exclusion of others? Raymond: 16:13 Great question. I think you will do yourself a favor to mix them up. I always tell people this … if you study Scrum, the next thing… they (people in organisations) call me and say, ‘I'm doing Scrum', (and the person) goes on saying ‘I'm writing user stories.' And I say, ‘Okay, but I'm sorry, user story is Extreme Programming. So, you're already mixing it up, right? Then you get people who are doing Scrum. Then they go, ‘Oh, our Jira board is a Scrumban board.' So, what's that about? Ula: 16:41 It's a Kanban board… yeah… Raymond: 16:42 So, what I tell people is this: I'm not dogmatic about any (framework). If you bring any framework tomorrow and call it… ‘Jump' … whatever you want to call it. My question to you (would be), ‘Is it solving human problems? Are we inspecting and adapting faster? Is it prioritizing collaboration over ‘blah'…? Is it prioritizing responding to change over following a plan? Is it tied to the principle?' (If the answer is) ‘Yes', that's it! I don't want to know what else you call the name. I mean, I was in a conference the other day and I said to someone, ‘Look, let's be honest.' (If) she goes to Facebook now, (and) I go to Netflix (and) ask them what (agile framework/ methodology) they're following, they probably would not tell you anything. Probably tell you, ‘I don't know what's Scrum - we just inspect and adapt quickly. We just learn fast. We have a system that helps us learn fast.' That's it. No one is gonna tell you, ‘Do three weeks sprint, do four weeks sprint… do one thing or the other…' It depends on the product. Depends on the product. Some people do one-week sprint. Some companies do one-week sprint, two weeks sprint, three weeks sprint. Some pharmaceutical companies do one-week experimentation. I've seen companies do design sprint zero, then go on and do one-week sprint. The thing is, where are you learning fast? How are you learning fast? And agile is just (a means to) the end game; it's the building of the product. Remember, I said design thinking? Where is the place (for empathy in Agile)? …No agile principle talks about empathy. Nothing like that. Ula: 18:05 No Raymond: 18:06 They (some agile frameworks) just tell you, ‘Sprint planning - boom, boom, boom, go!' But, how do I know the product to build? I mean, this was what inspired me to (write) my last post where I said… I did post something on LinkedIn the other day. (That's one of) the key things that I was trying to say to the team. I read that from a book called The Startup Way by Eric Ries. This is the same guy who … Eric Ries is The Lean Startup guy. So, here is Toyota (for example). Toyota known for all the things they do around production and lean and all that stuff. But yet someone in Toyota could say he thinks there's a missing part. And that is because they are good at creating things. But they don't have a system that tells them on (how to) discover what to produce. Scrum does not help you discover what to produce, you know… Kanban does not help you discover what to produce. They just help you produce but they don't help you discover. So, this is why I say, I'm not precious about any framework, as long as that framework can help me easily inspect and adapt. That is my key (requirement)… and it's transparent. That's my own, I don't really cherish… I'm not gonna say I'm a SAFe man (or it) must be SAFe. (Nor would I say) it must be Scrum, or it must be Kanban. But then, does it mean I haven't gone on training for all of them? I have – I'm not hung up on frameworks. (I've gone on training for every one of them) because I want to know what I'm talking about. I want to learn because I'm also an aggressive learner. So, I want to know what you're talking about. But then I always ask myself the question, what is the “why” you're doing this? Why are you doing it? If it connects with (the agile) principles – yes. If it doesn't… hmmm… I'll pick and choose what I want from it and throw the rest away. As simple as that. That's my view on all frameworks, really. Ula: 19:48 Makes perfect sense, actually. Raymond: 19:51 You don't want to be hung up around frameworks really. Going into this conversation the other day, someone talked about (the) product owner (role) and I said, ‘Listen, I've done a Product Owner course for Scrum. And that is not up to 2% of what it takes to be a Product Manager.' It's not! If you think you've done a Scrum course, on product ownership, and you think you are now a product owner? I'm sorry, it's not (the case). Because the Product Management (responsibility) is a big piece - from design, to engagement, to development. So, there you have several of those sideline courses, you have to go to; to understand the market, to understand the proposition, to understand business model presentation, Lean Canvas…, then, you know what I mean? Where goes all the certifications and frameworks again? It's all about just learning. Just see it all as learning; adding that to your toolbox. You know, focus on the human-centric problem you want to solve. Ula: 20:44 I quite resonate with what you said. As in likening these frameworks, the concepts - to look at them as tools in a toolbox. You pick the one that most appropriately suits the work and the organization you are in - in my opinion. I'd like to know what you think about this. But I also think it is possible that a team, an organization you know, or even within a project, it could evolve in such a way that the tools that you're using… or the practices and the tools and processes that you're using to try to accomplish an outcome might need to change midway. So, it doesn't necessarily mean that what you start with is what you end with at the end of the project. What do you think about that? Raymond: 21:30 Yes, I mean, it is. I've worked with several big companies trying to do agile or are doing agile. I've seen it. I've got the scars on my back. I know what I'm am saying. It's very painful when you see people who want to fix it (an ill-fitting framework) into their hole. I say to them, ‘You have to be pragmatic.' Like this consultant… I don't remember his name again. But he said, ‘Agile has a way of making people drop their smart brains at home and come to work.'  If you come to work, (that) you do agile doesn't mean you're not smart - you're smart. Just know that you're smart. Look around the process, see how it's going to work well for you. If it's not working, find another way it's going to work. Remember, the principles still apply. Keep the principles at your forefront. We're talking real stuff here, yeah? So how do we make Kanban work for us? How do we make Scrum work for us? Okay, yes. Okay. How do we draw funds, investment? Because we need seed funding to do this experiment and prove to our manager it works. Okay, you want to start up something now? You're starting small? You're (i.e. Ula is, for example) not going out now opening an office and buying a podcast device of 10 grand or 20 grands? You're being lean here; trying to make sure you're experimenting here, right? Ula: 22:39 Exactly, you have to know if someone wants… Raymond: 22:41 You (Ula) are applying the same principles. You've got the mindset; you've got the mindset. That why you're doing what you're doing right now. And it's the same principle applied at a scale. Ula: 22:49 Thanks! You mentioned something that you've had scars on your back as a contractor working with teams and organizations. Is there any one you wish to share? Raymond: 22:58 I think for me, the behavior is the same. What I can say is, every company wants to be agile; that's the market drive - just get that right. Every company wants to be agile. In fact, you can almost sell anything to any company now in the name of Agile. Ula: 23:12 It's a buzzword, right? Raymond: 23:14 Yes. But then I always say this, ‘If I get in there, how can I add value to you?' So, you get in there, you stumble on arguments. Now one coach prefers SAFe (Scaled Agile Framework), another Coach tell you Scrum, another coach tells you Kanban is the way. Then I always challenge them by saying… When I come in with design thinking mentality, they look at me like, ‘where does this guy come from? Who are you? We are agile.' I say, ‘yes, but how do you draw funds from the manager to tell him you're agile?' They'll say ‘Hmm! That is a Product Manager's responsibility.' I say, ‘Oh really? I thought that's still under Agile, because a  Scrum Product Owner course teaches them (i.e. the Product Managers) how to draw money? Is it a “no”? Okay'. You see, when you find that a… That's what you see in companies. I think what we need to start to understand is…  I tell people, ‘Guide yourself with mentors', experience is key as well, you know. My experience, tells me that many companies are still on the journey, and I said agile is a journey. My gauge tells me every company now knows: there's no argument we have to be agile. So, we've crossed that stage. They know that we have to be adaptive. They know that now. The challenge many companies are facing now is, ‘How?' They now know, but it's the ‘how' now. (My) advice is, based on my experience, there is no pattern. All I can say is, as long as you have these three pillars in the mindset of what you do; the design thinking, lean thinking, agile thinking… I always wrap it up by saying (you must have) almost an entrepreneurial mindset as well. Ula: 24:46 Oh yeah. Raymond: 24:47 That will help. A bit of that will very, very help (i.e. help very much). The reason why I say entrepreneurial mindset is because then you're thinking differently. You are not there sitting down in a company waiting for your salary every month and just go home. You're inspired to say, ‘What problem are we solving? What customer problem are we solving out there? How can we be fruitful?' Now you're thinking entrepreneurial. I think that drive will start to send a different message to company structures; you start inspire people to work, in fact inspire people for new products. And because people love working agile, when you put agile in any office, (for example) Kanban, people love it. Why? Because it is liberating. Ula: 25:27 It is. The transparency... Raymond: 25:28 It has that way of making… The transparency! People love it. That's the key to (the) successful companies we see these days everywhere. We don't know how they succeed. But this is the principle they've been applying years ago when it was not branded anything. Now is becoming branded, whatever we call it now. Ula: 25:44 Yeah, I mean, it's interesting… Yeah… it helps to put a name to something but it's more about not enshrining it and kind of stifling the spirit of what that thing is meant to mean (therefore) losing the value. Raymond: 26:00 Yeah, I agree with you 100%. Ula: 26:02 Now, you mentioned the book, The Startup Way and I assume that you might have read some other books. If you were to gift or recommend, say two or three more books that have greatly shaped your thinking; your agile, lean, design thinking - which ones would you recommend? Raymond: 26:21 Wow, there are key ones, I think, if you want to be different. If you want to be ‘agile- different', like I mean, set yourself apart. You need to have a hold of this set of books, you know. I would say go for The Startup Way (by Eric Ries), Lean Startup (book by Eric Ries), Lean UX, Impact Mapping by Gojko, User Story Mapping by Jeff Patton. These would get you started. Ula: 26:47 Okay Raymond: 26:48 These are books I've seen that stood the test of time when it comes to this whole ‘game' of Agile. You, kind of… They will set you apart in your Agile thinking. Someone is going to be like, ‘You just became holy again in agile.' I'm telling you. With every page you read in this book, you'll probably read them again and again and you'll be wondering, ‘Where have I been in this world?' Ula: 27:11 Kind of reminds me, there are some books that I have read yet across different disciplines - although I tend to read more of business and self-improvement books. And there are some that are out there, which I'dd read quickly and I'll make a mental note to read them again at a slower pace. However, I also have a lot queued up. Raymond: 27:31 I have so many books but I buy physical books. Ula: 27:33 Yeah Raymond: 27:34 The kind of books I buy are around technology, innovation, entrepreneur… Ula: 27:38 So, there might be other professionals out there or people who want to make a headway into the lean, agile world as consultants or contractors. Now you said you came from Nigeria to the UK, so how did you get your first agile related role? Raymond: 28:00 Yeah, I think it's more of the experience first - in the four walls of the company, that's it I mean, there are two levels I call it like I do some private coaching and training for people who want to get into like a fundamental business analyst role. Then maybe progress to an agile role. But I would say, most of these things... As I said, the first thing is the mind. I always say this, it's difficult to teach you agile, (if) you don't understand Agile, it's difficult. So, I think what I tend to do is… there is a level of experience I hope you'd have experienced in the four walls of a company, deep problems. Then you can do some training or in most cases, enlightening yourself with some of these books. Read them, be sure you understand what they're saying. I always say understand why people use Agile. Don't understand Agile. Just understand why and relate it to your real world. Bring it home. Always bring it home because… How we bring it home? I tell people, look at the things you use from day to day. When you started using WhatsApp, it's not what it is now. WhatsApp started with just a message. There was no video, there was no record, there was no that whole thing. So, there were messages then later. This is agile. They were changing things, giving people what they want, changing it again, adding this, moving the colors. Now, connect Agile to your daily world. Then when you get to the company, it just starts to make sense. Because the companies you might get into, they are also as confused as you think you are. So, I guess the most important thing is passion. Get that passion in your mind. If you are agile, it would come out of your mind(set) and the way you talk, people will now know it's agile. But if you don't have it in your mind, as a project you (need to) change your mind(set). I always teach people this. Look at your life as well. You want to look for a house or a project you want to work on or you want to buy a new car. You thought you wanted to buy a Volvo. Suddenly, as you started going (car shopping), you find out that you don't like a Volvo. You decided to change it (the desired car) into Mercedes, why? Your requirements are changing even as a human - you haven't even gone a month and you've changed three decisions already. So, that is the adaptive behavior the world is (aiming) at. The system can manage it. What technique will manage this changing requirement every day, yet give the business (its desired) business outcomes, give customer, customer satisfaction. This is… my coaching to people is always (to) connect it with your day-to-day life first - make sense (of it). Then every other thing people are talking about can be reality now. Then, you can do the training, you can do the coaching, you can do the workshops, and they all begin to join dots together. I do workshops as well but then that's more… my training and workshops are more experiential. I bring case studies into the room and by time you go out, you understand what it means. Yeah, that's the way I look at it, really. Ula: 31:04 So, are these workshops public? Raymond: 31:06 At the moment, the organisations I consult with – I run them with them. But then I do them public, but that is once in a while. My plan this year is to have some public sessions, but I haven't put them in the calendar yet. I'm still trying to work out what customers want. I'm still going through a design thinking phase around it because I feel I don't want to just produce what I like; I want to see what people really want. And see where I can do something barest minimum that can help satisfy the need. So, say I'm at that stage where I'm a bit lean about it as well. But then I'm also willing to do anything on demand. If there's a certain group of people that come together and say, ‘I want to learn this thing. We're 10 of us, we are 20.' I do things like that sometimes. I did one in Cardiff last year (2018). A group of people came together - 12 of them - said they wanted to understand Business Analysis, how it links to agile and all that stuff. So, I did a bespoke material for them and I went and delivered it for a full one day. So, things like that I can do as well. But as I said, there is no one public (course) at the moment . Ula: 32:14 Okay, fantastic. Once you have finalized your calendar for some public training or workshop events, where would be the best place for (finding) this info? Raymond: 32:25 I think professionally, the best way to get me is LinkedIn. Ula: 32:27 Okay Raymond: 32:29 So, Raymond Chike, LinkedIn, that's the best way to get me professionally. Ula: 32:34 I'll put your LinkedIn profile URL in the shownotes. Raymond: 32:38 Yes. I have a meetup group in Gloucestershire called the Design Thinking Squad.   Ula: 32:43 Okay. Do you have a URL for that? Is it on Meetup? Raymond: 32:47 It's on meetup as well as, a group called Design Thinking Squad Gloucestershire. We did a Design Thinking Crash Course which is only about  2-3 hours. If I get a demand for it, I will arrange something. Ula: 32:59 So, anyone who's interested who probably is listening to this episode that wants to get in touch with you, the best would be your LinkedIn (profile). Okay. Wow, the time does fly when you're having fun. I've enjoyed the conversation. Raymond. Thank you so, so much for making the time. Raymond: 33:17 You are welcome. Ula: 33:18 Do you have any last word for the audience, before we wrap up? Raymond: 44:45 Yeah, I've enjoyed this conversation. Thank you as well for making this happen. I know it's been busy for me to really get the time around it but finally we made it work. We have been very adaptive and true to the nature of agile. I'd say to the listeners out there, keep your dreams alive. And… there's always a way around everything. Keep in touch. And, as I always say, the future belongs to those who learn faster. Ula: 33:54 Thanks a lot Raymond. Raymond: 33:56 Thank you so much.

Read the full Show Notes and search through the world’s largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, we discuss how distance, both physical and otherwise, can help build or destroy the relationship between Product Owner and the team. The Great Product Owner: The emotionally available Product Owner Great Product Owners are emotionally available to the team. That’s the first characteristic we discuss in this episode, where we also explore the role of having a Vision for the product, as well as knowing how to negotiate with stakeholders, and helping the Scrum Master protect the team from interference.  The Bad Product Owner: Physical and emotional distance, the destroyers of the Product Owner effectiveness This Product Owner was sitting 5 floors above the team (literally). He was not available for the team to ask questions or interact with. The physical distance a PO builds with their team also transforms into emotional/relationship distance and destroys the collaboration that is so critical. We share some tips on how to overcome that distance between team and Product Owner. Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate. About Wouter Gheysen Wouter is a creative generalist with a broad area of interest beyond agility, a focus on people, and working with teams. He is a coach, guide and life long learner with a keen interest in facilitation, design thinking and systemic coaching. You can link with Wouter Gheysen on LinkedIn and connect with Wouter Gheysen on Twitter.

Read the full Show Notes and search through the world’s largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The messages that the PO passes to the team are critical. Even when the PO is being a “messenger” there are different types of messages that they pass to the team. We talk about two contrasting ways to be that “messenger”, one that works, and one that doesn’t The Great Product Owner: Explaining the “why” of the User Stories When we describe a great Product Owner, we focus on how they help the team learn about the customer, and “why” they are asked to deliver certain functionality. We also discuss how great PO’s make themselves available to the team when necessary The Bad Product Owner: The “messenger” Product Owner This particular PO was acting like a “messenger”. The PO would show up to the meetings and say “we need to deliver this because this executive said so”. There was a lack of Vision or “why” that functionality was being asked for, and that lead to the team feeling disengaged. In this segment, we talk about what a Scrum Master can do in such a situation.  Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate. About Kamal Hans Kamal Hans believes people are capable of incredible things if they have the support they need. He is at his best when he gets to connect people with each other and their vision, create a structure of support, build a system to achieve their goals to accomplish bigger things than themselves. As an Agile Coach and disciplined facilitator, he has worked with global organizations like Ericsson, and Bose to name a few.  You can link with Kamal Hans on LinkedIn and connect with Kamal Hans on Twitter

Read the full Show Notes and search through the world’s largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The relationship between PO, team and stakeholders is critical. We talk about some of the anti-patterns, as well as what would a great community-building PO look like. The Great Product Owner: Growing the Product Development community as a PO Product Owners that can take advantage of the team’s ingenuity and creativity are more likely to succeed in their role! This PO would listen to the team’s ideas on what to demo, and act as the bridge between the team and the business stakeholders, effectively creating a “wider” product development team that included not only the team, but the PO and the stakeholders as well!  The Bad Product Owner: The “over-engineer all the things” PO When Product Owners try to “control” the team by dictating how they should be working on the stories, and ignoring their ideas they prevent the team from bringing in their creative input and augmenting the PO’s ideas. In this segment, we also talk about the “not enough detail” and the “over-engineer all the things” PO, who does not understand the MVP (Minimum Viable Product) mindset.  Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at: bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate. About Chris Foley Chris is a Principal Systems Design Engineer at Red Hat working in the area of Engineering Improvement. He has over 20 years of experience in software and has filled PO and ScrumMaster roles. The team, to Chris, is the essence of the whole process and the Scrum Masters role is to help optimize that. He uses his experience from the sporting world to draw parallels around how successful teams function. You can link with Chris Foley on LinkedIn and connect with Chris Foley on Twitter.

Read the full Show Notes and search through the world’s largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website. Sharing the passion for the product with the team is a great way to energize the team while sharing the Vision for the product.  In this episode, we also about how to solve the “everything is a priority” anti-pattern, even if the PO does not want to! The Great Product Owner: Sharing the passion and energizing the team This Product Owner was “an energizer bunny” for teamwork. The PO worked with the team when needed, was decisive in decision making, included the team as much as possible and had a real passion for the product. All of this brought great energy to the team. The Bad Product Owner: Resolving the “everything is a priority” anti-pattern The Product Queen, is a PO anti-pattern, where the PO wants everything, and they want it now, just like that famous Queen song. However, this anti-pattern does not stop there. This particular PO also wanted everything to be “high-priority”. You may think it is impossible for a Scrum Master to help this PO, but you are wrong. Laurens shares with us an approach that helped this PO change their approach and be very clear on priorities!  Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at: bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate. About Laurens Bonnema Laurens helps leaders create high-performance organizations by guiding them to embrace who they are. As Laurens puts it: “when leaders ignite their inner strength and capability—and lead from love—they soar beyond their expectations. That is how we create a world of work that we would want our kids to live in."  You can link with Laurens Bonnema on LinkedIn and connect with Laurens Bonnema on Twitter.

Read the full Show Notes and search through the world’s largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website. Being a PO is not only about the backlog items, it is mostly about collecting feedback and involving the right people in the product development. We talk about the 5 relationships of a Product Owner The Great Product Owner: The 5 relationships of a Product Owner Ben starts by sharing “the 5 relationships of a Product Owner”, and how great PO’s focus on building those relationships, not only on the backlog items they need to create. In this segment, we talk about a PO that spent their time learning the practices that were required to be able to work with those “5 relationships”, and help the team develop a simple initial impact map that would help them throughout the project. In this segment, we refer to the LeSS framework for scaling Agile and Scrum. The Bad Product Owner: 4 critical PO anti-patterns Ben discusses a particular anti-pattern for the Product Owner: the PO that created the backlog alone in their room, without talking to the team. We discuss how this anti-pattern leads to the team feeling they are “out of the loop”, and be disconnected from the real customer needs. In this episode, we also refer to the following anti-patterns: The PO as a requirements manager;  The PO going in between teams, not allowing them to talk to each other; The PO as the Analyst, instead of Product Owner. Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at: bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate. About Ben Maynard Ben is an experienced coach, trainer, and mentor assisting senior leaders in medium to large organizations with organizational design and the cultural repercussions.  You can link with Ben Maynard on LinkedIn and connect with Ben Maynard on Twitter.

Read the full Show Notes and search through the world’s largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website. Ben reminds us that Product Owners can sometimes focus on their work so much that they forget about the importance of interacting directly with the team. In this story, Ben shares his own experience as a struggling PO and what happened when he tried to create the backlog in isolation, without the team being involved. His intentions were good, but the way we create the backlog can make or break the product development process.  Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at: bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate. About Ben Maynard Ben is an experienced coach, trainer, and mentor assisting senior leaders in medium to large organizations with organizational design and the cultural repercussions.  You can link with Ben Maynard on LinkedIn and connect with Ben Maynard on Twitter.

Read the full Show Notes and search through the world’s largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website. How the team acts when the PO is present is a great hint about the PO’s ability to work in Scrum. We talk about two different stances, one that makes the team feel safe, and the other that uses fear instead. The Great Product Owner: Challenge the team, and accept the team’s challenges to be a better PO This Product Owner was the classic persona of a great PO, they understood the product, why it existed, and what value it brought to the customers. Furthermore, this PO was available to the team, and responsive to their needs and requests. Perhaps even more important, this PO knew how to give feedback, but help the team feel safe in those moments. In the end the dynamic created between team and PO, helped both challenge each other to be even better.  The Bad Product Owner: The absent and fearful PO When the PO is absent, things are never easy. When, on top of that, the PO scares the team into submission, the conditions are set for a disaster. In this segment, we talk about how to work with PO’s so that they understand their contribution to the team, and help the teams engage productively with the PO.  In this segment, we refer to a tool that helps Scrum Masters and PO’s talk about being available and cooperating within the schedule restrictions that invariably hit PO’s: The Prodcut Owner Sprint Checklist.   Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at: bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate.   About Jacy Ong Jacy is a big anime fan! And she has found a strong connection between sports anime and her work as a scrum master. As she puts it: "nothing feels more rewarding than to watch your teams grow and achieve goals they never thought they could possibly achieve. :)" You can link with Jacy Ong on LinkedIn.

46. The Art of Productive Screen Time, host William Glass sits down with Laura Page-Hamelin & Graeme McKay, co-founders of Artebula. Together they discuss the power of creativity and how promoting creative children lead to future innovators. From there we explore the challenges facing parents and children with the current content platforms and how Artebula is focused on promoting productive screen time by combining technology, art, and science. You’ll also learn the challenges and benefits of going from solopreneur to teampreneur and how to effectively work as a team across multiple continents. Laura Page-Hamelin is a passionate businesswoman and entrepreneur. Laura worked in the corporate world as a marketer but felt most comfortable being an entrepreneur. When her fourth child was born with a rare auto-immune disorder she decided to stay home permanently and to fund this choice she used her digital marketing talents to found a successful, boutique digital marketing agency, Social Jibber Jabber. In 2018, Laura identified a pain point in the children’s art and education market and with a five thousand dollar government grant began the foundations for what would later become Artebula Inc. Graeme McKay is the technology lead at Artebula and brings significant experience in both healthcare informatics and finance product design and development. Graeme has worked with innovative start-up companies including eFilm and Radimetrics, as well as industry leaders Bayer Healthcare and JP Morgan Chase. Graeme holds a Bachelor's degree in Applied Computing from the University of Strathclyde as well as being a certified Scrum Product Owner. Website: https://www.artebula.com LinkedIn: https://www.linkedin.com/company/artebula-inc/ __ Visit SiliconAlleyPodcast.com - Instagram: https://instagram.com/siliconalleypodcast - LinkedIn: https://linkedin.com/company/siliconalleypodcast - YouTube: https://www.youtube.com/channel/UCSF39MO5e4z1SX9tYZEhNgA Theme music is Million Voices by Brett Miller - www.brettmillerofficial.com Ostrich is a personal finance app that uses the power of positive social accountability to help you define, set, & achieve your financial goals. Sign Up for Ostrich at https://www.getostrich.com Instagram: https://instagram.com/theostrichapp LinkedIn: https://LinkedIn.com/company/theostrichapp Silicon Alley is a Financial Glass Production --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app --- Send in a voice message: https://anchor.fm/silicon-alley/message Support this podcast: https://anchor.fm/silicon-alley/support

Read the full Show Notes and search through the world’s largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website. From the control-minded PO to the PO that wanted to learn and co-create with the team. This week’s PO patterns enlighten the need for focusing on the relationship building between the PO and the team, and the PO and the Scrum Master. The Great Product Owner: The PO that wanted to run experiments Great PO’s come in many shapes and forms, in this episode, we talk about the great PO that wanted to run experiments, to learn what worked in practice. We also talk about the importance of the relationship between Scrum Master and PO, and how that partnership can drive the success of the PO and the team. The Bad Product Owner: The Control Freak There are many reasons why the PO’s may not be able to perform as needed in a Scrum environment. However, the toughest reasons or root causes for that lack of performance are often tied to the PO’s own personality. In this segment, we talk about the reasons why some PO’s can’t give up control, and how that search for control directly affects the team’s ability to perform.   Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at: bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate.   About Oskar Collin Oskar is a former software developer who became a passionate agile coach and Scrum master. He did so mainly because he was better at helping teams working together than building software. He loves experiments and questioning the status quo. He is passionate about helping teams build digital products and deliver value continuously.  You can link with Oskar Collin on LinkedIn and connect with Oskar Collin on Twitter.

Too many L&D teams still only expect their digital offering to supplement face-to-face and drive engagement as an end in itself. But that's no longer enough. The opportunity now is to influence performance and therefore results. Peter Manniche-Riber challenges himself to do this and in this episode he shares the method he uses to have a different type of conversation with stakeholders and build solutions that make the difference. KEY TAKEAWAYS Far too many people are still focused upon how learning and development can be restricted, limited and measured. The task ahead is to better educate stakeholders about true people development. Many in the L&D sector are generally anxious about actually leaving our environments in order to find out what people need. But by doing so we can better identify solutions. There is a shift from learning objectives to performance outcomes. We need to encourage discussion about what people should do differently and how we measure this, and what the impact is.  The future of development relies on listening to, and understanding, our people. We can do this by employing  in-house analysis, to find out what people are talking about, praising and unhappy with. BEST MOMENTS ‘My work is not a “tick the box” exercise. It's about people. It's about learning' ‘What do you want people to think, feel and do, on the other side of what it is you want to achieve?' ‘If you don't know what people care about, then you don't know what the solution is' ‘I haven't come across one piece of effective e-learning that made a difference' VALUABLE RESOURC ES The Learning And Development Podcast - https://podcasts.apple.com/gb/podcast/the-learning-development-podcast/id1466927523 ABOUT THE GUEST Peter is Head of Digital Learning at Novo Nordisk and an advocate of solutions that work predominantly for the learner. As a certified Scrum Product Owner, Peter mixes contemporary approaches to L&D to best fit digital solutions. Prior to his current role, Peter was Head of Learning at Kanda and Senior Learning Manager at Siemens Gamesa. You can follow and connect with Peter via: LinkedIn: https://www.linkedin.com/in/peter-manniche-riber-5565628b/  ABOUT THE HOST David James David has been a People Development professional for more than 20 years, most notably as Director of Talent, Learning & OD for The Walt Disney Company across Europe, the Middle East & Africa. As well as being the Chief Learning Strategist at Looop, David is a prominent writer and speaker on topics around modern and digital L&D as well as an active member of the CIPD L&D Advisory Board. CONTACT METHOD Twitter:  https://twitter.com/davidinlearning/ LinkedIn: https://www.linkedin.com/in/davidjameslinkedin/ Website: https://www.looop.co/ See omnystudio.com/listener for privacy information.

Scrum Institute, Scrum Framework Episode #16 has been proudly brought to you by International Scrum Institute, https://www.scrum-institute.org You can also listen Scrum Institute’s Podcast from Apple, Spotify, Castbox and Google Play. Listen to Scrum Institute Podcast on AppleListen to Scrum Institute Podcast on Google PlayListen to Scrum Institute Podcast on SpotifyListen to Scrum Institute Podcast on Listen NotesListen to Scrum Institute Podcast on Castbox What Is A Scrum Release Plan? This Might Surprise You! The goal of a release plan is to visualize highlevel planning for multiple Sprints, usually between three to twelve Sprints, or so-called Product Increments. A release plan becomes the guideline that reflects expectations from a Scrum Team about: Which features will be implemented, In what order and when these features will be implemented. The release plan also serves as a benchmark to monitor and control the progress of a project. A release plan serves as a target for actual deployments of software in IT production systems in two ways: Deployment of “Milestone Deliveries” to create business value for the client before the project is complete. These Milestone Deliveries cover a subset of client requirements agreed by the Scrum Product Owner, client, and business stakeholders,Deployment of Final Delivery, which includes all known demands and feature requests from the client and business stakeholders. Before a release plan is created, the following artifacts and information need to be taken into account: A prioritized and estimated Scrum Product Backlog,The measured velocity of the Scrum Team (The velocity is estimated, or its value should be extrapolated from the past similar projects if the Scrum Team is just forming),Success criteria imposed by clients such as schedule, scope, provided human resources allowed by the project budget). Since a Release Plan is heavily associated with the Product Backlog, the Scrum Product Owner governs and maintains the Release Plans. Depending on the demands and priorities of the clients, a release plan is created to satisfy one of these three goals: Feature-Based Release Planning/li>Date-Based Release PlanningFeature-Based and Date-Based Release Planning (The Most Typical) Feature-Based Release Planning What we know: Velocity of the Scrum Team, Features we want to deliver.What we don’t know: How long do we need to deliver these features? For Feature-Based Release Plans, the sum of user story points of requested features within a release is divided by the team velocity. That is going to reveal the number of Sprints required to complete a Milestone Delivery or Final Delivery of the product. And we make the release plan accordingly. Date-Based Release Planning What we know: Velocity of the Scrum Team, The Date we want to deliver.What we don’t know: What features can we deliver until the deadline? For Date-Based Release Plans, we multiply the team velocity by the number of Sprints we have until the release date. That is going to reveal the estimated total number of user story points the Scrum Team can deliver until the release date. And we make the release plan accordingly. Feature-Based and Date-Based Release Planning What we know: Velocity of the Scrum Team, Features we want to deliver, The Date we want to deliver these features.What we don’t know: Can the Scrum Team deliver the requested features until the given deadline? We multiply the team velocity by the number of Sprints we have until the release date. That is going to reveal the estimated total number of user story points the Scrum Team can deliver until the release date. If this number is larger than the sum of user story points of features within a release, then we’re safe. Otherwise, the velocity of the Scrum Team needs to be extended by adding extra human resources to the team. That may not be a viable option as the Scrum team could already possess 9 people, which is the upper limit of an ideal size of a Scrum Team. Then some user stories of the project need to be delivered by another Scrum Team, which is going to work with the original Scrum Team in parallel. Similar to a Scrum Product Backlog, a Release Plan is not a static plan. It will change during the whole project while we know more about the project. New, removed, modified user stories, and the respective changes of their estimates will influence the release plans as well. Therefore, the release plan should be revisited and refreshed at regular intervals.

Scrum Institute, Scrum Framework Episode #14 has been proudly brought to you by International Scrum Institute, https://www.scrum-institute.org You can also listen Scrum Institute’s Podcast from Apple, Spotify, Castbox and Google Play. Listen to Scrum Institute Podcast on AppleListen to Scrum Institute Podcast on Google PlayListen to Scrum Institute Podcast on SpotifyListen to Scrum Institute Podcast on Listen NotesListen to Scrum Institute Podcast on Castbox How To Scale The Scrum Framework (Distributed & Large Scrum Projects)? This Might Surprise You! The Scrum Framework – as described so far – works best for a single Scrum Team in one location. However, in reality, a singular Scrum Team often cannot implement a project entirely, or the team members have to spread over multiple locations. As a consequence, the number of teams has to increase with various distributed teams. In many instances, we have also been observing that those teams are distributed in geographically distant locations or continents. There are numerous reasons which motivate organizations to distribute their teams across different locations: Technical Reasons: Some knowhow to build separate components of the software are not locally available in the headquarters, Expertise Reasons: Some capabilities related to the execution of different software engineering activities are not locally available. For instance, test automation, user interface design, or integration of in-house software to the software of other vendors can require experts outside the headquarters, Size-related Reasons: The project takes more people on board to deliver it to its clients in a predefined timeline. If this is the case, then the project organization will need more members than it can conceivably fit one single Scrum Team. So the Scrum Team has to be distributed,Business-related Reasons: Use of human resources from lower-cost locations or enabling the continuity of work by using engineers from different time-zones could build a good business case. As communication is an integral part of the Scrum Framework, all Scrum Team members should pay attention to overcome the challenges to deal with working within a distributed project environment. Furthermore, all team members should have access to communication tools, including audio/video conferencing and screen sharing tools. These commonly used project management tools support teams to enable healthy and continuous communication. Those can include product backlogs, sprint backlogs, incident lists, knowledge/ news sharing tools, and so on. Project Organization: Multiple Teams The simplest way of expanding the Scrum Framework while working in a larger-scale project setup is to increase the number of teams in the same location. If multiple teams need to work together to implement a project, it is best to grow the number of teams progressively. What does this mean to you? Multiple Teams in a Single Location In most organizations, progressive growth is more manageable than launching ten different new teams in one go. The best practice is to start with a single Scrum Team. After a few successful Sprints, one or two additional Scrum Teams can join the project. Once you ensure that these multiple Scrum Teams work together well, you can keep on adding further Scrum Teams to your distributed project organization. Increasing the Number of Teams There are two typical ways of creating new Scrum Teams:You split an existing Scrum Team into multiple teams and add new Scrum Team members where and when necessary,You construct a new Scrum Team from completely different engineers who haven’t involved the project so far. Splitting an existing Scrum team has the advantage of leveraging the Scrum Team members who are already knowledgeable and who have already experienced with the ongoing project. Therefore, those new teams are usually at least at some degree productive as soon as they’re formed. The major drawback of this scenario is that the existing and fully functional Scrum Team has now been split into two teams. That could always cause some issues with the motivation of Scrum Team members. Especially if those changes are happening without an in advance announcement and justification from senior leadership, and when the team members are mentally and technically unprepared. When adding completely new teams, these already existing teams can continue with their Sprints without any interruption and extra integration effort. However, it will take longer to build up the necessary know-how and momentum to ramp-up the entirely newly formed Scrum teams. Independent from the decision on how you add new Scrum Teams to your organization bear in mind the following principles: Start with a small number of Scrum teams,Increase the number of teams gradually,Ensure the continuity of work and smooth delivery of software and business value during the times of change and growth,If there’re significant problems that hinder productivity and continuity of work, first focus on fixing them rather than the expansion with new Scrum Teams. Project Organization: Distributed Teams The major complexity of multiple teams manifests itself when the new Scrum Teams have to be distributed over various locations. Communication barriers between people, coordination difficulties of work, and misunderstandings of joint project norms across teams are only a few of many when it comes to mentioning this complexity. Multiple Teams in Multiple Locations The consequences of not addressing these challenges are severe. Companies have to count billions of dollars of wasted IT budget because of the lack of their skills in Organizational Leadership andScaled Scrum Expertise. There are four critical suggestions for you to cope with these challenges: You ensure that new Scrum Team members are trained in the Scrum Framework as a Scaled Scrum Expert,You ensure that new Scrum Team members are introduced to the project adequately, so they have a proper understanding of what they’re serving for. Not only technically but also from a professional business value point of view, so they can make decisions in their work to increase the value of their contribution,You ensure that the project norms are established. Similar to a single Scrum Team, which has its norms of how to communicate, how to plan, how to get the work done, a multiple project team organization should have its higher-level norms too. So these teams can communicate, plan, operate, solve problems, and deliver client and business value together.You ensure that the new team members do at least temporarily work together with the experienced project members. That could require remote site visits and on-the-job training. That’s totally fine and even desired. Thanks to this approach, the knowhow can be smoothly transferred, and the two-ways and personal dialog between people in different teams and locations can be established. Virtual Teams Another option of a distributed Scrum Team is having its members spread over multiple locations. Such a team is called a “Virtual Team”. The main challenge here is to ensure flawless communication among the team members. Scrum Team members must still need to conduct all Scrum Rituals (Scrum Events) to coordinate their work, but now they have to do this while not all of them are present in the same room. Virtual Teams Scrum Team members co-located in the same location should still work together in the same room. And yet, they now have to rely more on the use of collaboration and communication tools. They can join the Scrum Events from the same meeting room to connect to the other half of the virtual team via video conferencing technologies. Scrum Product Owner Team As we have covered many times in this material so far, regular communication between the Scrum Product Owner and the Scrum Team is crucial for the successful delivery of a project. We need to ensure that the Scrum Product Owner is always available to Scrum Teams located in different locations. Therefore, it is often necessary to have multiple Scrum Product Owners working together. Ideally, there is one dedicated Scrum Product Owner for each team. The Scrum Product Owners should then build a dedicated “Scrum Product Owner Team” to work together effectively. One of the Scrum Product Owners should be assigned to the role of the “Chief Scrum Product Owner”. He or she is responsible for ensuring that: The correct product is built to satisfy the demands of its client,All Scrum Product Owners collaborate efficiently, and they enable their teams to build the business and technical value for their clients. Since the Scrum Product Owner Team is responsible for the complete requirement engineering, it is beneficial to have other competencies and stakeholders in this team. Those can include the representatives of the business case, relevant stakeholders, enterprise architects, and technology architects. All Scrum Product Owners should work within a single large Scrum Product Backlog containing all stories relevant for the project. Each Scrum Team is responsible for delivering some of these user stories. And yet there will be still instances of specific user stories that require the attention and deliverables from multiple Scrum teams. Component vs Feature Teams When distributing work among different teams, we can make the teams accountable for specific software components or features. That is why we call them “Component Team” or “Feature Team.” Component Teams When using Component Teams, each team is only responsible for the implementation of dedicated components from the overall system. To finish a user story, it is usually necessary to split the user stories into smaller pieces to implement them within a single component. The dependencies between the components of these Component Teams make continuous integration an inevitable part of successful deliveries. Scrum Product Owner Team Thus, a feature cannot be usually delivered within a Sprint because its implementation depends on the deliverables from user stories of other teams. That results in increasing batch sizes and lead times of ongoing, not yet integrated work. That doesn’t sound so good, because Scrum Teams should target delivering shippable software increment in smaller batch sizes and shorter lead times. The advantage of component teams is that they make it easier to focus on and build expertise about architectural and design details of particular components. That could be massively beneficial for components that require discovery and innovation. On the other hand, the members of component teams do only specialize in individual components of the whole system. They could lose their bird-eye view and business necessity of features. Keep in mind that our clients do not compensate us to deliver components, but features with which they will execute their businesses. Without this relentless focus on features, overall optimization, and integration of software might take extra time. Since decisions of component teams tend to optimize single components, those decisions can construct invisible bottlenecks for the success and performance of the overall solution. Component Teams Feature Teams Feature teams are fully responsible for the implementation of user stories as they’re specified within the Product Backlog.The teams do no longer need to be divided for various components. Each Feature Team is responsible for delivering a fully-functional feature and a business value associated with this feature. Feature Teams Members of feature teams possess cross functional skills. They act as autonomous as it is possible to deliver fast. The advantage of feature teams is that the team maintains the system-knowledge, and this makes it easier for them to integrate their features with the rest of the system. However, for feature teams, it may become more challenging to build sufficient know-how about components. Furthermore, bringing up an autonomous feature team that can deliver fast and independently takes time as building an interdisciplinary functional team is not that easy. And yet, these are the high-performer teams which get the job done in most organizations, probably including yours. How Do We Choose Component Teams vs Feature Teams? In practice, most of the large organizations use both dedicated Component Teams and Feature teams too. Component and Feature Teams Team C, on the chart, is a Component Team. It provides planned and on-demand infrastructure services to other teams that function as Feature Teams. Team C does not directly implement end-to-end user stories per se. They deliver the requirements of the user stories committed by the Feature Teams. That allows the minimization of the number of qualified people in Feature Teams with the know-how of those components. The Scrum Master In The Distributed Project Environment In a distributed project environment, the role of the Scrum Master is even more essential. In those project configurations: There will be extra effort required to align the teams on the values of the Scrum Framework,It will take longer to establish individual team and project norms (standards) which influences numerous teams,Last but not least, there will be many impediments due to the increased number of dependencies between teams and their deliverables. One important rule to bear in mind that the Scrum Master should physically locate where his or her team is. Otherwise, it will be almost impossible for the Scrum Master: To remove the impediments for his team,To Establish their norms, andTo help them to improve their use of the Scrum Framework. The best practice is to have a Lead (Primary) Scrum Master to guide the overall use of the Scrum Framework across multiple teams. In other unit Scrum teams, which form the larger Scrum organization, someone should be acting as a local Scrum Master too.

Read the full Show Notes and search through the world’s largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website. The Product Owner role is not a simple one, so it is critical we help them understand the complete spectrum of topics the PO should be aware of. Even when the PO does not take care of all of those topics, they are critical in enabling the team by thinking about process, business and collaboration. The Great Product Owner: The full-stack Product Owner Product Owners that are able to manage their time to be present when the team needs them are sure to have a great contribution, but PO’s really excel when they are able to collaborate well with the team, and understand that reducing WIP, running-tested-software, and good communication with stakeholders are critical aspects of their role. The Bad Product Owner: The PO that didn’t care about the details When a Product Owner fails to discuss the details with the team, that leads to many possible misunderstandings and a deteriorating relationship between team and PO. In this segment, we talk about how to help PO’s go through the details enough so that the team feels confident they understand the story and are able to implement their vision. [IMAGE HERE]Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at: bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate.   About Jeffrey Koors Jeff started his studies and career as a fine artist and has gone on to use his creative thinking and vision to help many organizations find ways to design systems, solve problems and embrace Agile. Jeff is also the co-founder and host of Coaching Agile Journeys. You can link with Jeffrey Koors on LinkedIn and connect with Jeffrey Koors on Twitter.

In this episode, Professional Scrum Trainer Sam Falco addresses the question: "How do we avoid Scrum adoption pitfalls?" Last week, a student asked me what are some common pitfalls that we see when organizations shift to Scrum from a “big design upfront” process like waterfall. A big one is that they think it’s a silver bullet Adopting Scrum doesn’t solve problems overnight. It doesn’t solve problems at all! Scrum will surface the problems in your ability to deliver so that you can fix them. Too many organizations falter when Scrum runs up against an organizational impediment and “the way we’ve always done it” wins out. One example of this phenomenon is when there’s an onerous change management system that prevents code from getting into production. Scrum teams complete an increment and it sits there waiting until someone approves it to be moved to production. Sometimes, the wait is so long that multiple increments pile up. Some organizations will cling to that change management system even though it’s getting in the way. Success comes when they adapt to the new way of working. At one organization I worked with, the solution was to set up an experiment with one team working on a less risky area of code. Once they proved that they could safely put code into production without breaking things, it paved the way for broader changes to their process. Another pitfall is that the organization doesn’t really adopt Scrum  In many cases, organizations claim to adopt Scrum, but what they really do is apply Scrum terminology to existing roles and processes. I frequently see the term “Product Owner” used—or maybe I should say abused—as a new name for a Project Manager. But those Project Managers carry on pretty much the way they did before. They lack any of the accountabilities or authority of a Scrum Product Owner. They shift from using Gant charts measured in weeks to plotting out a project in Sprints over several months. And that’s another way this behavior manifests. They’ll use the name of Scrum events without understanding their underlying purpose. A Sprint lacks the focus of creating a usable increment. “Daily Scrum” is a daily status report. “Sprint Review” is a carefully orchestrated smoke-and-mirrors show with limited, if any feedback or collaboration with stakeholders. Without using all of its roles, events, and artifacts—and the rules that bind them together—you’re not using Scrum. You’re probably perpetuating your existing system. You know, the one that wasn’t working for you before. This is the realm of “Scrum, but.” And “Scrum, but” is not Scrum at all. They don’t make other necessary changes Even when an organization adopts Scrum’s mechanics, they sometimes find that Scrum doesn’t provide the benefits they hoped for. Delivery improves a little, but it soon plateaus and it’s a struggle to keep improving. That’s because other changes are necessary to really reap the gains of Scrum. A common organizational structure is to have teams organized around technical layers or components. For example, a User Interface team, a Data Access Team, a Service gateway team, and so on. Scrum requires that we produce a working increment each Sprint, which means one that’s in usable condition. Teams organized by layers or components face numerous handoffs and challenges integrating their work. There’s a loss of transparency, and they struggle to compete that working increment. The solution is to form teams that can deliver complete features that cut across all layers. Scrum doesn’t tell you to do that, but it works best if you do. Scrum also doesn’t tell you to adopt good DevOps practices, or incorporate Kanban techniques, or to refactor your code. They’re all still good ideas. Scrum is incomplete for a reason and that’s so that you can identify what works best for your organization. You have to go beyond Scrum. I talked about the pitfall of “Scrum, but,” earlier. But “Just Scrum” isn’t enough. You need “Scrum, and.” Adopting Scrum requires a shift in organizational mindset. Without that, people revert to familiar behavior, even if that behavior wasn’t effective. And adopting Scrum can’t be an endpoint. It’s the beginning of a journey of experimentation and continuous improvement. In the Trainer Talk episode “Why Does Scrum Have So Many Meetings?” a few weeks ago, I mentioned that implementing Scrum requires intentional, thoughtful organizational redesign. That’s true of implementing the basics of the framework, but it’s equally true about the wider ecosystem that Scrum teams work in. And just like I said in that earlier episode, that’s why you need a good experienced Scrum Master—and sometimes more than one—to guide your organization’s Scrum adoption. 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!

Scrum Institute, Scrum Framework Episode #13 has been proudly brought to you by International Scrum Institute, https://www.scrum-institute.org You can also listen Scrum Institute’s Podcast from Apple, Spotify, Castbox and Google Play. Listen to Scrum Institute Podcast on AppleListen to Scrum Institute Podcast on Google PlayListen to Scrum Institute Podcast on SpotifyListen to Scrum Institute Podcast on Listen NotesListen to Scrum Institute Podcast on Castbox What Is A Sprint Planning Meeting? This Might Surprise You! During the Sprint Planning Meeting, the Scrum Team builds a viable Sprint Backlog, which determines the user stories and tasks the team is going to implement until the end of this Sprint (Product Increment). A Sprint Planning Meeting constitutes two parts, namely the WHAT-Meeting, and the HOW-Meeting. As those names imply, the WHAT-Meeting focuses on the scope of a Sprint, whereas the HOW-Meeting focuses on how this scope will be implemented. During Sprint Planning Meetings, the presence of the Scrum Product Owner is mandatory. So she can answer questions from the Scrum Team and bring clarifications for the requirements and their acceptance criteria. Stakeholders such as end-users or line managers can join Sprint Planning Meetings as view-only audiences. They’re not allowed to influence the flow of the Sprint Planning Meeting. The Sprint Goal The Scrum Product Owner defines the Sprint Goal. It is a concise and realistic description of what the Sprint will attempt to achieve for business, end-users, and IT systems. The Team Capacity The total capacity of the Scrum Team might change from Sprint to Sprint. To make realistic commitments, the Scrum Team needs to know its capacity for the upcoming Sprint. The team needs to take vacations, public holidays, time spent on Scrum Rituals, and a small contingency for unforeseen issues into account to propose a reasonable capacity. The WHAT-Meeting A Sprint Planning Meeting starts with a WHAT-Meeting. It requires some preparation: The Scrum Product Owner defines the Sprint Goal.Based on this goal, the Scrum Product Owner chooses the candidate user stories for the Sprint from the Scrum Product Backlog.These user stories are edited and broken into smaller user stories when necessary so that they can be processed within one Sprint.The user stories are estimated and prioritized.The Scrum Team plans its capacity for the upcoming Sprint. The duties of various Scrum roles during the course of the WHAT-Meeting part of Sprint Planning Meetings are the following: The Product Owner introduces the Sprint goal and her preselection of requirements, which should go into the product increment.The Scrum Team identifies the required tasks and their estimations. It’s the role of the Scrum Team to decide which and how many requirements preselected by the product owner they can confidently deliver in this Sprint.The Scrum Master moderates the meeting. She ensures that the self-organization and autonomous decision-making capability of the Scrum Team remain intact. The HOW-Meeting The goal of HOW-Meeting is to fill the Sprint Backlog by identifying the concrete tasks needed to implement committed user stories for the Sprint. These tasks usually (but not limited to) include activities such as analysis, design, development, testing, software build packaging, and documentation. The HOW-Meeting can be done in a separate session after the WHAT-Meeting, or it may follow the WHAT-Meeting without a pause. After identifying the tasks to be completed, the Scrum Team estimates these tasks. The unit for this estimation can be person-hours. Based on these estimates, the team has now its baseline about how long each user story will take them to deliver. What Is A Daily Scrum/Stand-Up Meeting? This Might Surprise You! The Daily Scrum Meeting is a maximum of 15 minutes meeting.These meetings take place every working at the same time in the same place. It’s best to conduct Daily Scrum Meetings with direct access to the Sprint Backlog and Sprint Burndown Chart. So the Scrum Team can direct the Daily Scrum Meeting based on the facts and progress which are visible to everyone in the team. Daily Scrum Meeting aims to support the self-organization of the Scrum Team and identify impediments systematically. All members of the Scrum Team, the Scrum Master and the Scrum Product Owner need to join Daily Scrums. Other stakeholders can also join these meetings, but only as a view-only audience. Daily Scrum Meetings are structured in the following way. Every member of the Scrum Team answers three questions. Daily Scrum Meeting – Question #1: What activities have I performed since the last Daily Scrum Meeting? Daily Scrum Meeting – Question #2: What activities am I planning to perform until the next Daily Scrum Meeting? What is my action plan? Daily Scrum Meeting – Question #3: Did I encounter or am I expecting any impediment which may slow down or block the progress of my work? The Scrum Master has to moderate Daily Scrum Meetings. She needs to ensure disciplined and fast-pacing progress so that all team members can answer these three questions in at most 15 minutes. The goal of Daily Scrum Meetings does not include to give time-consuming decisions or solve problems. On the other hand, no issues or concerns from any Scrum Team member should be ignored or undermined due to the time constraint of the Daily Scrum Meeting. Concerns associated with specific user stories must be clearly articulated, discussed, and resolved after the meeting with the Scrum Team members related to these user stories. To align on decisions and solve problems, the Scrum team can organize separate on demand basis meetings. These separate meetings to focus on decisions or issues take usually place subsequently after Daily Scrum Meetings. The Scrum Master documents the identified impediments and its dates in a separate log, flip chart or report which is accessible to the team. We find it very beneficial to quickly update the status of all known impediments at the very end of Daily Scrum Meetings. What Is A Sprint Review Meeting? This Might Surprise You! The Sprint Review Meeting happens at the end of the Sprint.Regardless of the duration of the Sprint, it usually takes one to two hours. Depending on the type of software and available infrastructure, the Sprint Review Meetings take place in a meeting room, in a lab or in the room of the Scrum team. The goal of the Sprint Review Meeting is to review the shippable product increment built during the Sprint and bring transparency to the product development process. The Scrum Team members do not need to prepare a Powerpoint or Keynote presentation to show in the Sprint Review Meetings. They should instead spend their energy on the successful completion and demonstration of the Sprint outcome, which we call the shippable product increment. The Scrum team demonstrates its work results. The Product Owner controls whether the Scrum team delivered the requirements they had committed during the Sprint Planned Meeting accurately or not. The Sprint Review Meeting enables the Product Owner to inspect the current status of the product and adapt the goals of the subsequent Sprint. Therefore, Sprint Review Meetings are another way of formal and practical application of “inspect and adapt”. Participants of the Sprint Review Meeting are the Scrum Team, the Scrum Product Owner, the Scrum Master. Optionally all other stakeholders such as end-users, clients, business representatives can join Sprint Review Meetings. In Sprint Review Meetings, everyone is allowed to deliver their feedback about the demonstrated product increment. In this way, the Scrum team has the opportunity to get unfiltered and direct input from stakeholders for whom they’re building the software. What Is A Sprint Retrospective Meeting? This Might Surprise You! The goal of the Sprint Retrospective Meetings is to improve the teamwork of Scrum Team members and the application of the Scrum process. The Sprint Retrospective Meeting happens directly after the Sprint Review Meeting, and it closes the Sprint. Therefore, Sprint Retrospective Meetings lead to an increase in productivity, the performance of Scrum Team members, and the quality of engineered software. The Sprint Retrospective is an integral part of the “inspect and adapt” process. Without this meeting, the Scrum Team will never be able to improve its overall throughput, and they cannot focus on the improvement of team performance. Remember this: What you focus on is what becomes better! A Sprint Retrospective Meeting is virtually a mini postmortem to define improvement potentials and remove process-related obstacles. Some examples of such improvement potentials that we frequently see in our project are: Adoption of agile software development practices such as extreme programming (XP) or test-driven development (TDD), Identification of new team norms and principles, orIncreased availability of the Scrum Product Owner. Without exception, the Scrum team conducts Sprint Retrospective Meetings at the end of every Sprint. Only in this way, these meetings enable the Scrum Team to systematically adapt and improve their use of the Scrum process to the specifics of their project. What Is A Scrum Grooming (Backlog Refinement) Meeting? This Might Surprise You! Scrum Backlog Refinement (Grooming) Meetings aim to keep the Product Backlog up to date. So the Product Backlog reflects the best know-how and understanding of the Scrum team about the ongoing Scrum project. Scrum Backlog Refinement meetings can happen on-demand or scheduled basis up to two times a week, 30 minutes each session. The Scrum Team, the Scrum Product Owner, and the Scrum Master participate in these meetings. During Scrum Backlog Refinement (Grooming) meetings, the participants fine-tune the Product Backlog with the following actions: Add new user stories based on newly discovered requirements.Remove user stories which are no longer required for the product.Fine-tune estimates of user stories.Update priorities of user stories.Split giant user stories into digestible smaller user stories, and prioritize them accordingly. Here are our other suggestions to improve the outcomes of Backlog Refinement Meetings: Ensure Cross Team Participation, which means you identify the dependencies as early as it is possible, Size User Stories Correctly, which means all user stories can result in a shippable product increment within one single Sprint,Prioritize User Stories, which means you deliver immediate value to end-users, enable quick wins, and make them happy,Estimate Like a Pro, which means you obtain actionable inputs for reliable release planning,Identify Dependencies, which means you pull required teams and resources on board to make your project a success,Uncover Risks, which means you avoid tedious surprises during the later stages of your project.

Scrum Institute, Scrum Framework Episode #12 has been proudly brought to you by International Scrum Institute, https://www.scrum-institute.org You can also listen Scrum Institute’s Podcast from Apple, Spotify, Castbox and Google Play. Listen to Scrum Institute Podcast on AppleListen to Scrum Institute Podcast on Google PlayListen to Scrum Institute Podcast on SpotifyListen to Scrum Institute Podcast on Listen NotesListen to Scrum Institute Podcast on Castbox What Is A Scrum Burndown? This Might Surprise You! The “Scrum Burndown Chart” is a visual measurement tool that shows the completed work per Sprint against the projected rate of completion for the current project release. Its purpose is to enable the Scrum Product Owner, the Scrum Team, and other stakeholders to control the progress of the project. So the Scrum Team achieves to deliver the requested software solution within the desired timeline. Simple Scrum Burndown Chart The speed/rate of progress of a Scrum Team is called “Velocity”. It expresses the total number of story points completed that the Scrum Team delivers per Sprint (Iteration). An essential rule to assess and calculate the Velocity is that; Only entirely completed user stories that precisely fulfill their Definition of Done (DoD) are counted. The velocity calculation shouldn’t take partially completed user stories into account. (For instance, coding of a user story is done, but its tests are still missing) Only a few Sprints after a new Scrum Team is formed, the Velocity of the team can be reliably calculated. That helps the Scrum Product Owner to predict the throughput of the Scrum Team better, and he or she can foresee what user stories the Scrum Team can deliver in a given Sprint. That would enable the Scrum Product Owner to plan software releases more accurately, with less surprises towards business clients and end-users. As a simple example: Let’s assume the Velocity of your Scrum Team is 50 story points per Sprint. And the total amount of remaining work has been estimated as 300 story points. Then you can predict that you need 6 Sprints to deliver all of the remaining user stories from the Product Backlog. However, in reality, the user stories in the Scrum Product Backlog will change over the course of the project. New stories are added, and other stories are modified or even deleted. In the Simple Burndown Chart, the Velocity of the Scrum Team and the change of the scope cannot be visualized accurately. To increase this lost accuracy and visibility, Scrum Teams use another type of diagram, which we call “Extended Burndown Chart”. Extended Burndown Chart uses a bar chart instead of a line diagram. The size of each bar represents the total number of remaining user stories at the beginning of each sprint. The Velocity of the Scrum Team is subtracted from the top bar, while changes of the Product Backlog are presented at the bottom of the bar. Extended Burndown Chart Separating Velocity and Scope Changes To get even more accurate results with the Burndown Chart, we can also take the rate of changes in total work into account. We call this more precise model “Extended Burndown Chart With Prediction”. However, we have to be careful when using this model. The magnitude of changes in the Product Backlog will be relatively higher at the beginning. And yet, the rate of changes will usually drop, and they approach zero towards the end of the project. What Is A Scrum Burndown Report? This Might Surprise You! The Sprint Burndown Chart (Sprint Burndown Report) visualizes the progress within the Sprint towards reaching the Sprint goal. It enables transparency and actionable progress data about the actual performance (burndown rate) of the Scrum Team. That allows the Scrum Product Owner and the Scrum Team to easily monitor how the Sprint is going. Thanks to this overview delivered by the Sprint Burndown Chart, the team can predict if the Sprint goal can be accomplished until the end of the Sprint on time. Otherwise, the Scrum Master and the Scrum Team should consider and implement other measures to speed-up the execution of the remaining tasks and user stories in the Sprint Backlog. In the Sprint Burndown Chart, the initial Sprint Backlog defines the start-point for the remaining efforts. Every day the remaining effort which needs to be completed until the end of the Sprint is summed up, and it’s logged on this graph. Sprint Burndown Report/Chart It's worthwhile to remember that; While a new Scrum team is forming, the performance is often not as good as how the ideal burndown rate envisioned it. That usually happens due to wrong estimates or unforeseen impediments that have to be removed to bring the Scrum Team on full speed.

Scrum Institute, Scrum Framework Episode #11 has been proudly brought to you by International Scrum Institute, https://www.scrum-institute.org You can also listen Scrum Institute’s Podcast from Apple, Spotify, Castbox and Google Play. Listen to Scrum Institute Podcast on AppleListen to Scrum Institute Podcast on Google PlayListen to Scrum Institute Podcast on SpotifyListen to Scrum Institute Podcast on Listen NotesListen to Scrum Institute Podcast on Castbox What Is The Scrum Product Backlog? This Might Surprise You! Product Backlog (Scrum Backlog) or Scrum Product Backlog is the central element to manage all of the known requirements of a Scrum Project. It consists of all customer requirements and work results that are needed to execute and finish a successful project. As requirements, you count functional and non-functional requirements and other features related to user experience and user interface design. The Product Backlog contains feature requests and their high-level user stories. These can also include pre-requisite or complementary project requirements such as building test and development environments. Moreover, other user stories required to resolve known bugs or reduce technical debt or improve certain software features have also their places in the Product Backlog as well. Every Scrum Project has its Product Backlog. The Scrum Product Owner is responsible for the creation, maintenance, and fine-tuning of a Product Backlog. The Product Backlog doesn’t and shouldn’t answer the question of how these requirements will be developed and delivered. That’s the duty of the Scrum Team. The Scrum Team decides and documents the required tasks to address these requirements in Sprint Backlogs. Note that Product Backlog and Sprint Backlog are physically separate entities although entries in the Product Backlog drive the contents of the Sprint Backlog. The owner of the Scrum Product Backlog is the Scrum Product Owner. The Scrum Master, the Scrum Team, and other Stakeholders contribute it to build a broader list of user stories to bring the product to success. Working with a Scrum Product Backlog does not mean that the Scrum Team is not allowed to create and use other artifacts to manage work. Examples for additional artifacts could be a summary of the various user roles, workflow descriptions, user interface guidelines, storyboards, or user interface prototypes. However, note that these artifacts do not replace the Scrum Product Backlog but complement and detail its contents. he Product Backlog is a living document. Similar to how the software incrementally improves, the Product Backlog grows in time as well. The Scrum framework doesn’t require a separate change management process per se. The Scrum Product Owner creates the first versions of the Product Backlog based on his best initial understanding of the product. While the Scrum Product Owner closely observes how the product emerges from sprint to sprint and while the knowledge about client requirements augments, he or she adds, removes and fine-tines requirements in the Product Backlog. The Scrum Product Owner prioritizes requirements in the Product Backlog. The more priority an element in the Product Backlog has, the more details it should contain. So the Scrum Team can easily make sense of these high priority requirements and create the required tasks to build them. Furthermore, by using story points, the Scrum Team regularly estimates the requirements in the Product Backlog. These estimations should be fine-tuned and improved for high-priority user stories to make them ready for Sprint Planning Meetings. Each Scrum Product Backlog has specific attributes that differentiate it from a simple to-do list: A user story in the Scrum Product Backlog always add a business or technical value to its client, business owner and end-users, All user stories in the Scrum Product Backlog are prioritized and ordered from highest to lowest priority, The level of details stored in a user story depends on its position within the Scrum Product Backlog, User stories are estimated,Scrum Product Backlog is a living document,There are no action items or low-level tasks in the Scrum Product Backlog. User Stories Add Value To Client, Business, and Systems Each user story in the Scrum Product Backlog must offer some client value. User stories without any client value are a pure waste of resources, and they should be eliminated. The Scrum Product Backlog can include user stories for: The specification of functional and nonfunctional requirements,The summary of high-level break-down of the work necessary to launch the software product, Setting up non-production development and demonstration environments,Remediating defects. Example Scrum Product Backlog Some tasks may not add direct value to the functionality of software system and business clients. Nevertheless, they should add value by increasing quality, reducing technical debt, and increasing maintainability of the product during the long run. Product Backlog Is A Living Document The Scrum Product Backlog is a living document. It changes and evolves throughout the entire course of a project. If needed, new user stories are added, existing user stories may be altered, defined in more detail, or even deleted. Requirements of Scrum projects are no longer frozen early on like we used to have them with the Waterfall Methodology. Instead, the final set of requirements within the Scrum Product Backlog are developed iteratively, together with the emerging software increments.That is different from traditional requirements engineering. Still, this new way of handling client requirements allows the Scrum Team to maximize client value and minimize waste of resources. Different Level Of Details The requirements in the Scrum Product Backlog can have varying depths with their granularities. Only those requirements that will be implemented during the next few Sprints should be defined with greater detail. All other user stories should remain coarse-grained; they should be only processed “just in time” before the Scrum Team needs to know more about them. It does not make sense to invest time and resources into the specification of these requirements, as some of these requirements may change or disappear until they are needed for implementation. “Just in time” handling of requirements is one of the most excellent benefits the Scrum Framework offers to deal with “unknown unknowns” in your projects. No Low-Level tasks In The Product Backlog The Scrum Product Backlog should not contain detailed task break-down of user stories. The Scrum Product Owner defines the requirements together with the business clients and stakeholders before he or she brings them to the Backlog Refinement or Sprint Planning Meetings. Detailed task break-down and distribution of these tasks among the Scrum Team Members are the responsibility of the Scrum Team. The Scrum Product Backlog Is Ordered Based On Priority All user stories are prioritized, and the Scrum Product Backlog is ordered based on the priority of user stories (from highest to lowest). The Scrum Product Owner performs the prioritization with the support of the Scrum Team. During this prioritization exercise, the added value created for the business of the client, costs, risks, and dependencies are the most common factors which are into account by the team. Thanks to this prioritization, the Scrum Product Owner can decide what the Scrum Team should subsequently build and deliver. All User Stories Are Estimated All user stories within the Scrum Product Backlog have to be estimated according to the agreed norm of story point units such as Fibonacci number or S/M/L/XL/XXL, etc. More about this comes later in this material. These estimations then impact the capacity planning of Sprints, contents of Sprint Backlog, and release plans. Working With The Backlog The Scrum Product Backlog needs regular care and attention. It needs to be carefully managed because it’s the source of truth to understand what your software product is all about. At the beginning of a project, it’s filled with a lot of high-level stories that may or may not be highly relevant to contribute to the success of the project. While the project progresses from one Sprint to another, the Scrum Product Owner and the team learn more about the project. Subsequently, the contents of the Scrum Product Backlog will become perfectly reasonable to reflect your product better. After this initial setup, the Scrum Product Backlog has to be continuously maintained. The maintenance of the Scrum Product Backlog stands for: As new requirements are discovered, they are described and added. Existing requirements can be changed or removed as appropriate,Ordering (Prioritizing) the Scrum Product Backlog. The most important (highest priority) user stories are moved to the top,Preparing the high-priority user stories for the upcoming Sprint Planning Meetings (usually during Backlog Refinement Meetings), (Re-)Estimating the user stories in the Scrum Product Backlog (usually during Backlog Refinement Meetings). The Scrum Product Owner is responsible for making sure that the Scrum Product Backlog is always in good shape. And yet maintaining the Scrum Product Backlog is a collaborative process. A reasonable capacity of the Scrum Team members should be reserved for managing the Scrum Product Backlog for the time they need to spend during Scrum Rituals (Events). Furthermore, note that, this collaborative maintenance of the Scrum Product Backlog helps to clarify the requirements and creates buy-in of the emerging software product from the Scrum Team members. What Is The Sprint Backlog? This Might Surprise You! The Sprint Backlog stores and maintains user stories required to deliver the shippable software increment of a Sprint. These user stories are the ones the Scrum Team committed during the Sprint Planning Meeting. All user stories in the Sprint Backlog are estimated to enable the monitoring and tracking of the work. The Sprint Backlog is a living artifact, and during the course of Sprint, the Scrum team members continuously update it. When a Scrum Team member works on a task, his or her name is associated with it. The status of the task is set to “Started Tasks” or “Work In Progress”. When the task is completed according to its Definition of Done, its status is set to “Done” or “Completed”. New tasks (not new user stories) can be added to the Sprint Backlog during the Sprint. At the end of every day, the remaining effort to deliver the full Sprint Backlog is calculated. This helps the Scrum Team and the Scrum Product Owner to monitor the remaining amount of work to bring the Sprint goals to success. The Sprint Backlog can be kept electronically by using a Scrum Project Management Software or spreadsheet software such as Excel or Google Sheet. Alternatively, for smaller and new teams, cards (or post-its) glued on a real physical board can be used too. The latter has some advantages such as transparency of work and easy access for everyone, including the stakeholders. Its downside is that it’s not sustainable if the Scrum Team is distributed over multiple locations. The figure below shows a sample of how such a Sprint Backlog Board can be built. The structure should be adapted to reflect the needs of the project and the Scrum Team. A Sample Sprint Backlog Board It’s evident that for a Scrum Team to work productively, they need to understand the difference between a Product Backlog and a Sprint Backlog, and how these two elements interact to execute forward the project. Remember that there is a complete list of user stories from the Product Backlog. And now, a small subset of this list is being moved to Sprint Backlog to accomplish the goals of the Sprint. During the Sprint Planning Meeting, all members of the Scrum Team should discuss what tasks must be done and how these tasks will be completed. It’s at this point that each item on the Sprint Backlog is broken down into tasks or steps that will be taken to complete the committed user stories. All of this must be clearly communicated and agreed upon, so the Scrum Team members have an unmistakable consensus about what is coming in the Sprint and what it takes to accomplish its goals. What Is A Sprint? This Might Surprise You! In the scrum framework, all activities to implement the requirements happen during Sprints. Sprints are cycles of work activities to develop shippable software product or service increments. Sprints are also sometimes called iterations. You think about sprints as if they’re micro projects. As the term “Sprint” implies, a sprint doesn’t take long, and it’s maximum for four weeks. Sprints are always short, usually between 2 to 4 weeks. But depending on the reliably foreseen amount of work or for Exploration Sprints, a one week long Sprint is also typical. With the approval of the Scrum Product Owner, a Scrum Team may need an Exploration Sprint to investigate new technology, build a mock-up or a proof of concept. Different from a running race, at the end of a Sprint, the Scrum Team shouldn’t be out of breath and power. Instead, the Scrum Team should be fresh, and they should energetically start the next Sprint. The Scrum Software Development and Delivery Framework has nothing to do to create pressure and stress for its team members. It’s a well known fact that people perform best when they can work focused, relieved, and undistracted. If it’s applied correctly this is what Sprints help us accomplish. Every Sprint starts with a Sprint Planning Meeting. During the Sprint Planning Meeting, the Scrum Team decides what and how many requirements they will implement in this given Sprint. Subsequently, the Scrum Team starts the execution of activities to deliver requirements. Daily Scrum (Daily Scrum Meeting) happens every day at the same time in the same place. The goal of this meeting is to align all members of the Scrum Team regularly. Scrum Team Members can also ask help from the Scrum Master to remove any impediments which may potentially slow down or block the progress of a Sprint. The Scrum Team finalizes a Sprint with Sprint Review and Sprint Retrospective meetings. The Sprint Review Meeting enables the Scrum Product Owner to review and control the work results the Scrum Team has created during the Sprint. During the Sprint Retrospective Meeting, the Scrum Team reflects the way they work together, how they use the Scrum Framework, and how they can improve. So the Scrum Team jointly takes these improvement potentials and feedback into account during the next Sprint Planning Meeting.Sprints enable such feedback loops during short periods with small batch sizes of work. That’s one of the significant reasons why and how the Scrum framework helps teams and organizations to improve themselves continuously.

Scrum Institute, Scrum Framework Episode #10 has been proudly brought to you by International Scrum Institute, https://www.scrum-institute.org You can also listen Scrum Institute’s Podcast from Apple, Spotify, Castbox and Google Play. Listen to Scrum Institute Podcast on AppleListen to Scrum Institute Podcast on Google PlayListen to Scrum Institute Podcast on SpotifyListen to Scrum Institute Podcast on Listen NotesListen to Scrum Institute Podcast on Castbox What Is User Story In The Scrum Framework? This Might Surprise You! The entries in the Scrum Product Backlog are often written in the form of User Stories. A User Story tells a short story about the requirements of someone while he or she is using the software product we are building. It has a name, a brief narrative, and acceptance criteria for the story to be counted as completed. The advantage of user stories is that they precisely focus on what the user needs and wants without going into the details on how to achieve them. How to achieve them will be the job of the Scrum team as a later stage, There are different recommendations on how to define User stories. A well known and reliable template is: As an [actor], I [want|must] [action] so that [achievement] Or in a shorter version:As an [actor], I [want|must] [achievement] The Actor is the owner of the user story. That is often a user, but it is advisable to be more specific. By using particular actors such as an administrator, logged in customer, or unauthenticated visitor or so on, user stories become distinctive. So they set requirements into a proper context everyone can understand. The Action is what the Actor wants to do. If it is a mandatory requirement, it can be prefixed as must. Otherwise, it’s prefixed as want. The Achievement is what the Actor wants to achieve by performing the Action. That’s the Actor’s envisioned business result or a functional technical component that emerges once the Action is completed. How To Estimate Effort For Stories In The Scrum Framework? This Might Surprise You! All user stories within the Scrum Product Backlog have to be estimated to allow the Scrum Product Owner to prioritize them and plan releases. That means the Scrum Product Owner needs a reliable assessment of how much the delivery of each user story will take. Nevertheless, it is recommended that the Scrum Product Owner does not interfere with the estimations that the Scrum Team performs. So the Scrum Team delivers its estimates without feeling any pressure from the Scrum Product Owner. The Scrum Framework itself does not prescribe a way for the Scrum Teams to estimate their work. The teams who rely on the Scrum Framework do not deliver their estimates of user stories based on time or person-day units. Instead, they provide their estimates by using more abstract metrics to compare and qualify the effort required to deliver the user stories. Common estimation methods include: Numeric sizing (1 through 10),T-shirt sizes (XS, S, M, L, XL, XXL, XXXL), orthe Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, 34, etc) An Example User story The Scrum Team members must share a common understanding and consensus of the unit of estimations they use so that every member of the team feels and acts comfortable with it. Planning Poker® / Scrum Poker One commonly used method for the estimation process is to play Planning Poker® (also called Scrum Poker). When using Planning Poker®, the social proof influence among the Scrum Team members are minimal. Therefore, the Scrum Team produces more accurate estimation results. What you need to play Planning Poker® game is straightforward: The list of features to be estimatedDecks of numbered cards. A typical deck has cards showing the Fibonacci sequence, including a zero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. Other similar progressions are also possible. The reason for using the Fibonacci sequence is to reflect the uncertainty in estimating larger items. It would be a waste of time to discuss if a user story should have a size of 19, 20 or 21. And yet, it’s relatively easier to decide if the user story fits better to the size 13 or 21. A high estimate could mean that the Scrum Team members have not very well understood the user story yet. So they can attempt to secure extra capacity for contingency before their commitment to this user story. Alternatively, that could also mean that the user story should be broken down into multiple smaller user stories.Scrum teams can usually estimate smaller and clearer user stories with higher confidence. Finally, the Scrum Team plays Planning Poker® by adhering the following steps: The Scrum Product Owner presents the story to be estimated. The Scrum Team asks questions, and the Scrum Product Owner articulates the user story in more detail. If the Scrum Team has to assess many user stories, estimates can be time-boxed in a way that the Scrum Team does not spend more than a few minutes for each user story. If the team cannot still estimate a user story in a given time-box, then this could be a signal to which the Scrum Product Owner needs to pay attention. This signal indicates that either the end-user requirement or the user story or both of them are not clear enough, so they need to be rewritten.Each member of the Scrum Team privately chooses the card representing the estimation.After everyone has selected a card, all selections are revealed.People with high and low estimates are asked to explain their assessment because they may have thought something that the majority of the Scrum Team members have been unable to see.Another estimation is done for this particular user story until the team reaches a consensus for an estimate.The Scrum Team repeats the game until they estimate all user stories. Planning Poker® is a registered trademark of Mountain Goat Software, LLC. What Is The Definition Of Done In The Scrum Framework? This Might Surprise You! In the Scrum framework, the factors which define when a feature is complete and when it meets the required quality standards are set by Definition of Done (DoD). As it was clarified before in this material, DoDs specify the expected outcome in terms of functional and non-functional requirements, design, coding, unit testing, end-user validations, documentation, and so on. DoDs are defined in the levels of both user stories and tasks. DoDs of user stories focus on functional and non-functional client requirements, whereas DoDs of tasks focus on the desired working activities from the Scrum Team members. The Scrum Team is not allowed to close the user stories, and obviously, the tasks that do not fulfill their DoDs. Definition of Done (DoD) is used to decide whether a User Story from the Sprint Backlog is complete or not. DoD is a comprehensive checklist of required activities to ensure that only truly completed features are delivered, not only in terms of functionality but in terms of quality as well. The norms which a Scrum Team uses to define DoDs may vary from one team to another, but it must be consistent within a given Scrum Team. There are usually different DoDs at various levels: DoD for a Project/Product (In the project goals)DoD for a Release (In the release goals)DoD for a Sprint (In the sprint goals)DoD for a User Story (In the User Story)Dod for Tasks (In the task) One more essential thing to keep in mind here is that a DoD is neither static nor indisputable. During the course of a project, a release, or a sprint, a DoD can be challenged by anyone from the Scrum team or other business and IT stakeholders. As long as the proposed changes of a DoD makes sense and they’re brought up to bring the project to success, the Scrum Team and the Scrum Product Owner should be open minded to listen to those proposals and implement them when and where necessary.

Scrum Institute, Scrum Framework Episode #9 has been proudly brought to you by International Scrum Institute, https://www.scrum-institute.org You can also listen Scrum Institute’s Podcast from Apple, Spotify, Castbox and Google Play. Listen to Scrum Institute Podcast on AppleListen to Scrum Institute Podcast on Google PlayListen to Scrum Institute Podcast on SpotifyListen to Scrum Institute Podcast on Listen NotesListen to Scrum Institute Podcast on Castbox How Does The Scrum Framework Work Without A Project Manager? This Might Surprise You! In a traditional project, typically, a Product Manager defines the requirements. Then the Product Manager delegates the realization to a Project Manager. Afterward, the Project Manager coordinates all activities needed to deliver the requirements of the project. The Scrum Framework does not define a “Project Manager” role in the classical sense. And yet, the tasks of this role are still required to deliver a project successfully. Within the Scrum Framework, the responsibilities of a Project Manager are distributed over the functions of the Scrum Product Owner and the Scrum Master. The definition of the role and responsibilities of the Scrum Product Owner takes possible conflicts that may arise between the Product Owner and the Project Manager into account. Decisions about functionality, release planning, and budgeting can be made much more comfortable, quicker and better if one person is responsible for the execution, controlling, and documentation of those activities. Otherwise, there would always be a constant tension between the Scrum Product Owner (not responsible for the project) and the Project Manager (not responsible for the execution of work). The goal of any reliable process should be to avoid this potential conflict that impacts the functional and tactical administration of the work that the Scrum Team performs. And that’s precisely what the Scrum Framework aims to accomplish. Therefore, the typical responsibilities of Project Managers and Product Managers are merged into the Scrum Product Owner role. Nevertheless, the Scrum Master takes over some responsibilities of a traditional Project Manager. Tracking the tasks in Sprints and facilitating the resolution of impediments are among his duties. Since he or she is part of the Scrum Team, it is much easier and much more efficient to handle such activities directly in the team.

Scrum Institute, Scrum Framework Episode #8 has been proudly brought to you by International Scrum Institute, https://www.scrum-institute.org You can also listen Scrum Institute’s Podcast from Apple, Spotify, Castbox and Google Play. Listen to Scrum Institute Podcast on AppleListen to Scrum Institute Podcast on Google PlayListen to Scrum Institute Podcast on SpotifyListen to Scrum Institute Podcast on Listen NotesListen to Scrum Institute Podcast on Castbox What Is The Role Of The Scrum Team? This Might Surprise You! The Scrum Framework recognizes three roles: The Product Owner,The Scrum Team Member,The Scrum Master. In addition to other programs it’s providing to its worldwide students, International Scrum Institute provides three primary training and certification programs for these three roles. These programs are namely Scrum Product Owner Accredited Certification (SPOAC), Scrum Team Member Accredited Certification (STMAC), and Scrum Master Accredited Certification (SMAC) . A proper scrum organization must adequately possess people from all these three skill-sets. That’s particularly essential to succeed with the scrum software development framework. None of these roles is indispensable and irreplaceable. They cannot be combined with the other scrum roles and functions.Each Scrum Product Owner typically works together with one scrum team. Each Scrum Team has its own Scrum Master, and each Scrum Master cares and works with one single Scrum Team. Please don’t underestimate the importance of understanding the purpose and function of these roles and employing them with adequate talents. Many times we observed that the root cause of difficulties of a scrum team is either because these roles are not understood or they don’t employ the right people. Each of these roles has a defined set of responsibilities. Only if the owners of these roles fulfil these responsibilities, closely interact, collaborate, and work together, they can finish a Scrum project successfully. Scrum Roles & Stakeholders The Scrum Team Within the Scrum Framework, dedicated Scrum Teams do all work delivered to the business clients. A Scrum Team is a collection of individuals working together to provide the requested and committed product increments. To work effectively, it is essential for a Scrum Team that everyone within the team: Embraces values of the Scrum Framework such as Courage, Focus, Commitment, Respect, and Openness, Adheres the same norms and rules,Follows the common goal, which wires them to both IT and business outcomes. When setting up a new Scrum Team, you always need to keep in mind that no new team will deliver with the highest possible performance right from the beginning. After setting up the team, it has to go through certain phases as described by the Tuckman-Model: Forming, Storming, Norming, Performing. Tuckman's Stages of Team Development How long it takes until the Scrum Team reaches the Performing Phase varies from team to team. Hiring good basketball players for the same club will not make a good basketball team as soon as they start to play together. They first need to learn and adapt their playing styles, their strengths and weaknesses to assist each other, and to play in harmony. Scrum teams are not that different. Therefore, it’s vital to keep in mind that it usually takes about 3 to 5 Sprints until the team becomes mature enough to deliver its results effectively and predictably. Characteristics of a Scrum Team Scrum Teams have the following characteristics: Team members share the same norms and rules,The Scrum team as a whole is accountable for the delivery,The Scrum Team is empowered,The Scrum Team is working as autonomous as it is possible,The Scrum Team is self-organizing,The skills within the Scrum team are balanced,A core Scrum Team is small and has no sub-teams,The Scrum Team members are dedicated to their teams with 100% capacity,Scrum Team members are collocated, and they ideally share the same room. Rules & Norms The environment, business, IT, and geographical ecosystem of Scrum Teams invisibly define some of the norms the teams follow. And yet, to become a truly successful Scrum Team, some rules and norms should be explicitly developed and exercised during the Norming phase. These common standards are essential, and they can’t be overemphasized to deliver smooth gameplay, IT, and business results. Otherwise, the Scrum Team members would have to continually switch back and forth between different value systems and rule sets, and they waste their valuable time. Just a few examples of such norms and rules are: The goal, scope, duration, location, participants and outcomes of Scrum Rituals (Events),Required level of details to write clear, concise and unmistakable Definition Of Dones (DoDs),Guidelines to prioritize and estimate user stories and tasks, Guidelines, procedures and the level of details to create living documents, Tools to use and tools not to use (remember, sometimes less is more), Coding standards,Tools and guidelines to build/perform manual/automated tests and ensure quality,The process to resolve bugs,The process to handle change requests,The process to prepare to product increment demonstrations during Sprint Review Meetings,The process to handle the outcomes of each Scrum Ritual (Event), Frequency, depth, and duration of Backlog Refinement Meetings. Accountability The Scrum Team as a whole is responsible for delivering the committed user stories in time and with the highest possible quality. A good result or a failure is never attributed to a single team member but always the result of the Scrum Team. Empowerment & Self-organization The Scrum Team has to be empowered to define What the team commits to deliver at the end of the Sprint, How the committed user stories will be broken down into tasks,Who will perform a specific task and in which order the tasks are implemented. Only if the Scrum Team is empowered to decide these and similar internal decisions, the team members will work with higher performance and motivation for the interest of their client stakeholders. Balanced set of skills Each Individual within the Scrum Team will most certainly have specialized skills, focus, and personal preference of interests. However, to achieve the best possible performance, your Scrum Team needs to have a balanced set of skills. Only then the Scrum Team will be able to deal with the ever-changing IT and business challenges, and they can act as autonomous as it is possible. That means a Scrum Team should be multidisciplinary (designers, developers, testers, architects, etc.) right from the beginning. On the other hand, this also means that each team member should learn a little bit from each other’s specialization. For instance, to be able to finish a committed user story until the end of the Sprint, a developer should willingly write and execute tests, and consult the tester whenever necessary. The roles of the Scrum Team members are not compartmentalized like the architect, the developer, the tester, and so on. They all share the same title, “Scrum Team Member” regardless of their core personal competencies. Size of the Scrum Team Scrum Teams are small. The ideal size is 7 +/- 2 people. Note that if the Scrum Team contains more than nine members, your team will most probably suffer due to excessive overhead of alignment and communication. And yet, there is no one size fits all answer. Your Scrum Teams may still productively function even if they have less than five or more than nine members. The only way to find this out is to test, learn, and adapt. If you find out that a team of 13 people cannot perform well enough, then these Scrum Teams need to be split into two teams. These Scrum Teams should closely align, and they correlate their goals and user stories. Besides that, they work independently. Collocation To minimize unnecessary communication overhead, each Scrum Team should be collocated. If the work has to spread over multiple geographical locations, independent Scrum Teams need to be created. These teams need to align and correlate their goals and user stories. Responsibilities of the Scrum Team The Scrum Team has specific responsibilities they need to fulfill: They have to breakdown the user stories, create tasks, define priorities and estimates, and they self-organize the implementation. In other words, they have to create, process, and deliver the Sprint Backlog.They have to perform Daily Scrum Meetings.They have to ensure that at the end of the Sprint, potentially shippable product increment is delivered and demonstrated. They have to update the status and the remaining work efforts for their tasks to allow the creation of a Sprint Burndown Diagram. What Is The Role Of The Scrum Master? This Might Surprise You! The Scrum Master serves all participants of a Scrum Project and the external stakeholders to comprehend and apply the Scrum Framework correctly. He or she supports the Scrum Team to execute the Scrum Framework successfully and contributes them to improve their productivity and performance continuously. The role of the Scrum Master is to establish the Scrum Process in its organization, the new way of thinking and acting. Furthermore, the Scrum Master acts as a change agent. He or she coaches the team to develop new team norms and standards. The Scrum Master has its desk somewhere very close to the rest of the scrum team. Essential tasks of a Scrum Master owner are: To establish the Scrum Framework in his or her business and IT ecosystem,To act as a change agent and support the adaptation of existing processes to maximize productivity of the Scrum Team.To coach the Scrum Team to understand and live the values of the Scrum Framework,To ensure efficient and close collaboration between the Scrum Product Owner and the Scrum Team,To remove impediments which hinder the continuity of work,To lead progress of work by serving,To moderate the Scrum Rituals (Scrum Events).To guard the Scrum Team from external interference and interruptions while the team does work it has originally committed for a Sprint. Easily Learn Scrum and Officially Prove Your Know how To effectively do this work, a Scrum Master needs to possess savvy moderation and coaching skills. He or she needs to be a continuous learner to inspire others to learn, change, and grow. To learn more about Scrum Master’s duties as a facilitator, I recommend you to have a look at this article: If I had 5 Minutes to explain Scrum Master As a Facilitator. To learn more about Scrum Master’s duties as a facilitator, I recommend you to have a look at this article: If I had 5 Minutes to explain Scrum Master As a Facilitator. The Scrum Master is part of the Scrum Team and acts as a servant-leader for the Scrum Team. In the beginning, this will be a full-time job so that the Scrum Master will not be able to contribute to the Sprint results directly. However, after a few Sprints, while the Scrum Team approach to the Performing phase of the Tuckman model, the initial workload as moderator and coach will reduce. So, the Scrum Master could actively contribute to the Sprint goals. Since there must be trust between the Scrum Master and the Scrum Team members, it can always be a good idea that the Scrum Team chooses its Scrum Master. However, in reality, the management usually imposes who the Scrum Master will be. To get the required trust, the Scrum Master should have no line management responsibility above the Scrum Team members. Otherwise, open communication in the Scrum Team and joint ownership of work and decision-making ability of the Scrum Team can suffer. Guarding The Scrum Team, Removing Impediments An essential job of the Scrum Master is to safeguard the Scrum Team from a false sense of urgency. Line management and the Scrum Product Owner often attempt to add unplanned user stories to the Sprint Backlog while the team focuses on the work of a planned Sprint. However, one of the critical aspects of the Scrum Framework is that all user stories are known and committed only during the Sprint Planning Meetings. The Scrum Team cannot be forced to take over new user stories. The job of the Scrum Master is to ensure that until the next Sprint Planning Meeting, these new user stories are stored in the Scrum Product Backlog. Alternatively, if the ongoing Sprint does not make any business and/or technical sense to continue, it can be canceled, and a new Sprint can be planned. Scrum Team members should only concentrate on delivering client value by building potentially shippable product increment. The Scrum Master helps by removing impediments that block or slow down the progress of work. Examples of removing impediments could be: To arrange support, resources,To find missing know how, andTo do hands-on work to help the Scrum Team Members. Scrum Master as a Change Agent One of the cornerstones of the Scrum Framework is the continuous improvement through Inspect & Adapt. The Scrum Master hosts and moderates the Scrum Retrospective Meeting, and his or her job is then to facilitate, control and measure the change of the identified shortcomings. Facilitation of Scrum Rituals (Event) The Scrum Framework defines several meetings that have to be organized and facilitated by the Scrum Master: Scrum Grooming (Backlog Refinement) Meetings,Sprint Planning MeetingsDaily Scrum Meetings,Sprint Review Meetings, andSprint Retrospective Meetings What Is The Role Of The Scrum Product Owner? This Might Surprise You! The Scrum Product Owner is a central role within the Scrum Framework. That role unifies product and project management tasks, and it’s also firmly integrated with software development and delivery. The product owner’s role is far broader than traditional project management, program manager, or product management roles. He or she represents the end customers and/or other stakeholders and is responsible for maximizing the value of the product by ensuring that the Scrum Team delivers the right work at the right time. The Scrum Product Owner decides the software requirements provided for a specific software version, and when the software will be released. She represents functional and nonfunctional demands from end-users. That means that the Scrum Product Owner has to work very closely with the Scrum Team and coordinates their activities over the entire lifecycle of the project. No one else is allowed to impose the Scrum Team to work for a different set of priorities. Essential tasks of a Scrum Product owner are: To manage and clarify project requirements,To guide releases and to ensure return on investment (ROI),To closely work with the Scrum Team and enable it to deliver the correct work on time,To manage stakeholders and their expectations,To manage the Scrum Product Backlog. The Scrum Product Owner can delegate certain activities (like physically maintaining the Scrum Product Backlog). However, he or she still owns the accountability of his or her tasks. Managing the Product Backlog The Scrum Product Owner is the only person allowed to own the contents of the Scrum Product Backlog. That means he or she needs to: Create, maintain and clearly describe user stories in the Scrum Product Backlog,Prioritize user stories to accomplish business goals and fulfil the mission of software product,Ensure that the Scrum Team correctly comprehends and implements the user stories in the Scrum Product Backlog. Release Management The Scrum Product Owner is responsible for reaching the project goals. He or she creates and maintains the release plan and decides about deliveries, end-user functions, and the order they need to be delivered. Scrum Product Owners often manage the costs and budget of Scrum Teams too. They collaborate with the Scrum Team members to fine-tune, prioritize, and estimate user stories. Stakeholder Management External stakeholders should not directly bring their demands to the Scrum Team members. Instead, the Scrum Product Owner should collect and assess required functionalities with the stakeholders (for instance, with internal clients, representatives of external clients or end-users). The Scrum Product Owner combines, filters and initially prioritize these user stories before they're discussed them with the rest of the Scrum Team. Collaboration With The Scrum Team For a successful project, the Scrum Product Owner and the Scrum Team must work very closely. The Scrum Product Owner is responsible for ensuring that the Scrum Team members are informed and aligned about the aimed goals of software they’re building. During Sprint Review Meetings, the Scrum Product Owner is responsible for inspecting, accepting, or declining deliverables of the Scrum Team. What Is The Role Of The Scrum Team Member? This Might Surprise You! The Scrum Team Members implement the software. They jointly decide the number of requirements that they can undoubtedly deliver during a particular product increment called“Sprint”. A high-performer scrum team has most of the software engineering skills typically in it. Software developers, architects, testers, database administrators, and team members from all other roles work together. They jointly build and deliver great software their client is paying for. Scrum team members do no longer belong to a functional silo of a matrix organization. Developers do no longer belong to software development competence centers, and testers do no longer belong to the software testing competence center, and so on. Regardless of their past coordinates in the organization, members of a scrum team belong to their particular scrum project. Now their job is to build the best possible software to deliver the requirements of their scrum product owner. Characteristics of scrum teams are: Empowered and Autonomous,Cross-functionalSelf-organized and smallFull-time participantsWorking in the same roomOne for all, all for one. It's an excellent time to remind that the Scrum Team members follow Scrum values persistently. CourageFocusCommitmentRespectOpenness

Scrum Institute, Scrum Framework Episode #7 has been proudly brought to you by International Scrum Institute, https://www.scrum-institute.org You can also listen Scrum Institute’s Podcast from Apple, Spotify, Castbox and Google Play. Listen to Scrum Institute Podcast on AppleListen to Scrum Institute Podcast on Google PlayListen to Scrum Institute Podcast on SpotifyListen to Scrum Institute Podcast on Listen NotesListen to Scrum Institute Podcast on Castbox What Can Cause Chaos And Frustration Before The Scrum Framework? This Might Surprise You! To better understand the impact of the scrum framework to our software engineering practices and businesses, it makes sense to have a look at a day in the life (or a software project in life). Therefore, I would love to briefly talk about a software project from the past before we adopted the scrum development and software delivery framework in our organizations. A few days before I wrote these lines, we had lunch with one of my ex-colleagues with whom we used to work together almost 20 years ago. This gentleman, Marcus has got his scrum master certification and scrum product owner certification from International Scrum Institute. He currently works as a scrum master for one of the leading software houses in the agile project management software domain. As a scrum master, Marcus is now in charge of operating an agile scrum team whose scrum team members located in geographically distributed locations around the globe. During our lunch, Marcus admitted that there are a lot of typical challenges with distributed agile scrum teams. Some of the problems he specifically mentioned related to his software project configuration are: Differences in working styles among scrum team members, Timezone differences,Cultural misfits, andLanguage constraints. Despite these difficulties, Marcus still added that running a software project with the agile scrum process is more fun, productive, and enriching than how we used to work 20 years ago. Compared to days when we used to work without scrum software development and scrum software delivery processes. Marcus' statement was indeed a big testimonial for the credit of the scrum framework from a very accomplished and experienced manager, scrum master, and product owner. Thank you, Marcus! Then we explained to him one of our past software projects before we used to meet with the scrum framework. I’m sure that many scrum masters would resemble this experience to their previous projects before they’ve gotten their scrum master certifications. Back in the late 1990s, we were part of a software engineering group to build a smart card-based public key infrastructure. Smart cards securely protected private keys of infrastructure members, associated public keys and their wrapper certifications were openly distributed (as the name public implies). Back in the day, this was by itself a relatively complex IT project that required multiple interdependent hardware engineering and software engineering teams. We had to do massive amounts of research and development (R&D) to build a fully functional hardware and software system. Remember these are days before we had the minimum viable product (MVP) concept to experiment, create, learn, and experiment again. Without scrum to create such a sophisticated infrastructure that constituted numerous hardware and software elements was a real challenge. Here are three significant setbacks we used to have without any scrum masters and anyone who possesses a scrum master certification in our teams. Had To Plan The Entire Project Before Understanding The Project? This Might Surprise You! Without scrum, our teams had built and delivered entirely wrong software and hardware products that did not fulfill demands from our client. We had times in our professional lives when some third party companies had imposed how we supposed to build our software products or software services. Capability Maturity Model (CMM), ISO 9001:2008 and other derivates attempted to help our companies to ensure we build our correct software in correct ways. How successful they used to be is not part of this book. This book was meant to focus on the scrum process and meri ts of the scrum framework rather than criticizing almost extinct procedures. However, I have to add that these process improvement frameworks before the scrum software engineering framework recommended a phased approach. They advised a phased software engineering approach which we called the Waterfall Software Engineering Model. With the Waterfall Model, each software project was supposed to start with requirement analysis, where we aimed to understand what our client needed and wanted. Then we designed these requirements, we implemented them, we tested (verified) them, and we maintained them in our software production environments. Finally, we reached to end of the software engineering lifecycle. Nonetheless, the reality didn’t play out like that! The Waterfall Methodology vs The Scrum Framework Phases in the Classical Waterfall Software Development Model The adverse effects of unforeseen delays happened during a particular phase of the Waterfall Software Engineering Model were inevitable to the following software engineering phases. Studies have shown that in over 80% of the investigated and failed software projects, the usage of the Waterfall Methodology was one of the critical factors of failure. But why? As shown on the left side, when deploying the Waterfall Methodology, there is a strict sequential chain of the different project phases. A previous phase has to be completed before starting the next phase. Going back is, in most cases, painful, costly, frustrating to the team, and time-consuming. The project timeline is planned at the start. A releasable product is delivered only at the end of the project timeline. If one phase is delayed, all other phases are delayed too. To avoid this, project managers of the Waterfall Methodology usually try to anticipate all possibilities beforehand. That means that in one of the earliest phases of the project, they try to define all requirements as fine-grained and complete as possible. However, requirement definition in an initial stage of a project is often complicated, and therefore many requirements change (or should change) throughout the project. Studies have shown that in more extensive and complex projects, about 60% of the initial requirements do change throughout the course of projects. Other requirements are implemented as define, but some of them are not really needed by the customer. So those implementations consume time and money that could have been better used to implement functionality with a higher added value for its clients. The separation into different project phases forces project managers to estimate each phase separately. The problem is that most of these phases usually are not separate. They are working together and in parallel. For instance, no reasonable human-being can assume that the development phase finished before the testing phase started. And yet, this is precisely and unfortunately how the Waterfall Methodology used to work. The Waterfall Methodology for developing software can be used for implementing small and straightforward projects. But for bigger and more complex projects, this approach is highly risky, if not insane. It’s often costlier and always less efficient than Scrum software development and delivery framework. This was the life before the Scrum framework. Sending our software back and forth between various teams, without the guidance of professionals with the Scrum skills, made our work bureaucratic, complex and unproductive. Finally, it wasn’t only the product which suffered, but also employee morale and commitment to our organizational mission have wholly disrupted. Overcoming A Lack Of Commitment, Change Management & Team Work! This Might Surprise You! The most significant weakness of process improvement frameworks used before Scrum was that: They mainly focused on self-serving organizational demands of leadership. Some of these demands are monitoring, compliance, and predictability. There was no focus on serving clients well and increasing employee morale at all. Thus members of software management teams and various other internal and external stakeholders attempted to have a fixed deadline for software delivery projects and easily monitor the progress of software engineering phases. They penalized their people if something was outside the planned track, and they hoped to fix emerging issues before the scheduled date of project completion. Furthermore, independent silos realized entirely separated software engineering phases. As an example, the development team was completely independent of a software testing (verification) team. Most people who supposed to work for the same business mission didn’t even know each other by their names. Have you got a guess about the reason for this silo-mentality in our organizations rather than focus on business missions and professional (business) maturity of employees? The reason is simply the matrix management . Matrix management is an organizational management and employee structure, and it has been in our businesses since the 1970s. At first glance, the differentiating idea behind a matrix organization or matrix management seems to be smart. The Leadership creates an organizational structure by bringing together employees with similar kinds of functional and technical skill-sets into the same or at best neighbor silos. The Waterfall Project Delivery Model in a Matrix Organization Back in times, it was quite popular to see the so called “Center of Competences” in our companies where each center of competence represented an independent and autonomous silo. One silo for C++ developers, another silo for database administrators, and another entirely separate quality assurance silo in oversees and it goes on and on. Go and figure! The biggest challenge with the matrix organizational structure was that: To deliver a software project without the scrum framework and scrum masters, project managers had to borrow employees from silos temporarily. These employees did not even physically position with their project teams, but they still located in the rooms of their particular center of competences. Up upon completion of projects, these temporary project teams dissolved and project participants moved on their next assignments to serve for other projects. Therefore, the targeted business values of these ongoing software projects have never been the utmost priority for these independent silos. They tend to see their work as checkboxes they ticked for one project over here and another project over there. Leadership and matrix organizational model didn’t teach them how professionals should commit their business to improve the bottom line, including sales, revenue, and profit. A McKinsey Quarterly article written by McKinsey & Company has also clearly illustrated this illusion of cost optimization beyond the matrix organization . Gartner has estimated that organizations worldwide have been yearly spending 600 billion USD to recover their IT systems from non-scheduled maintenance work and defects. Now let’s take a short moment to visualize how the change management and impediment handling of software projects played out. How t hey pl ayed out i n a proj ect configuration with the waterfall model, with the matrix organization, and without the scrum process. Yes. You’re right. Management and employees treated change management, impediment, and error handling as if they’re ill exceptions which shouldn’t have happened in the first place. Therefore, changes in a software project have been the synonym of delays. They usually created a domino effect of cascading delays. Teams required someone to blame and finger point for defects and impediments. Last, but not least, because silos did not have a mechanism in place to process, fix, and learn from their errors, they kept on repeating the same mistakes. Furthermore, they kept on augmenting the amount of technical debt while they passively attempted to deal with their problems. Why Should Democratic Decisions Not Be Overruled? This Might Surprise You! Steve Jobs once said: “It doesn’t make sense to hire smart people and tell them what to do. We hire smart people, so they can tell us what to do.” However, this is precisely opposite of how most of the mainstream leadership used to operate to make decisions before the scrum era. Before we had the scrum process in our organizations, autocratic decisions from leaders overruled the combined intelligence of their teams. They invalidated the democratic decision making ability of groups who were in charge of doing the real works which spanned the entire software engineering lifecycle from the conception of software to its operations. The remoter a decision was shifted away from work centers (teams) it impacted, the more default it was to give a correct mission-critical decision. The judgments from leaders used to be usually impulsive, not thoroughly thought-out, mostly late and tentative, but sometimes even too early. These autocratic decisions imposed from the top made employees feel undervalued. They entirely hindered the ability of their organizations to come up with creative and innovative solutions to handle competitive business and software-related challenges. Furthermore, they discouraged software engineering teams from giving their inputs at the times when they’re asked to contribute decisions. It was a brief overview of how we used to develop and deliver our software services and service products before we adopted the scrum framework in our organizations. Now let’s have a look at how we sorted out these chaos and frustration elements with the help of the scrum process. What Makes The Scrum Framework Succeed? This Might Surprise You! The Scrum Framework changes the classic triangle of project management. Organizations do no longer need to sacrifice one of the time, budget, or quality. The new triangle is now emerging between the budget, time, and functionality. And none of these project success elements have to be endangered. Triangle of Project Management According to the Scrum framework, quality is no longer optional. To deliver what clients are paying for to flourish their businesses, the Scrum Teams strive to provide the best possible software they’re jointly able to build. In the Scrum framework, the factors which define when a feature is complete and when it meets the required quality standards are set by Definition of Done (DoD). DoDs specify the expected outcome in terms of functional and non-functional requirements, design, coding, unit testing, end-user validations, documentation, and so on. DoDs are defined in the levels of both user stories and tasks. DoDs of user stories focus on functional and non-functional client requirements, whereas DoDs of tasks focus on the desired working activities from the Scrum Team members. The Scrum Team is not allowed to close the user stories, and obviously, the tasks that do not fulfil their DoDs. Scrum Product Owner and the Scrum Team define user stories and their tasks throughout the course of the Scrum software engineering process incrementally. This incremental development allows the team to remain adaptive and adjust their next best actions in a controlled manner without the additional costs and risks of jeopardizing large chunks of previous work. The Scrum Team builds a potentially shippable software product increment until the end of each Sprint. The team demonstrates and discusses these increments with the Scrum Product Owner and client stakeholders to get and incorporate their feedback towards the next steps of their project. This flexibility applies to not only software delivery but also the operational processes. So, the Scrum Framework allows the optimization of the use of resources (human, time, budget, material) and the minimization of wastes. Studies have shown that Scrum has the following positive effects in practice: More frequent code deployments,Faster lead time from committing to deploying code,Faster mean time to recover from downtime,Lower change failure rate,Better product quality,Reduced or identical costs compared to pre Scrum deployment,Improved productivity and throughput,Improved code and operational reliability,Enhanced organizational performance and client satisfaction,Improved market penetration, market share, and profitability of organizations,Improved market capitalization growth,Improved motivation of employees. Introducing and adopting the Scrum Framework is non-trivial. And yet, the adaptive and iterative approach of the Scrum Framework handles this initial burden, and it copes with ever-changing client and business requirements better. Thus, the Scrum Framework is, in most cases, a better alternative to the classical software engineering methodologies.

Scrum Institute, Scrum Framework Episode #6 has been proudly brought to you by International Scrum Institute, https://www.scrum-institute.org You can also listen Scrum Institute’s Podcast from Apple, Spotify, Castbox and Google Play. Listen to Scrum Institute Podcast on AppleListen to Scrum Institute Podcast on Google PlayListen to Scrum Institute Podcast on SpotifyListen to Scrum Institute Podcast on Listen NotesListen to Scrum Institute Podcast on Castbox Learn Scrum Framework Using Real World Case Study! This Might Surprise You! Before Starting The First Sprint Alex works as the Scrum Product Owner of a new software development project. One of his first tasks is to assess and find out requirements to deliver business value his client is looking for. He needs to make sure that his client will get the correct software to achieve tangible business results. He writes down the essential use cases and discusses them with the architects, client representatives, and other stakeholders from IT and business units. After assembling the high-level use-cases and requirements, he writes them into the Scrum Product Backlog and initiates an estimation and prioritization session with the Scrum Team. As a result of this session, all items in the Scrum Product Backlog get an initial rough estimate and priority. During those sessions, Anna, the Scrum Master, ensures that everyone speaks the same language. So, the Scrum Product Owner, the Scrum Team Members, and their stakeholders arealigned with the anticipated goals. So they have an adequate understanding of potentially new concepts for them, such as Use Case, Backlog, Sprint, and so on. And most importantly, the Scrum software development and delivery process is correctly applied in the store. Now Alex, the Scrum Product Owner, begins to break down the high-level requirements into the first draft of smaller-grained user stories. With this list, he then calls for the first Sprint Planning Meeting. Sprint 1 – Day 0 During the Sprint Planning Meeting, Alex presents the Scrum Product Backlog items from the highest priority to the lowest. The Scrum Team asks and clarifies open questions. For each item, the team discusses if they have enough 25 capacity and the required know-how to develop and deliver it. The Scrum Team needs to ensure that all required human and technical resources are in place before the start of the Sprint. They need to confirm that all prerequisites and dependencies are fulfilled, which could be critical to delivering certain software features successfully. During Sprint Planning Meeting (What-Part), the Scrum Team commit to complete the user stories 1,2,3,6,7 and 8 until the end of the Sprint. So these user stories are now moved from the Scrum Product Backlog to the Sprint Backlog. The user stories 4 and 5 cannot be accomplished in this Sprint, as some prerequisite technical infrastructure is not yet in place. After the What-Part of the Sprint Planning Meeting, Anna, the Scrum Master, calls the Scrum Team to drill down how the team is going to implement the committed user stories (How-Part). The emerging tasks during the How-Part of the Sprint Planning Meeting are written down on the cards, and the team store them into the Sprint Backlog. Now all members of the Scrum Team are ready to select a task to begin to work on. Sprint 1 – Day 1 In the morning, the whole team gets together for their Daily Scrum Meeting. Everyone gives a brief and concise statementabout what he or she has done so far, updates the estimates of remaining work on the cards of the Sprint Backlog. Everyone tells what he or she is planning to do today, and reveals if there are any impediments which hinder them from processing any tasks. Today one of the Scrum Team members, Melinda, informs the Scrum Team that she has a problem with the license of the integrated software development environment she is using. Anna, the Scrum Master, checks if other team members have the same problem and confirms that she’ll take care of this impediment after the meeting. After about 15 minutes of this Daily Scrum Meeting, everyone goes back to work. After this meeting, Anna updates the Sprint Burn down Chart to visualize the progress of work during this Sprint. Then she calls the software vendor, orders the missing license, and delivers it to Melinda. Introduction to Scrum A Real World Example (Case Study ) across various Scrum Phases and Sprints Sprint 1 – Day 2 In the morning, the whole team gets together again for their Daily Scrum Meeting. In the afternoon, a member of the Scrum Team, James, has uncertainty about the expected outcome of one of the user stories. He calls Alex, Scrum Product Owner, and they discuss this user story to ensure that James properly understands it. After Alex gets informed and confident about how to proceed with this user story, he continues working on its implementation. Sprint 1 – Day 6 The days starts again with the Daily Scrum Meeting of the team. Anna, the Scrum Master, notices this morning that the meeting tends to take more than 15 minutes. The Scrum Team members are engaging with a discussion regarding the optimization of some database queries. Anna reminds the team that the Daily Scrum Meetings are not meant to do the work, but formally aligning the team about the work and bringing them on the same page. After the Daily Scrum Meeting, Alex (Product Owner) informs Anna (Scrum Master) that the client brought up several new requirements that may potentially impact the ongoing Sprint and the subsequent Sprints. Anna politely reminds Alex that the Scrum Team is unable to pick up these requirements during the current Sprint as the team has already committed to the scope (user stories) of this Sprint. And yet, Anna calls a Backlog Refinement Meeting for the afternoon so that Alex can inform the team about these new requirements. During this meeting, the group supports Alex to figure out where these user stories fit the overall development plan of the software, their initial task break-down, estimates, and priorities. Sprint 1 – Day 10 Finally, that’s the last day of this first Sprint. Anna, the Scrum Master, invites the Scrum Team for the Sprint Review Meeting. The team has prepared a non-production server with the latest version of the shippable software increment they created. Alex, the Scrum Product Owner, and Mr. Rich, one of the client stakeholders, sit in front of an instance of a graphical user interface of this software. They validate if the implementation meets the expectations and if the team documented details regarding the current level of application adequately. At the end of the Sprint Review Meeting, Alex concludes: The team delivered user stories 1,2,6 and 7 as committed and expected. The team couldn’t finish the user story 3 on time, and they didn’t demonstrate this user story at all. So, the remaining tasks of this user story are shifted to this next Sprint.The user story 8 did not fulfill some of its Definition of Done (DoD) criteria. This user story is moved to the next Sprint, so the team can define and complete the associated tasks to satisfy the DoD of this user story later. Alex, the Scrum Product Owner, and Mr. Rich, the client stakeholder, shortly debrief the Scrum Team about the upcoming changes and challenges about the software requirements and the direction of the overall strategy about this software should be going. Mr. Rich thanks the Scrum Team for their efforts and commitment and leaves the room. After the completion of the Sprint Planning Meeting, the Scrum Team sits together for the Sprint Retrospective Meeting. During this meeting, they discuss what went well during the Sprint and what could be improved, so that the likelihood of failed commitments like it happened with user stories 3 and 8 will reduce in the next Sprints. One of the hurdles identified from the Sprint Retrospective Meeting is that the team do not know enough about the overall system architecture. Anna, the Scrum Master, takes over the task of bringing a system architect on board to coach and guide the team at the beginning of the next Sprint. Sprint 2 – Day 1 Alex, the Scrum Product Owner, keeps on adding new requirements to the Scrum Product Backlog based on his recent client meetings. Moreover, he improves the way he articulated DoD of user story 8, so the Scrum Team can better envision the expected outcome from this user story. Alex then invites the team for the Sprint Planning Meeting for Sprint 2. The Scrum Team discuss and commit to user stories with the guidance of Anna, the Scrum Master, and subsequently, the second Sprint begins.

Scrum Institute, Scrum Framework Episode #2 has been proudly brought to you by International Scrum Institute, https://www.scrum-institute.org You can also listen Scrum Institute’s Podcast from Apple, Spotify, Castbox and Google Play. Listen to Scrum Institute Podcast on AppleListen to Scrum Institute Podcast on Google PlayListen to Scrum Institute Podcast on SpotifyListen to Scrum Institute Podcast on Listen NotesListen to Scrum Institute Podcast on Castbox What Is The Scrum Framework? This Might Surprise You! What is Scrum? Well, without making things too complicated, the Scrum framework can be defined as the following: Scrum is an iterative software engineering process to develop and deliver software. Although the software is the main focus of the Scrum framework, iterative and agile Scrum process can be and is already being applied outside the software industry as well. Most people in the IT industry believe that the term “Scrum” was coined early in the 2000s as a parallel track of emerging agile software development and delivery trends. That is a piece of incorrect information! The term “Scrum” was first used and published by Harvard Business Review in January 1986. Hirotaka Takeuchi and Ikujiro Nonaka coined the term “Scrum” with their article: The New New Product Development Game. (Yes, two News) You should have a look at “The New New Product Development Game” to see how everything all about Scrum got started! Scrum can be used in all kinds of software development projects. To develop and deliver complete software packages or only some modules of larger systems — both for products and services of internal and external clients. The Scrum Framework is a lightweight process. It focuses on increasing the productivity of teams while reducing wastes and redundant activities. Scrum defines some general guidelines with a few rules, roles, artifacts, and events. Nevertheless, all of these components are critical, serve for specific purposes, and they are essential for the successful use of the Scrum framework. The main components of Scrum framework are: Three Scrum Roles: The Scrum Product Owner, the Scrum Team, and the Scrum Master.Five Scrum Events (Scrum Rituals) or Ceremonies: Scrum Grooming (Backlog Refinement) Meeting, Sprint Planning Meeting, Daily Scrum Meeting, Sprint Review Meeting, and Sprint Retrospective Meeting.Product Backlog (Scrum Backlog) or Scrum Product Backlog: An artifact that is used to manage and prioritize all of the known requirements of a Scrum project.Sprints: Cycles of work activities to develop shippable software product or service increments.Sprint Backlog: An artifact to keep track of requirements committed by the Scrum teams for a given Sprint. Self-organization and unconditional collaboration are critical elements of the Scrum framework. Scrum Teams do no longer require a project manager in a classical sense. With the Scrum framework, the Scrum Master and the Scrum Product Owner share the role and responsibilities of a typical project manager. Nonetheless, a Scrum Master or a Scrum Product is never allowed to overrule the democratic decision-making capability of a Scrum Team. For instance, only the Scrum team members can jointly commit which ones of highly prioritized Backlog items they will deliver in a Sprint as a software increment. Another central element with the Scrum framework is the continuous improvement that we enable with “inspect & adapt”. A Scrum Team continuously monitors, inspects, and assesses their artifacts and their use of Scrum framework to adapt and optimize them. These continuous efforts for optimization maximize quality, efficiency, client satisfaction, and therefore minimize wastes and overall project risks. The Scrum framework understands that the requirements are likely to change and they are not entirely known, especially at the beginning of projects. Every project has unknown unknowns. Sometimes a few, sometimes a lot. The Scrum framework helps us embrace that we can discover and deal with these unknown unknowns only while we are running our projects. The Scrum Team first fine-tunes and granularizes the lower-level or low priority requirements before it implements them. During Scrum Grooming (Backlog Refinement) and Sprint Planning Meetings. Openness for change, continuous optimization, and learning from errors are now becoming integral elements of the whole software engineering lifecycle. Another cornerstone of the Scrum framework is transparency and direct communication. The Scrum Product Owner works closely with the Scrum Team to identify and prioritize requirements. These requirements are written down as user stories and stored in the Scrum Product 15 Backlog. The Scrum Product Backlog consists of all tasks that need to be implemented to deliver a working software system successfully. A Scrum Team is empowered to select the user stories with which they are confident to deliver within the 2-4 weeks of Sprints. Because the Scrum Team commits its own goals, the team members feel more engaged, and they know that their opinions are listened to. This inclusion of Scrum team members to the natural flow and planning of software projects increases the team morale and subsequently augments the team performance. Scrum Masters possess another vital role in the Scrum Framework as they work as servant leaders for and with their Scrum Teams. Scrum Masters are trained facilitators to ensure flawless operation of their Scrum Teams. Sometimes they are master negotiators to protect their Scrum Teams from interruptions and fictive priorities of their stakeholders. Other times they are master communicators to remove or prevent known or anticipated impediments before these impediments bring their teams to dead-end streets. To only call a few of the responsibilities of Scrum Masters. We will cover more about the duties of various Scrum roles later. The Scrum Framework, in its pure form, is best suitable for highly independent, one team green field or brown field projects. However, the practical common sense of Scrum professionals did not stop there. With the introduction of additional roles and addendums such as “Chief Scrum Product Owner” and “Scaled Scrum”, it can be used within different project configurations too, including multi-team and geographically distributed project setups. We will cover more about these as well. For now stay tuned and keep on enjoying the lecture!

Pour voir la version vidéo : https://youtu.be/Y3IQ7IpKCKY ----- Ça y est, vous vous lancez dans l'agile... Bien sûr, ce sera avec Scrum. Mais comment faire sans Product Owner ? Revenons aux sources de l'agilité et voyons qu'il y a bien des manières de s'en sortir au-delà de Scrum, Product Owner ou non. Découvrez-en plus dans la description ci-dessous

Read the full Show Notes and search through the world’s largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website.  Confidence is one of the symptoms you are in the presence of a good Product Owner, when you add to that the ability to articulate the reasons for the decisions made as well as using data and analysis to support decisions, we know we have a great PO working with us.  We also talk about the consequences from creating an implicit or explicit competition between Product Owners. The Great Product Owner: The confident and articulate Product Owner A great Product Owner will have a clear Vision of their product, but that’s not the only characteristic they exhibit. They can also clearly defend their Vision, using data, and analysis they’ve made. They intimately understand their product, business and customers. As they move away from “guessing” as a practice, they are not afraid to have difficult conversations about the product.  The Bad Product Owner: The Feature Owner anti-pattern Let’s imagine that your company creates an internal competition among teams and Product Owners. What will happen then?  We discuss the consequences on the PO role that Jim has witnessed.  In this segment, we refer to the work by Daniel Vacanti.  Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at: bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate. About Jim Sammons Jim is currently a Professional Scrum Trainer with Scrum.org and works with an amazing team at Insight as an Agile Coach and trainer for their clients around the world. His time as a Scrum Master was awesome and fueled his passion for agility at all levels. You can link with Jim Sammons on LinkedIn and connect with Jim Sammons on Twitter.

Read the full Show Notes and search through the world’s largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website.  From a weak or lost Product Owner to one that cared deeply about the product, we explore some of the critical contrasts between good and not so good PO’s, as well as how Scrum Masters can help them improve. The Great Product Owner: The Product Owner that cared about the product When it happens, this Product Owner pattern can really help the team succeed. In this segment we talk about the Product Owner that cared deeply about the product. Made the Vision clear to the team and even if she did not know how to write User Stories (she got help from the Scrum Master), or about “limiting the work planned for the Sprint”, she was ready to learn. We also discuss how Scrum Masters can be really powerful allies for their Product Owners. The Bad Product Owner: The weak or lost Product Owner Although Martin has seen several Product Owner anti-patterns (the seagull PO, the absentee PO), the one he wants to highlight is the “weak or lost PO”. This anti-pattern is about the PO being only a mouthpiece for someone else, having little insight into what he asks from the team, and letting the team often without answers to their questions. In this segment, we also talk about how Scrum Masters can help these Product Owners overcome their anti-pattern. Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at: bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate. About Martin Lambert Martin's an agile coach, trainer and scrum master. He’s a Northener making a living in the south of England, and finds great energy and sense of purpose from the agile movement during the second act of his career. Loves the hills and being out on a road bike. And to all the European listeners, he says: "sorry for you know what". You can link with Martin Lambert on LinkedIn.

Read the full Show Notes and search through the world’s largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website.  Stanislava has shown a keen focus on people, and their interactions this week, and to finish off the week we talk about how to apply that focus in the Product Owner role. First as a learning process, and helping a team member gain trust in their abilities. Later we talk about the great Product Owner, one that was ready to listen to the team, and answer their questions. The Great Product Owner: Listening to the team As an example of a great Product Owner, Stanislava mentions the ability to listen. To pay attention to what the team needs, and to be available to answer questions when they arise in the team.  We also talk about how important it is for teams to ask questions, and how Scrum Masters can coach teams to learn how to ask questions from the Product Owner. The Bad Product Owner: Learning to be a Product Owner from scratch Sometimes the “bad” Product Owner, is a temporary situation for a team member that wants to take on a new role. In this segment, we talk about how we can help shy, and inexperienced team members learn a new role.  Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at: bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate. About Stanislava Potupchik Stanislava is not only a serious games facilitator and a team coach, but she also spends a considerable amount of time rock-climbing and hiking, traveling with her partner and son, and drawing zentangles. You can link with Stanislava Potupchik on LinkedIn and connect with Stanislava Potupchik on Twitter. 

Tips on how to delegate to improve your bottom line with Tim Francis I didn't know how to delegate and I didn't know how to lead and manage. What I discovered after my first failure with an assistant was that at least 50% of the problem was not with the assistant, but was with me. At the very top, which is what the surgeon focuses on and what I encourage entrepreneurs to focus on, is strategy, high-level skill, and high-level access. Everything below that we draw a delegation line and everything below that should be done by everyone else. Sooner or later there is going to be those rinse, wash, and repeat tasks that come up. They seem innocuous, but they really add up. The number one of the big six concerns when it comes to hiring an assistant was actually, I don't know how to trust and let go of control. I mean I am super passionate about a few things. One of which is actually our dinner parties. A horrible idea is going on Facebook and posting up, "Hey, who knows someone?" That's bad advice number one. Bad advice number two is hiring the first person that you meet, irrespective of how you find them. I actually think it's a great idea to go overseas if you are going to be delegating work that happens every week or every month and is a simple task that doesn't require a lot of decision making. But, to have someone with those three attributes, the culture, time zone, and language, you immediately solve at least 40% of the misunderstandings, maybe 50% of the misunderstandings that are happening. I think the other thing that people don't realize is how affordable it can be. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ HOW TO DELEGATE TO IMPROVE YOUR BOTTOM LINE [just click to tweet] HOW TO DELEGATE TO IMPROVE YOUR BOTTOM LINE I didn't know how to delegate. What I discovered was that at least 50% of the problem was not with the assistant, but was with me. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Doug: Hey welcome back another episode of Real Marketing Real Fast. Today in the studio I've got joining me, Tim Francis. Now Tim is a fellow Canadian, but he's also an NYU guest lecturer, certified Scrum Product Owner and lecturer at the University of Alberta. He's an award-winning entrepreneur and the founder of Profit Factory.com and the greatassistant.com. He's a graduate of the University of Alberta and in 2010, 2011 Tim was blindsided and he had a rare illness that left him unable to walk for three months. He nearly went bankrupt as a result of this, and he was re-forced to restart his business, and at that point, he promised himself that he'd never be a burnt out entrepreneur again. So I had a great conversation with Tim and we talked about why more entrepreneurs don't have assistants. I think you're really going to enjoy this episode. You're going to want to make sure that you stick around to the very end as Tim rolls out and shares with you how he got his humble start and the challenges that he had to overcome to build his business to be successful and what it is today. Doug: So I'd like to welcome Tim Francis to the Real Marketing Real Podcast today. Hey Tim, super-excited to have you to join me as part of the Real Marketing Real Fast Podcast today, so welcome to the show. Tim: Thanks for having me, Doug. Doug: So we start talking a little bit before we started recording and I asked you what your superpower was and I'd just like you to recap that because I think it's so valuable. I mean, we have entrepreneurs and C-level business and executive guys on here and often they feel overwhelmed, there's lots of details and stuff to do. So do you want to take a minute and just give us a little bit of background on what you're doing and how you help your clients be more successful? Tim: So I own a company called Great Assistant, and we help entrepreneurs to get a great executive virtual assistant that's coming out of corporate America.

Ways to do successful scrum Product Ownership when the business doesn't want to play that role

Ways to do successful scrum Product Ownership when the business doesn't want to play that role

Ep. #18: Over the past few years we’ve seen a growing trend of designer founded startups. There are a few really notable designer-founded startups like — Airbnb, Kickstarter and Lynda.com have paved the way… and in general startups are realize the value of user-centered design as a competitive differentiator, so there’s definitely more value placed on design and user experience. But the designer as founder is still not the norm for startups. This week I’m talking with designer-founder Will Sykora of Covailnt, to find out more about the benefits and challenges he's faced as a designer in the startup world. ​Will Sykora is a Product and UX Designer, and startup founder. When not focused on Covailnt, he works with companies to craft, validate, and focus their product experiences on their customers. Over the years, he's experienced the success that comes from putting people first, staying grounded in empathy, and delivering on customer needs to build great businesses. Will is well versed in LEAN, Design Thinking and the various flavors of Agile. He's a Certified Scrum Master and Scrum Product Owner, and holds a Masters in Technology Entrepreneurship from the University of Maryland.Check out Covailnt-- where freelancers go to find freelancers.Covailnt: https://covailnt.com/freelance_directory/will/LinkedIn: https://www.linkedin.com/in/willsykora/Website: http://www.willsykora.comConnect with us!Website: uxcake.coFacebookTwitterInstagramPodcast music by hip-hop band Eaters (song Cruziero, album Simian Samba) Hear their music on Facebook See acast.com/privacy for privacy and opt-out information.

  I don’t really dare to introduce Roman. He is such a big name in Agile Product Management. Since his beginnings in Scrum, he was totally focused: Scrum it will be, Product it will be - and everything that belongs to it. No more, no less. Clarity. In the field of Agile Product Management, he is really known for his great Scrum Product Owner courses, but also his books. His latest book is called Strategize and is all about product strategy. Unlike with many other books on strategy, what Roman accomplishes with his book, is to get the topic out of the vague. He gives clear cut advice in an otherwise often blurry topic. Knowing Roman for many years, it actually took me until this interview to actually decode one of his main qualities: Calm and certainty. Roman, in the best sense, gives you the clarity and certainty you expect from a teacher. While many teachers may bring you to the brink of doubt, Roman in a very calm, distinct and respectful way tells you what he found out to be the core of any topic he writes about. He really helps you to accept this things and go on with them. While I sometimes struggle and have to tell the world about all the different aspects of a topic, Roman already did all the thinking and came to a conclusion. And that helps. He does not leave out the rest of the truth, he just helps you to focus on the core and makes it easy to take the next step in your journey. I guess, it also has to do with his experience: he seen them all and has been in many contexts. He is running his brand as a business since 2006 and was amongst the first Certified Scrum Trainers in Europe. He really was amongst the pioneers and saw the potential when nothing was yet clear. He also writes a prominent blog on his website. These days, his focus is on leadership and product portfolio topics. It is also the topic of his newest blog posts on his blog. The Interview During the podcast we go through the following topics: What is a product strategy? Ways to work on product strategy in the context of new products Working on existing, mature products How to work with Roadmaps What was the writing process for Srrategize? What’s next from Roman? Citations Here some citations from the conversation: "The main challenge initially really is to get to a launch": On why focus and a minimal good enough product is needed in the beginning. "What good enough means, what minimal means, depends very much on the innovation we’re dealing with." "There is a correlation between the amount of time we spend on something and the level of attachment that results": On why it is psychologically so hard to change plans, even though we know it is necessary. "Two aspects are important: Do we have the right skills? And: are people empowered to do the product strategy work?" Often times, senior management is doing the product strategy work, which limits the strength and growth of the company. Management should do the business strategy and let the product department do the product strategy.“ Links  The home of Roman’s company  Roman's blog Roman’s LinkedIn Profile Lots of tools and resources that Roman invented and provides for free, e.g. the Product Vision Board template, a template for goal oriented GO Roadmaps, his Product Management Framework (a structured approach to ordering the disciplines and capabilities involved in product work) and much much more! Strategize - Roman’s latest book, self published in 2016. Buy it! Read it!  Agile Product Management with Scrum - Roman’s 2nd book, published with Addison Wesley in its Mike Cohn Signature Series, a German version is also available - Scrum: Agiles Projektmanagement erfolgreich einsetzen, published with d.punkt Oh, if you like the music in the background, it is my first try at doing the music myself.

Chris Oltyan, CEO of Rebric, has started and sold over nine companies and helped bring over 30 software products to market. A Certified Scrum Master and Scrum Product Owner, he is a strong advocate of agile and lean practices. See acast.com/privacy for privacy and opt-out information.