Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Juan Banda - Certified Scrum Master slide deck


Published on

This slide deck contains topics covered in the CSM courses that I teach.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Juan Banda - Certified Scrum Master slide deck

  1. 1. Certified Scrum Master Juan Banda, CST
  2. 2. Agenda 1. Scrum Theory 2. Scrum Roles 3. Scrum Events and Artifacts Transparency 4. Sprint and Increment 5. Sprint Planning 6. Daily Scrum 7. Sprint Review 8. Sprint Retrospective 9. Product Backlog 10.Sprint Backlog 11.Definition of Done 12.SM Core Competencies 13.Service to the Development Team 14.Service to the PO 15.Service to the Organization 2
  3. 3. Scrum is a lightweight framework in which a cross-functional team develop products in an iterative, incremental manner
  4. 4. Like in the chess game, Scrum rules are simple to understand but then Scrum itself is difficult to master Photo by G CACAKIAN
  5. 5. Scrum can also be seen as a team-centric approach for building products. Because of this it is highly depending on context and people which make it not a good candidate for direct extrapolation
  6. 6. Core Elements of Scrum •Deliver a working product every sprint •Inspect and adapt every day •Trust the team
  7. 7. Scrum Values •Focus, Courage, Commitment, Openness and Respect •Abstract and difficult to cultivate but without them Scrum won’t work and the team won’t be a real team but just a collection of individuals instead
  8. 8. Scrum Values •For Scrum to work the Scrum Values got to be lived up by people in the three roles, and got to be present in the events and artifacts
  9. 9. Scrum Values •For instance, in the Sprint the Team needs to stay focused on the work, had the courage to innovate, commit to the Sprint Goal, be open to learn new things and be respectful to each other
  10. 10. Scrum Values are also the enablers that make a Scrum Team to stay unitedPhoto by Ice birdy
  11. 11. Empirical Process Control • Scrum implements an empirical process control based on observations of reality instead of ficticios plans • Therefore empiricism means working in a experience-based, fact-based, evidence-based fashion and not relaying just in up front created plans
  12. 12. Empirical Process Control • Empiricism is support by three pillars: Inspection, Adaptation and Transparency • Even though we have empiricism certain things −like Sprint duration, Team composition, and technology stack− are defined and should’t be changed once we start the Sprint
  13. 13. Empirical Process Control • Applying inspection and transparency we might decide to make some adaptations for the next Sprint or the next day • All in all in Scrum we try to keep the balance between empirical and defined and constantly bettering the defined side of things based on experimentation and empirical learning
  14. 14. Warning: if we take empiricism to an extreme then the system could become chaotic, and if we do the opposite and try to completely define the system it’ll be waterfall development again
  15. 15. Scrum is a Framework • By being defined as a framework Scrum can be extended, meaning that in reality is a meta-framework that incorporates empirical controls • And by being barely sufficiently defined it is suitable for product development where the scope, market and other variables will constantly change
  16. 16. Scrum is Agile Photo by eventuo
  17. 17. Framework vs Methodology • A methodology is a well defined set of steps and processes that follow a prescriptive order and if correctly applied guaranteed the outcome • A framework in the other hand is barely sufficiently defined and invites creativity and complementation with tools, ideas, and practices from other disciplines
  18. 18. In simple terms, a framework invites creativity and requires effective team work, a methodology invites compliance and requires effective control and supervision
  19. 19. Another key distinction is that in a methodology hard metrics are a fundamental piece whereas in a framework collaboration, team work, innovation and communication take precedence
  20. 20. Scrum Requires Dedicated Practice • Because Scrum is a lightweight framework easy to understand people and organizations tend to think that by making cosmetic changes and changing job titles they’ll get Scrum right • Quiet the opposite, Scrum requires study of not just Scrum but other ally disciplines and more importantly dedicate daily practice
  21. 21. Photo by Maxim Kushpel Is just not possible to get the benefits of Scrum without embracing it entirely and practicing it every day
  22. 22. Scrum Roles • The Scrum Team consist of a number (7 ± 2) of individuals on just these three roles: • Product Owner -> Only one (still one and still called Product Owner in LeSS) • Scrum Master -> Only one (still called Scrum Master in LeSS) • Development Team -> Several (just called Team in LeSS)
  23. 23. Product Owner Rights • Have the final saying on the Product Backlog order • Come to the Development Team frequently with a collaborative spirit and to see working software that is well crafted and runs on an integrated environment • Cancel the Sprint if she identifies that the Product Increment doesn’t make sense anymore
  24. 24. Product Owner Responsibilities • Maximizing ROI by identifying product features and translate them into a prioritized list also called Product Backlog • Making sure that the Product Backlog is visible, adaptive and clear for everybody • Connect directly Development Team questions with the customers that originated the requirements • Hold the space for the Product Vision • Keep the Product Backlog ordered and aligned with the business objectives
  25. 25. Scrum Master Rights •Call out the Scrum Team when she observes that they’re doing something different and calling it Scrum •Have support from executives and upper management to really change the system in which the Scrum Team operates •Try to extend the Scrum beyond and above the current team
  26. 26. Scrum Master Responsibilities • Foster a learning environment in which the Development Team members feel confortable experimenting, failing and learning • Changing Scrum Team and organization dynamics • Helping the Product Owner to effectively communicate internally and externally with the customer and the organization at large • Helping the Development Team to clear obstacles • Helping the Development Team to stay focused, close to the gemba, remove waste and avoid distractions
  27. 27. Development Team Rights • Feel contable saying “I don’t know but I want to learn” • Be capable of self organize and decide on its own how the work is going to be done • Invest time, effort, and energy to created a well crafted software product that make developers feel proud about their craftsmanship
  28. 28. Development Team Responsibilities • Learn a second, a third and if possible a fourth speciality so each team member can be more knowledgable and valuable for the team • Learn the customer domain specific language to communicate more effectively • Build software using modern engineering practices • Avoid wasteful work and processes that delay feedback and effective interaction with the customer • Voice their opinion when they feel overcommitted or feel that the product is going in the wrong direction
  29. 29. Development Team Characteristics •Long-lived -> same team members together over the years (not officially required in Scrum but highly recommended) •Co-located -> seated in the same table (not officially required in Scrum but highly recommended) •No formal managers -> who decides how the team works or what they work on •Self-organized -> they decide by themselves how to do the work •Empowered to make technical decision -> without the intervention of external actor like architects
  30. 30. Development Team Too Small or Too Big • Less than 3 team members won’t provide enough diversity of thought • With less than 3 team members product development might take too long because there are just too few developers • Beyond 9 team members coordination can become problematic and risk of duplication work and having idleness increases
  31. 31. PO is a Single Person • A single person instead of a committee shortens the decision making process and helps to keep product integrity • Similarly to what happens in Toyota with its Chief Engineer concept, centralizing product strategic decisions in the PO speeds up product development
  32. 32. A great PO needs to be really immersed on the market and anticipate its trends Photo by traqair57
  33. 33. PO Has Final Saying on the Product • Even though customers, clients, executives and users provide input on the product, it is the POs prerogative to decide on what goes in the Product Backlog and in what order • An empowered PO is entitle to make product decisions on her own
  34. 34. The Product Owner Has Final Saying on the Product •The PO has total responsibility of the value of the work carried by the team; in order to guarantee that the product is actually providing value short feedback loops are recommended •The PO collects feedback from different sources like the customer, the Development Team, the market, etc. and she analyzes and decides the direction for the product
  35. 35. Feedback is necessary for validating product hypothesis. The sooner feedback is received the betterPhoto by Alan Levine
  36. 36. Only the Product Owner Says What the Development Team Will Work on • The Development Team is composed of full timers that work on a single product at the time and the PO decides which goes in each Sprint; violating this rule will cause: • Team loosing focus and increasing switching cost • Too many distractions because work is coming from multiple sources causing delays, internal fighting, rework, and confusion of priorities
  37. 37. Scrum Events and Artifacts Transparency • In the Daily Scrum the Scrum Team will have the opportunity to sync-up for the day • Furthermore, they’ll have the chance to learn about what others are doing, hearing about the work and connect with themselves for starting the day • By being present in the moment in this event team members will effectively inspect the work, the team, impediments and make the necessary adaptations; of course for these to work team members need to fell comfortable saying things aloud in a very transparent manner
  38. 38. Scrum Events and Artifacts Transparency • In the Sprint Planning event team members have to be transparent about them not understanding the work that is supposed to be done and make clarifying questions to customers that where not made during Refinement • Also in this event inspecting that the Sprint Backlog has just enough detail and is highly visible will make it more achievable; adapting the plan instead of defending the plan will foster agility
  39. 39. Scrum Events and Artifacts Transparency • In the Sprint Review the customers need to have the opportunity to really inspect the Product Increment, the best way to do so is to allow customers to actually play with the product that is running in a live environment • Customers will provide more educate feedback after playing with the product and that will trigger better adaptations • Of course for these to work transparency from all participants is needed
  40. 40. Scrum Events and Artifacts Transparency • In the Sprint Retrospective the Scrum Team will voice their opinions about how the Sprint went for everybody; holding back opinions, critics or resentments won’t foster transparency and will be a more like a symptom of a dysfunctional team • Based on true transparency, the team can better inspect and propose the necessary adaptations in their practices, behaviors, internal process, etc. for the next Sprint
  41. 41. The Sprint is a fixed period of time −timeboxed to maximum 4 weeks− during which the team produces the Product Increment Photo by Anita Ritenour
  42. 42. Sprint Goal •Having a changing Sprint Goal might create the impression in the Development Team that they’re trying to create several disconnected features of a product •On the contrary, having an overarching goal that remains the same for the Sprint contributes to team alignment and product consistency •Also by not changing the Sprint Goal we contribute to customer’s understanding about what to expect at the end of the Sprint
  43. 43. Sprint and Increment • The output of each Sprint is a piece of well crafted software that meets the Definition of Done and is in usable condition; furthermore, it can be installed and run in a production environment • It is important because: • It allows to provide true feedback from customers • It makes evident the team’s real capacity and skillset • It takes the team one step closer to the product vision
  44. 44. Sprint and Increment • Releasing each Product Increment is a business decision that has many implications in other areas like legal, marketing, infrastructure, etc. and for this reason the PO might or might not decide to release at the end of each Sprint • Notwithstanding, the Development Team needs to keep adhering to the evolving Definition of Done to keep improving their development practices and discipline
  45. 45. Sprint Planning • In Sprint Planning One/Topic One the focus is understanding what we can to achieve and based on that understanding formulate the Sprint Goal •Tip: write down the Sprint Goal on a flip chart and keep it visible for the whole Sprint
  46. 46. Sprint Planning • Having a written and visible Sprint Goal can contribute to: • Helping visiting managers or customers to quickly answering to the question to what is the team’s current goal for the Sprint • Helping team members to stay aligned and working towards a goal that is greater than just the work at hand
  47. 47. Sprint Planning • In Sprint Planning Two/Topic Two, which is a design activity, the focus shifts to discuss how the Development Team is actually going to do the work, self-organizing about who is going to do what and estimating the work if the team feels that providing estimates will contribute some value •Tip 1: decompose the work into smaller pieces that can flow in a day or so
  48. 48. Daily Scrum • The Daily Scrum is different from a traditional status meeting because: • Is not intended to inspect progress based on oral status reports • Is not for talking about an initial fixed plan and if we’re still on schedule • Occurs on a circle with no laptops, very distant from the gemba and consequently reporting status will be totally subjective
  49. 49. Daily Scrum • This event has several constrains to support the Development Team: • Developers making the commitment to really focus and be present in the moment • Timeboxed for short duration • No blame and judgement • No bosses, everybody is in a peer relationship
  50. 50. Daily Scrum • There are several structures that can help the team to run this event within the 15 min time-box: • Talking around yesterday’s achievements, today’s goals and impediments if they exist • Co-located team meeting face-to-face • Parking lot discussions or questions for later
  51. 51. Sprint Review •There are certain activities in preparation and during this event such as: •Setting up the room and logistics to allow the customers to interact with the Product Increment •The Scrum Team closely observing how the customer interacts with the Product Increment •The PO addressing questions and comments about the connection between the business and the Product Increment •The Scrum Master facilitating the conversations and event flow
  52. 52. Sprint Review •The Sprint Review produce outcomes such us: • Validation that the product is going in the right direction so the team just need to persevere for the next Sprints • Indication that the product is not meeting customer needs or not effectively solving their problem so the team will need to pivot the product starting by adjusting the backlog • Realization of the real technical capabilities of the Development Team that allows it to deliver software that meets the Definition of Done
  53. 53. The true value of implemented items will be discovered when real customers can actually use them Photo by Chris
  54. 54. Sprint Retrospective • Some of the responsibilities for the Scrum Master in this event are: • Help the team to remain focused on the theme for this event which is inspecting the process and the environment • Keep the discussions balance between the positives and areas for improvement • Help the team concentrate the discussions around problems and not putting blame on particular team members • Keep the retrospectives alive using effective facilitation techniques and constantly innovating them
  55. 55. Product Backlog • For the Product Backlog the Product Owner is responsible for: • Leading its initial discovery with the participation of customers and key stakeholders • Keeping it alive and updated to reflect her current understanding of the product • Having it ordered so it contributes to putting the Development Team’s effort and capabilities in the right place
  56. 56. Product Backlog • For the Product Backlog the Scrum Master is responsible for: • Coaching the other roles in using it as a tool for communicating and executing valuable work • Coaching the PO so she together with the developer can keep it small and with just enough level of detail avoiding overinvesting time detailing and estimating every single item on it
  57. 57. Product Backlog • For the Product Backlog the Development Team is responsible for: • Providing estimates and reestimate to bring in reality • Refining it on the Product Backlog Refining event • Clarify its items by talking with whoever that came up with the requirement
  58. 58. Product Backlog • The Product Backlog has some essential characteristics: • It is dynamic and constantly changes based on learning from the team and discovery from the customers • It is ordered so the team better focus its energy on the most important items first • It is finite so is a attainable in a reasonable amount of time • It is public so everybody can see it and contribute to it
  59. 59. A useful metaphor is to see the Product Backlog as a grocery list as both share some essential characteristics
  60. 60. Product Backlog • Any Product Backlog Items has these attributes: • It is customer-oriented • It will contribute value to the product once implemented • It is not detailed in length using written documents, instead it will be ongoing conversations between developers and customers • It will be later decomposed into smaller pieces of work to incentivize flow within each Sprint
  61. 61. Photo by Paul Downey The Product Backlog contains items that are just placeholders for conversations that will need to occur
  62. 62. Sprint Backlog • The Sprint Backlog has these essential characteristics: • Its created by the Development Team and is actively used during the Sprint • It contains just primary information to not overcrowded it with too much detail • It can have estimates but those are just indicatives and not hard commitments
  63. 63. Sprint Backlog • The Sprint Backlog will more likely change as developers start to work on it • Developers are totally entitle to change task estimates, introduce new tasks, decompose further down or change tasks priorities • However, the PO needs to be consulted if developers feel the need to reduce the breadth or depth of the agreed scope
  64. 64. Definition of Done • Having a common Definition of Done across two teams is necessary because: • It’ll provide clarity for everybody about doneness and that will prevent misunderstandings • It’ll help teams to better communicate in code when everybody call done to the same thing • Even thought teams start from commonality each team can decide to make it Definition of Done even more strict
  65. 65. Definition of Done • The Scrum Team might decide to adapt its DoD when: • A team found more value making its own DoD more strict and wants to cross-pollinate the other team(s) • In the Retrospective is been observed by the team that the DoD is not strict enough or the opposite • In the Sprint Review the DoD is allowing items to be presented with technical or functional debt • In LeSS the DoD is considered a measurement of current team capability so it adapts as capability changes over time
  66. 66. Photo by Tor Hakon Half-baked items will hide all sorts of problems like quality and integration undone work
  67. 67. Definition of Done • The DoD is an essential component of Scrum because without it the Scrum Team might just be building incomplete items • A weaker DoD will trigger risks such us: • Qualifying half-baked items to the Sprint Review, items that customers will critique and disapprove • Creating the impression on developers that is fine to come short with implementation and cut corners
  68. 68. Definition of Done • One way to start creating a DoD is ask the team about what would be the quintessential elements that every item needs to have to be considered truly done • Summarizing those elements in a list on a flip chart that the team can see during the Sprint is a good way to remind everybody about the DoD
  69. 69. Scrum Master Core Competencies - Facilitation • The SM can facilitate for the Scrum Team in several ways that includes: • Help them communicate more effectively by discovering/ rediscovering the more effective communication tool: talking • Help them to recognize when is better to remain silent and hear and learn from who is talking • Help them recognize that for a true Scrum adoption the Scrum Team will need to change the system in which it lives
  70. 70. Scrum Master Core Competencies - Facilitation • Part of the facilitation includes group decision making and for these the SM can use techniques like: • Fist of Five • Voting using thumbs up/thumbs down • Dot voting on a flip chart • Taking an stand on the room (constellations) • Decider protocol
  71. 71. Scrum Master Core Competencies - Coaching • Facilitating means helping the team to reach conclusions and communicate more effectively • Teaching is showing others an skill with the expectation that they can also pick it • Mentoring is about taking on a mentee and informally pass experience and knowledge • Coaching is different from the others because it is connected to help others discover their own answers without telling them what to do
  72. 72. Scrum Master Core Competencies - Coaching • Self-organizing teams (LeSS prefers to call these self-managing teams) often times find challenges like: • Being so used to work in a command & control environment that they’re simply not prepare to self-organize • A system previously design with job titles, career paths, promotions, etc. that foster internal competition and jealousy • Team members that were former managers that are used to give orders and track progress but lack the skills to do technical work
  73. 73. Scrum Master Core Competencies - Coaching • A simple technique that can help self-organizing teams to overcome challenges consists in drawing a big X like this: • And then asking team members to individually write post-its for each dimension, then collectively review and discuss the pos-its Stop doing Start doing Let go Start believing in
  74. 74. Service to the Development Team • Servant-leadership basically inverts the tradicional hierarchical pyramid in which workers serve the manager; instead the aim for the servant-leader is to serve the workers so they can develop their true potential and enrich their lives • The SM is more align with this servant- leadership style
  75. 75. Service to the Development Team • The SM acts as a servant-leader for the Development Team when she: • Is a good listener and always be there for whoever that wants to talk • Helps people to remove their impediments • With intellectual humility acknowledges that she doesn’t know something but wants to learn • Asking dumb questions that everybody is afraid to ask
  76. 76. Scrum Masters are not ego- driven individuals that try to give orders to others Photo by fede 1845
  77. 77. 77 Warning: being a servant leader doesn’t mean updating everybody’s cards on a taskboard or always speaking for the team in meetings
  78. 78. Service to the Development Team •The SM as a servant-leader can improve the volunteering aspect of the team, a typical scenario (in Scrum but not in LeSS) is when during the Sprint Planning Two no one volunteers to take on a task and the SM put his name forward even though she doesn’t have the particular knowledge but is willing to learn •By showing this as a repetitive behavior other team members will eventually imitate it and find that is rewarding to volunteer, learn and have the appreciation of the rest of the team
  79. 79. Service to the Development Team • There are situations in which the PO or an stakeholder wants to put pressure on the team to speed up implementation • One way to deal with the situation is to invite the PO or stakeholder to analyze the impact in other variables (like quality, motivation, and collaboration) if the Development Team focuses in only going faster
  80. 80. Service to the Development Team • Quick and dirty implementations introduce what is call technical debt that is like an analogy connected to the financial world • Technical debt accumulated by the team eventually will need to be repaid and the more that the teams takes in repaying it the more interest it will accumulate • Code that works but is not well crafted is a common form of technical debt, not refactoring that code will eventually stop it from running and fixing it months or years down the road will be too costly
  81. 81. Service to the Development Team • Not knowing how to craft code that doesn’t introduce technical debt can be seeing as a form of knowledge debt • Organizations that are OK with just having code that just runs without caring if the code will cause trouble later or if the developers didn’t learn anything new by writing it, present a form of organization debt • Part of the job of the SM is to create awareness about these forms of debt and how to start repaying them
  82. 82. Service to the Development Team •eXtreme Programming development practices were proposed more than 20 years ago and they can (if used with discipline) help the team to reduce technical debt and craft a high-quality product increment •Some of the more relevant XP practices are: • Test Driven Development • Continuous Integration • Refactoring • On-site Customer • Small Releases
  83. 83. Service to the Development Team • Development practices may impact the ability of the Development Team to deliver a potentially releasable increment each Sprint in the following ways: • By building automated test that can execute in minutes multiple times a day guaranteeing that we have a tested integrated product • By incorporating the latest technical skills and knowledge of the developers in the code via refactoring • By incorporating shorter and shorter feedback loops via small releases that on-site customers can evaluate
  84. 84. Service to the Product Owner • The PO can use several collaboration techniques to work with the the Development Team or stakeholders, techniques such us: • Help the team to see the big picture about the product that they’re building by creating together a Product Roadmap • Discover what will go into the product with the stakeholders using User Story Mapping • Also with the stakeholders collaborate on strategic planning using Impact Mapping
  85. 85. Service to the Product Owner • The SM could support the PO by: • Advising senior management to implement necessary changes like conferring full product authority to the PO • Encouraging the Develpment Team to work frequently and consistently with the PO in the Product Backlog • Helping her to select the simplest but effective tools for her work
  86. 86. Service to the Organization • The SM can help the team responding to impediments by: • Constantly asking personally and in the Daily Scrum if there are any impediments • Keeping impediments somewhere visible for the team, like in a flip chart or somewhere on the wall • Helping team members talk about impediments and possible mitigations
  87. 87. Service to the Organization • There are however some organizational impediments outside the team that can affect its effectiveness, impediments like: • Too much bureaucracy • A command & control mentality that demands too many reports from the team • Imposed deadlines that were defined by someone external to the team • Pressure to meet deadlines sacrificing quality and affecting personal lives • Tendency to work by specialties siloing the knowledge
  88. 88. Service to the Organization • Eventually Scrum will require an organization redesign that will imply radical changes like: • No more PMO and Project Managers • No more QA Department • No more pool of resources • No more short term thinking and projects • No more outsourcing that creates teams split in several physical locations and time zones
  89. 89. Service to the Organization • In Scrum the Product Owner tracks and reports on teams work but only within the current Sprint boundaries • In general we completely deviate from Taylorism and its postulate that one creates the plan and the others just execute it • Some of the practices from project management can still be done but they got to be done by the Scrum Team and not by one single individual • Remember: Scrum is team-centric
  90. 90. The SM is an optimistic individual that believes that things can be changed for better
  91. 91. Service to the Organization • There are some stakeholder behaviors, that the Scrum Master can help to develop, and that can support the Scrum Team’s success, behaviors like: • Being available, involve and closely collaborate with the Scrum Team • Understand that quality doesn’t come for free • Don’t ask for every single feature in a product • Acknowledge adaptiveness in the product development cycle
  92. 92. Service to the Organization • Conversely there are other stakeholder behaviors that don’t support the Scrum Team’s success, behaviors such as: • Fire a requirement and forget about it until months after • Create proxy roles that introduce layers of separation from the Development Team • Insist on a fixed initial scope • Ask for precise estimates • Demand velocity
  93. 93. Service to the Organization • If the organization adopts Scrum only partially then it will be loosing benefits like: • The redesign of the organization to incorporate modern management • Repaying technical, knowledge, and organization debt • Developing people to their true potential • Competitive advantage to other smaller but more agile organizations
  94. 94. Books on Scrum
  95. 95. Books on eXtreme Programming
  96. 96. Books on Toyota
  97. 97. Books on Lean
  98. 98. Books on Technical Excellence
  99. 99. Books on Technical Excellence
  100. 100. Books on DevOps
  101. 101. Books on Management
  102. 102. BIG Idea 102 LeSS is and organizational design framework and systems thinking is one of its pillars
  103. 103. Why LeSS? 1. Create a learning organization 2. De-scale the organization 3. Simplify with a barely sufficient framework 4. Stick to the plot of: >Increasing adaptability >Increasing customer value 103
  104. 104. LeSS Framework 104
  105. 105. 105
  106. 106. @juanbandajara