Scrum Master Key points

AGILE MENIFESTO
Uncover better ways of developing software by doing & helping other to do to deliver values.
Prefer :

• Individuals & interactions overs Processes
• Working software over Comprehensive documentation
  (Bare minimum doc to focus on product)
• Customer collaboration over Contract negotiation (Charging for CRs)
• Responding to change over Following a Plan
  (Responding is NOT Taking every change
   BUT Analyzing impact and communicate the possibility to accommodate the change)

AGILE PRINCIPLES
  1. Satisfy the customer through early and continuous delivery of software
  2. Welcome changing requirements even late in development
  3. Deliver working software frequently
  4. Business people and developers work together daily throughout the project
  5. Build project around motivated individuals
  6. Working software as primary measure
  7. The sponsers, developers and users should be able maintain a constant pace
  8. Continuous attention to technical excellence and good design
  9. Simplicity - for maximizing the amount of work not done
 10. At regular intervals, the team reflects on how to become more effective and adjust its behavior accordingly.
  11. The best architecture, requirements and designs emerges from self-organizing teams
  12. Face-to-face communication with and within a team  


AGILE VALUES

• Trust
• Accountability
• High performance
• High Aims
• Sense of urgency
• Goal driven approach
• Self Growth & experience 

AGILE METHODOLOGIES AND FRAMEWORKS

• Scrum : Team collaboration
• SAFe : Scaled Agile framework
• XP : Design
• Kanban : Workflow / Workload management
• Battlefield Agility : used in Continuously changing environment
• AUP, Agile modelling : Requirement management
• DAD
• LeSS 
• Krystal 

SCRUM

• A Framework for Team collaboration to build complex projects with highest value productive and creative product
• written by 2 main authors : 
• Ken Schwaber (working with Mike Smith and Chris Martin)
• Jeff Sutherland (working with Jeff McKenna)
• Ken Schwaber and Jeff Sutherland first co-presented Scrum at the OOPSLA conference in 1995
• Lightweight, Simple to understand, Difficult to master  
• Scrum is founded on empirical process
•  asserts that knowledge comes from experience and making decisions based on what is known
• 3 pillars of empirical process control : 
• Transparency : Visibility to those who are responsible for the outcome
• Inspection : Frequently inspect progress toward a Sprint goal
• Adaptation : An adjustment must be made to minimize further deviation

• Scrum is NOT :
• A process or technique for building products
• Estimation technique
• Prioritization technique
• Requirements writing

• Why Scrum ?
• Gets early feedback, incorporates changes and improve accordingly

• Iterative model vs. Agile / Scrum
• + More focus on people
• + Customer collaboration

SCRUM MAIN PRINCIPLES

• Small shippable increments
• High quality working software
• Ongoing Integration during the development
• Cross-Functional team
• Self-managed & Self-Organized
• Customers : A shared journey
• Visibility 
  

SCRUM VALUES

• Focus
• Commitment
• Courage - To say No
• Openness
• Respect

SCRUM DISADVANTAGES

• Easy to understand, Hard to implement
• Partial adoption may be worse
• High risk of turnover
• Bad products will be delivered sooner, and doomed projects will fail faster
• Makes all dysfunction visible

SCRUM TEAM

• A Scrum Master, A Product Owner and A Development team
    1. Scrum Master (manages the process)
    2. Product Owner (decides what to do)
    3. Development Team (does the work)

• SM does not have to be in Daily scrum
• SM only has to ensure the Dev team has a Daily Scrum

TIME-BOXING

• Time-boxed events are events that have a maximum duration

DAILY SCRUM

• Fixed length - 15 minutes and does not change with the length of a Sprint
• held at the same time and place each day to reduce complexity
• Aim :
• To inspect the progress towards a sprint goal
• Objectives :
• To synchronize activities
• inspect the work since the last Daily Scrum
• forecast the work that could be done before the next one

• During meeting, Dev team member explains :
• What did I do yesterday ?
• What will I do today ?
• Any impediment that prevents from meeting the Sprint Goal ?

• Only mandatory in Daily scrum - Dev team
• If the SM or PO is also in the Dev team, they need to be there.
• If not, SM simply has to make sure the Dev team knows how to conduct a Daily Scrum and does so.

• Benefits of Daily Scrum : 
• improve communications
• identify impediments to development for removal
• highlight / promote quick decision-making
• improve the Development Team’s level of knowledge

SCRUM MASTER

• ensures that the Dev team has the Daily scrum
• SM is not responsible for conducting the Daily Scrum, Dev team is
• teaches the Dev team to keep the Daily Scrum within the 15-minute time-box
• enforces the rule that only Dev team members participate in the Daily Scrum
• SM facilitates and removes impediments serves a team in achieving the best productivity possible

DEV TEAM

• Cross-functional team (Designers, Developers, Testers...)
• Committed to delivering working units with clear business values
• Optimal Dev team size : 3 to 9
• Small enough to remain nimble and large enough to complete significant work
• < 3 Dev team members decreases interaction and results in smaller productivity gains
• > 9 members simply requires too much coordination
• should have all the skills needed to :
• Turn the Product Backlog items it selects into an increment of potentially releasable product functionality
• Cross-functional skills to create a product increment
• All Sprint Backlog items are "owned" by the entire Dev team, even though each one may be done by an individual development team member
• Must be as stable as possible for higher productivity / efficiency
• Responsible for managing the progress of work during a Sprint, Not SM

PRODUCT BACKLOG

• Ordered list of everything that might be needed in the product (Upcoming work)
• ordered by whatever is deemed most appropriate by the Product Owner.
• A single source of requirements for any changes.
• As long as a product exists, its Product Backlog also exists.
• Product backlog is Never complete, Dynamic, Constantly changing
• due to changes in business requirements, market conditions or technology
• A Living artifact / documentation

