Scrum

[en] Scrum Basics.md

What is Scrum

• maximize performance by triage
• fixed time range called "time box"
• clarity: clarify what current problem is
• review: check progression related problem whether to carry on
• adaption: if the procedure has a problem or is able to improve, fix it
• minimum: 5 events,3 roles,3 prescriptions
• scrum rule: https://www.scrumguides.org

Scrum Values

• Commitment: Commitment of everyone towards own goals
• Courage: Brave approaches of 'Doing the right thing' mind toward puzzles
• Focus: Concentration of everyone to the tasks and goals
• Openness: Concensus over all the tasks and problems to be open
• Respect: Respect each other as competent self

Components of Scrum

Roles

Role 1: PO

• Takes in charge of 'What' of the product
• Role
  • Value Maximization
  • Product representative, at least 1 PO required per product
  • Backlog Admin
  • Final determiner of backlog ordering
  • Confirms the completion of the backlog
  • Consults Dev team(no interruption)
  • Collaborate with stakeholders
• Featured Missions
  • Shares Product Visions clearly
  • Decides the "Big Picture" of the release plan
  • Budget management
  • Backlog check & consultations (w/ users/stakeholders) over production orders or implementation timing
  • Renews backlog
  • Explains the contents of backlogs to stakeholders so they can understand
  • Confirms completion

Role 2: Dev team

• Takes in charge of 'How' of the product
• Roles
  • Actual production
  • Cross-functional: Able to do Requirement Analysis, Architecture, Development, Environments construction, Test, Documentation...
• Features
  • 3~9 members (No more than 9)
  • Able to produce a thing when assembled
  • No rank titles/sub-teams
  • Self-organized: Responsible for the product as a "Team" itself

Role 3: Scrum Master

• Roles
  • Works as a lubricant for F/W or the structure
  • Excludes external deterrents
  • Servant Leadership
  • Education, Facilitation, Coaching, Propellation of the Scrum
  • Not a manager nor admin(Not in charge of task allocation/progress management)
• Featured Missions
  • Makes PO/Dev team understand Scrum rules/outputs/procedures
  • Protects scrum members from external irritations
  • Promotes productivity-improving changes
  • Promotes the communication between PO and Dev team
  • Researches over the management of product backlog

Events

Event 1: Sprint

• Maximum 1 month, always the same period
• Becomes the container of the events below

Event 2: Planning

• Executed when starting a sprint
• Topic1: What PO wants + Maximum range of the Dev team
• Topic2: How the Dev team would implement
• Sprint goals: Brief summary of the goal of each sprint
• Refinement: Proposes concrete tasks for backlog, Clarifies unclear goals & questions, Task partition & time estimation

Event 3: Daily Scrum

• Maximum 15 mins nonetheless of number of members
• Everyday checks for goal achievements
• What was done yesterday, what to do today, any issues&concerns from the task
  • Only report issues & concerns, consult after daily scrum is over

Event 4: Sprint Review

• Conductor: PO
• Participants: All stakeholders of the product
• Objective: To get the feedback for the product
• Time: 4 hrs for 1-month sprint
• Essentials
  • Demonstration of the completion
  • Feedback (-> reflects to sprint backlog)
  • Check remaining tasks/progress
  • Explanation on incomplete tasks
• Add-ons
  • Discussion on Problems/Dilemmas in tasks
  • Explanation of PO about situation/business
  • Discussion on backlog candidates(whether to put into the backlog)
  • Predictions on release/task completion based on current progress

Event 5: Retrospective

• Recursion of the improvements
• If bug, improve the process where the bug occurred
• Revise sprint in terms of People, Relationship, Process, Tool respectively
• What was good & What to improve
• Next Action Suggestion
• Always gradual: No substantial change
• Time: 3 hrs for 1-month sprint

Outputs

Output 1: Product backlog

• Order of the back log != Absolute priority
• Backlog should always be renewed
• Top backlogs: Time estimation should have been done

Output 2: Sprint backlog

• Concrete TODOs for the sprint derived from Product backlog
• Each task consists of 1-day completion
• Could be added afterwards
• Task is selected by member(No designation for the tasks)

Output 3: Increment

• Achievement(completion) of the latest sprint + Overall of the previous sprints
• Operatable/Inspectable status(Not directly related to Release)
• Definition of Completion
  • Checkpoint for that sprint(Until where)
  • Consensus between PO and Dev team
  • Definition of the completion relies on the consensus

ScM.md

Goal

• Stimulate team to be self-organized team
• Become scrum coach and facilitator
• Make team get rid of its own obstacles for scrum sprints
• Have team responsible for their objectives(ScM is not responsible for)

Responsibility

• Support team to have common identity and actions for goals
• Defend dev team when needed
• Propel transparency and collaboration
• Keep on studying and considering Agile&Scrum to help others understanding those
• Facilitate scrum meetings
• Serve for team effectivity

Pitfalls on role combination

• w/ team member
  • Unable to see the team's blueprint
  • Unwilling to improve team's ability
  • with trust amongst members, able to point out team drawbacks
• w/ PO
  • Goals are standing against those of PO
  • Able to get closer approach towards team(members)
• w/ manager
  • Tend to untrust, not coaching, mentorings only
  • Quick migration process

Poisons of Scrum team

• Blaming(非難)
• Self-protection
• Building barriers
• Denouncement(罵る) →Depoisoning and calming down the atmosphere is one another role of ScM

ScM toolbox

• 守:Constant training - Natural action chains
• 破:In-depth understandings and considerations on Scrum adaptations
• 離:Setting apart from examples and external studies
• Root-Cause analysis: problem solution esp. for dealing with bugs
• Fishbone: 5Ws questions set
• SMART: Specific, Measurable, Agreement&achievable, Real, Timed
• Impact mapping
  • Why are we doing?
  • Who can implement?
  • In what way should the actions be changed?
  • What can be done to make impacts real?

Why scrum doesn't fit that well for my team for now

• Not developing new products/Large Scale Changes anymore
• Most of the tasks are experimental/metrics/platform maintenance
• 5~6 members with 2 products engaged, no full-time ScM provided...

What I thought

方法論の書籍でも技術書や取説のように「無批判的に受容すべし」の聖書か？

いわゆる「取説無誤説」