Scrum master
- 1. { Scrum Master Taller – UTN – FRT
- 2. Pablo Augusto Mazzeo Senior Scrum Master @ConveyArgentina Certified ScrumMaster @ScrumAlliance Certified Scrum Product Owner @ScrumAlliance Aprendiz Coaching Ontológico Profesional @ECP Your facilitators… Patricio Gaston Moreno QA Supervisor @ConveyArgentina Scrum Coach @ConveyArgentina Profesor @UTN-FRT Asociado @ScrumAlliance
- 3. Mastering is an art…
- 4. Be Agile, be different…
- 8. Leyes del Agilismo Ley de Parkinson “Las necesidades se expanden para ocupar todos los recursos disponibles” Ley de Hosftadter “Una tarea siempre dura más que de lo que esperas, incluso teniendo en cuenta la ley Hosftadter” Corolario: “Eres incapaz de estimar, asumelo”
- 9. Leyes del Agilismo Ley de Pareto “Para numerosos fenomenos el 20% de las causas probocan el 80% de los efectos”
- 10. Leyes del Agilismo Ley de Humphrey “Lo sabré cuando lo vea”
- 11. Leyes del Agilismo Ley de Brooks “Añadir más personas a un proyecto retrasado solo lo retrasa más”
- 12. Ley de Ziv “El desarrollo del software es impredicible y los requisitos nunca serán completamente comprendidos” Leyes del Agilismo
- 13. Leyes de Lehman “Cambio continuo: Un sistema debe ser continuamente adaptado o será cada vez menos satisfactorio para sus usuarios” “Complejidad creciente: La complejidad de un sistema crece salvo que se trabaje para tratar de reducirla” “Por cada 25% de incremento de complejidad en el problema se produce un 100% de complejidad en la solución” - Robert L. Glass Leyes del Agilismo
- 14. “Los clientes prefieren las malas noticias a las sorpresas” Leyes del Agilismo
- 20. We start so long ago…
- 25. Meetings Facilitating meetings for the team. This includes: preparing moderation postprocessing Holding retrospectives. Retrospectives are special meetings, therefore I count them separately. Things a SM do…
- 26. Team Dynamics Coaching team members (e.g. with one-on-one coachings). Mediating through conflicts. Helping the team to make decisions. Fostering the developer team’s self-organisation. Mediating the general conflict of goals between development team (high technical quality) and product owner (more features). Things a SM do…
- 27. Learning Continuing learning regarding everything Agile (e.g. visit user groups, attend conferences, read books, write blogs, etc.). Consulting team members regarding everything Agile. Helping the team to create information radiators. Giving feedback to the team. Encouraging the use of Agile Engineering Practices within the development team (this is a huge field to spent a Scrum Master’s time in, including e.g. one click releases, continuous delivery, feature flags, and many more). Challenge team with Agile management innovations (e.g. FedEx-Days). Exchanging constantly with other Scrum masters in the organisation (e.g. through community of practice). Doing Gemba Walks. Things a SM do…
- 28. Product Helping to write or split user stories. Helping to write or adapt product visions. Helping to order product backlog items. Helping with the release planning. Being familiar with the team’s work (i.e. the product). Things a SM do…
- 29. Big Picture Bringing people together who should talk to each other. Keeping in touch with every stakeholder regularly. Helping the team to report to management. Helping to further the Agile community within the organization. Organizing exchange events like Open Spaces or World Cafés for the team, its stakeholders, and its organisation. Sharing insights throughout the company (micro- blogging, blogging, internal conferences, etc.). Being a contact person for everyone in the team and their stakeholders regarding Agile. Giving learning opportunities to people in the organization (e.g. talks or workshops) and letting them learn important Agile concepts like e.g. technical debt. Things a SM do…
- 30. Change Helping the team to get rid of impediments. Suggesting new metrics for the team as catalysts for change. Mirror Reflecting Agile and Scrum values to the team. Reminding the team of their arrangements (e.g. policies). Helping the team to continuously improve their process. Reflecting issues to the team through observation from outside of the team. Asking open questions. Checking all the models the team uses (e.g. Sprint backlog, metrics, etc.) and show them differences between the model and the real world. Miscellaneous Helping the team to keep focus (e.g. by acting as a buffer between external distractions and the team). Helping the team to maintain their Scrum tools (Story board, Action board, charts, backlogs, etc.). Helping team and product owner to find a suitable definition of done definition of ready. Things a SM do… (final)
- 32. Waterfall Project Planning Project can be accurately planned in details
- 33. In reality, software projects are like… forecasting weather- rain or shine?
- 34. Planning WaterfallAgile All or noneIterative, incremental Prioritization is not importantPrioritization is key activity of planning Planning becomes a prioritization exercise Critical path is eliminated through time boxing Critical path is important PredictiveEmpirical
- 35. How to do prioritization? Informal MoSCoW Ad-hoc and intuitive Must have, Should have, Could have, Would not have Formal Priority = Business Value/Complexity ROI (= Business value – Cost) based prioritization Kano Mandatory, Linear, Exciter Threshold, Performance, Excitement
- 36. MoSCoW Must haves Should haves Minimum Usable SubseT for production (a.k.a. Minimum Viable Product) Important, but absence of it would not make the product useless Could haves Optional, if fund and time are available Would not haves Out of scope, defines the boundary of the product Pros and Cons?
- 37. Minimum Viable Product (MVP) Release#1 R#2 R#3 Expanding scope of MVP Release every sprint ideal
- 38. Kano Analysis Survey Q#1 Rate your satisfaction if the product has “this” feature? Q#2 Rate your satisfaction if the product does not have “this” feature? Answers: A) Like it, B) Neutral, C) Dislike it Additional Question for trade-off analysis How much extra would you pay for “this” or more of “this” feature?
- 39. Release Planning • Set a release goal • Determine scope through prioritization • Determine a release date • Define sprints • Allocate stories to sprints • Product backlog grooming • Ideally release every sprint
- 40. Sprint Planning Capacity Scope Estimation • Load factor • Availability factor • Holidays • Vacations • Set a sprint goal • Take stories from the top of the product backlog • Total points = Velocity • Task breakdown • Estimate tasks in actual hours or days • Assign task owners • Assign a story owner • Verify estimate against capacity
- 52. “Do Scrum By The Book Until You Get Good At It -then Adjust” Mike Cohn
- 53. Scrum Universe…
- 55. Grooming
- 56. Sprint 0 (zero)
- 57. LeSS…
- 58. Scrum of Scrums
- 61. Jeff’s Secret Sauce for Hyperproductivity How do you get started? (STABLE TEAMS) How do you successfully pull backlog items into a Sprint? (YESTERDAY'S WEATHER) How do you get stuff done? (SWARMING: ONE-PIECE CONTINUOUS FLOW) How do you deal with interruptions during the Sprint? (ILLEGITIMUS NON INTERRUPTUS) How do get defect free at the end of the Sprint? (DAILY CLEAN CODE) How do you deal with surprises? (EMERGENCY PROCEDURE) How do you ensure you continuously improve? (SCRUMMING THE SCRUM) How do you get teams to have fun? (HAPPINESS METRIC) How do you get hyperproductive? (TEAMS THAT FINISH EARLY ACCELERATE FASTER)
- 62. Library