• Product owner is responsible for its content, availability and ordering.
• A product have 1 Product Backlog, regardless of how many teams are working on it
• can be filled from multiple sources (customers, stakeholders, users etc.)
• comprises of Requirements, Training, Technical evolution etc.

• Product backlog items has : 
• Description
• Order
• Estimate
• Value 

• Product backlog refinement
• Act of adding detail, estimates, and order to items
• Scrum Team decides how and when refinement is done.
• But, items can be updated at any time by the Product Owner

• Ordering
• Higher ordered items are clearer and more detailed than lower ordered items

• Estimation
• Dev team is responsible for all estimates. 

• "Ready" items
• Marked "Done" by Dev team within one sprint for selection in a Sprint planning.

SPRINT BACKLOG

• Set of Product Backlog items selected for the Sprint + Plan for delivering the product Increment
• Forecast by the Development Team, what functionality will be in the next Increment
• makes visible all of the work identified by Dev team necessary to meet the Sprint Goal
• A plan with enough detail
• Highly visible, Real-time picture of the work to accomplish during the Sprint

Working with Sprint backlog

• Only the Development Team can change its Sprint Backlog during a Sprint  
• Sprint Backlog emerges during sprint
• As new work is required, the Development Team adds it to the Sprint Backlog
• As work is performed or completed, the estimated remaining work is updated
• Unnecessary items are removed 

PRODUCT OWNER

• should know the most about the progress toward a business objective or a release
• sole person responsible for managing the Product Backlog
• ensures Product Backlog is visible, transparent and clear to all

•  Tasks and Roles of PO
• Work with customers/users/sponsors and understands customer needs
• User story workshops / sessions
• Acts as a bridge between Scrum team and customer
• Approves "DONE" 
• Clarifies requirements and scope
• Prioritize the requirements
• Guard of the team
• Authority to take decisions
• Define Product vision, Roadmap and Release planning
• manages Product backlog
• sets Release goal
• Evaluating ROI
• SBT decisions

SPRINT

• Fixed duration and cannot be shortened or lengthened.
• Length of a Sprint should be :
• Short enough to keep the business risk acceptable to the Product Owner.
• Short enough to be able to synchronize the development work with other business events.
• No more than one month (1-4 weeks)
  
• New Sprint starts immediately after the conclusion of the previous Sprint.
• Factors in deciding your sprint length :
• Length of release
• Amount of uncertainty
• How long priorities can stay unchanged
• Overhead of Sprint planning and Review

Sprint progress

• PO assess progress toward completing projected work by the desired time for the goal
• Tools to forecast progress : Burn-down, Burn-up, Cumulative flows

• Dev team tracks this total work remaining at least for every Daily Scrum
• By tracking the remaining work, Dev team can manage its progress

Sprint release

• The purpose of the Sprint :
• to deliver Increments of potentially releasable functionality
• to produce a done increment of working product

• Product increment
• should be usable and releasable 
• Not mandatory to be released on production at the end of every Sprint
• Product Owner may choose to immediately release it
• Sum of all the Product Backlog items completed during a Sprint
• At the end of a Sprint, the new Increment must be “Done”

• Definition of "Done"
• used to assess when work is complete on the product Increment
• Dev team must define a definition of "Done"
• If multiple scrum teams working together, all teams must mutually define it

Cancellation of Sprint 

• A Sprint can be cancelled (Abnormally terminated) before the Sprint time-box is over if the Sprint Goal becomes obsolete.
• This might occur if the company changes direction or if market or technology conditions change.

SPRINT REVIEW

• A 4 hour time-boxed meeting for one-month sprints
• For shorter Sprints, the event is usually shorter
• Attendees : Scrum Team + Stakeholders (invited by Product owner)
• Objective : To inspect the outcome of a Sprint and figure out what to do next
• Other activities :
• Dev team discusses :
• What went well during the Sprint
• What problems came into
• How those problems were solved

• Dev team gives demo of the work "done" 
• Product owner discusses the Product backlog

• Outcome : Revised Product backlog
• Scrum master ensures that the event takes place and teaches all to keep it within the time-box

SPRINT RETROSPECTIVE

• occurs after the Sprint review and prior to next Sprint planning
• 3 hours time-boxed for 1-month sprint
• For shorter Sprints, the event is usually shorter
• Objective : Scrum team inspect itself and create plan of improvement
• How the last Sprint went ?
• Identify items that went well
• Create a plan for implementing improvements in next sprint
• Scrum master ensures that the event takes place, teaches all to keep it within the time-box and encourage Scrum team to improve

ROLE OF MANAGEMENT IN SCRUM

• Management has no active role in the actual product development through Scrum.
• Management external to the Scrum team is incredibly important in setting the vision and strategy to guide the overall direction of the organization.

SOME SITUATIONS

Change of culture

• When an organization decides to adopt Scrum, but management wants to change the terminology to fit with terminology already used. It will likely to happen :
  A) Without a new vocabulary as a reminder of the change, very little change may actually happen.
  B) The organization may not understand what has changed with Scrum and the benefits of Scrum may be lost.
  C) Management may feel less anxious

Change of Sprint

• During a Sprint, a Development Team determines that it will not be able to finish the complete forecast. So during the Sprint, scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

Quality in Scrum

For good quality, any one of 3 must be adjusted :
 
In Scrum, 

• Activities are time-boxed = Time is fixed along with Budget is fixed
• Only Scope can be adjusted

Tuckman model

------------------------------------- Common task orientation ------------------------------------------>