Agile

• Scrum Framework
• Scrum Theory and Principles

Scrum Framework

TODO

• Take 2-day Course
• Review scrum.org website
• Study The Scrum Guide (Nov 2020)
• Take Practice Exams
• Purchase PSM I Assessment
• Take and pass the exam
• Professional Scrum Master Certified

Agile Manifesto

• Agile is a mindset
  • A cultural change, a different way of thinking
  • Scrum masters have to bring that thought to the team
  • It's not a time-management system, but a value-management system
• 4 Roles, 5 Events, 3 Artifacts
  • Understanding these is not enough, it takes a long time of experience to change your mindset
• Agile Culture
  • A red metric is when the Plan is >30% off of actual team performance... and the plan needs to be changed.
  • Team members are team contributors and focus on team success even if it means delaying or missing individual commitments
  • Teams are groups of people who collaborate to achieve a common goal. There is no lead.
  • Small increments of code, build, integrate
  • Failures are learning opportunities and points of improvement
• Predictive vs Empirical Process
  • Predictive is to make a plan and then follow it
  • Empirical is to update the plan as more information comes in (think of hurricane planning)
    • Divide and Conquer (break down large pieces of work or process or organization)
    • Inspect and Adapt (product, process, plan)
    • Create transparency (people work better when they have all the information)
• 4 Value Statements
  • We value Individuals and Interactions over Processes and Tools
    • Higher morale and better results when people are working together and collaborating in teams
  • We value Customer Collaboration over Contract Negotiation
    • Needs change over time... product needs to meet the needs not the requirements
    • To bring it down a level, we can say: Product Owner Collaboration over Acceptance Criteria Negotiation
  • We value Working Software over Comprehensive Documentation
    • We don't want our system to be delivered, shelved and never used
  • We value Responding to Change over Following a Plan
    • Adaptive planning
• 12 Principles of Agile Development
  • Customer-Related Principles 
    • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
    • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
    • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
      • Agile says work iteratively (first iteration could be 3 weeks, second one 4 weeks, etc.). In scrum, there needs to be cadence and consistency in length of iterations.
    • Business people and developers must work together daily throughout the project.
      • In scrum, the "Business Person" is the Product Owner
  • Business-Related Principles
    • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
    • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
    • Working product is the primary measure of progress.
      • If you finish the requirements, the design, the architecture, etc. you are still 0% done
      • Need to get things done really early
    • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
      • Because of scrum (and 2-week sprints), this one goes out the window... sometimes we overcommit to a sprint. Scrum Master needs to make sure they don't do that.
  • Team-Related Principles
    • Continuous attention to technical excellence and good design enhances agility.
    • Simplicity–the art of maximizing the amount of work not done–is essential.
    • The best architectures, requirements, and designs emerge from self-organizing teams.
    • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Scrum

Framework

• Why is it a Framework
  
  • Process - a sequence of procedures and activities with inputs, outputs, entrance criteria, exit criteria
  • Methodology - set of principles, tools, practices which can be used to guide processes
  • Framework - loose, but incomplete structure that describes a small set of elements and activities
• 4 Roles
  • Product Owner
  • Scrum Master
  • Developers
  • Stakeholders
• 5 Events
  • Sprint
  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective
• 3 Artifacts
  • Product Backlog
  • Sprint Backlog
  • Increment

Roles

Scrum Master

• Skillset:
  • Servant leader with a background in Agile and Scrum
  • Skilled in domain knowledge, coaching, facilitating, and teaching with a passion for delivery
• Responsibilities:
  • Scrum Team's expert and coach for Scrum
  • Ensures impediments that would prevent the Scrum Team from meeting its sprint goal are removed
  • Prevent the team from being distracted from internal or external sources
    • Internal like if the team is about to make a bad planning decision
    • External like if a manager is trying to pull people off the team
• Accountability:
  • Accountable for the scrum team's effectiveness
  • In service to the scrum team, product owner, organization
• Service
  • Not a team lead, but a facilitator

Product Owner

• Skillset:
  • Visionary with strong leadership and communication skills
  • Knowledgeable in customer needs and focused on maximizing value to stakeholders
• Responsibilities:
  • Maximize value of product and work by dev team
  • Clearly express backlog items
    • Daily and weekly grooming of the product backlog
  • Ensure product backlog is visible to all
  • Voice of the customer
  • Order items to achieve goals and missions
  • Optimize the value of the work
  • Ensure developers understand items in product backlog to level needed
  • Define acceptance criteria
  • Accept/Reject work results

Developers

• Scrum Team is 10 or fewer people
• Skillset:
  • Creative problem solvers with excellent communication skills
  • The ability to self direct while supporting a larger team
• Responsibilities:
  • Collaborate on solutions
  • Creates deliverable products
  • Mutual accountability
  • No sub-teams
  • Support Team Planning
  • Implement tasks in timebox
  • Minimize work in progress
  • Communicate needs and dependencies
  • Ensure quality products
  • Continuously learn.

Stakeholders

• Skillset:
  • Anyone affected by project or products that scrum teams are delivering
• Responsibilities:
  • Provide regular feedback
  • Attend demonstrations
  • Identify risks
  • Clearly articulate needs
  • Collaborate with other stakeholders and team
  • Respect others

Events

Introduction

• What makes events events is that they are timeboxed - they have a maximum duration
  • Sprints are events, but are special in that their timebox is both a maximum and a minimum

Sprint

• Heartbeat of Scrum
• Duration <= 1 Month
  • Most common is 2-weeks
• Result: Increment
• Next sprint begins immediately after conclusion of previous sprint
• No changes are made that endanger the sprint goal
• Quality goals do not decrease
• Scope may be re-negotiated between team and Product Owner
• Sprints may be cancelled if the sprint goal becomes obsolete - only the PO has the authority to cancel sprint

Sprint Planning

• 4-hour meeting for 2-week sprint
• Steps:
  1. Product Owner and team determine Sprint Goal
     • Might do that based on risk or based on priority or based on nothing at all - it's his call!
     • Sprint Goal is a user capability
  2. Product Owner suggests user stories for team to implement
     • User stories are "problems for the user to solve"
  3. Team reviews their velocity and capacity. Negotiates with Product Owner (Scrum Master may help)
     • Velocity: How many SP a team gets done in a sprint
  4. Team and PO agree on user stories to implement
  5. Team breaks user stories down into small tasks and create Sprint Backlog
  6. Scrum Team commits to the Sprint Goal
     • They aren't committing to the tasks or their stories or the backlog - they are committing to the Sprint Goal
     • Fist of five
• Topics
  1. Why is this Sprint Valuable?
  2. What can actually get done this sprint?
  3. How will we actually get this done?
• Inputs
  • "Ready" Product Backlog Items
  • Team Capacity
  • SME Input
  • User Story Acceptance Criteria
  • Current Product
  • Feedback from Demo
• Outputs:
  • Sprint Goal
  • Sprint Backlog
• Roles:
  • Product Owner: Offers sprint goal, any clarifications, negotiates scope
  • Developers: Decide how much work is brought into the sprint, break down work into small 1-day tasks that create a Sprint Backlog
  • Scrum Master: Facilitates dialogue between team and Product Owner, Maintains the timebox, Ensures developers don't over or under-commit

Daily Scrum

• 15-minute meeting
• Every day at the same time and place
• Goals
  • Intended for the team to plan their day (NOT a status meeting)
    • Throw out the questions to the whole team all at once - "Team, what did we get done yesterday"
    • Encourage collaboration
    • Make sure everyone is participating
    • "Team, what are we going to get done today?"
    • "Team, what impediments are we facing that will keep us from achieving our Sprint Goal"
    • Goal of the Scrum Master is: Team leaves with a plan for the day
  • Scrum Master facilitates but does not lead the meeting
  • Team discusses what was completed yesterday, what they plan to do today, and impediments blocking their Sprint Goal
• Benefits
  • Usually eliminates need for other meeting
  • Improves communications
  • Highlights impediments

Sprint Review

• 2 hours for a 2-week sprint
• Goals
  • Demonstration of what was accomplished during the Sprint
  • Only demonstrate capabilities that meet the team's Definition of Done
  • Capture feedback from stakeholders and talk about next steps
  • Not a presentation - minimal slides. Product or Service should be the focus
  • Product Owner is usually the host/presenter
  • Whole team should attend

Sprint Retrospective

• 2 hours for a 2-week sprint
• Goals
  • Inspect and adapt
  • Goal is to improve the product, process, and plan
  • Entire team discusses what worked well, what didn't work well, what they should stop doing, what they should continue doing, and what they should start doing

Product Backlog Refinement

• Not an event
• Product Owner brings stories to the team and gets their feedback - is it good? detailed? sized correctly? etc.
• Ongoing activity throughout the Sprint as often as the Product Owner deems necessary

Artifacts

Introduction

• Artifacts represent work or value for the user

Product Backlog

• Owned by Product Owner
• Product Owners build, maintain, prioritize, refine the backlog
• Ordered List of what is needed to improve the product
• The single source of work undertaken by the Scrum Team
• User-facing description of user value that contains Epics, Features, and User Stories
  • User Story - Small size (i.e. one sprint). Much detail.
  • Feature - Medium size. Less detail.
  • Epic - Large size. Minimal detail.
• Commitment: Product Goal
  • It is the "why" we are doing all this work

Sprint Backlog

• Set of product backlog items selected for the sprint
• Backlog items that can be completed within a sprint
• Commitment: Sprint Goal
  • Single objective for the Sprint
  • Highest priority in the Sprint (including in Sprint Planning and Daily Scrum)
• Commitment: Definition of Done
  • What do we need to do, as a team, to release value to our customers/stakeholders?
  • For a story to be done:
    • All of its acceptance criteria satisfied - each story has its own unique acceptance criteria
    •  

Scrum Theory and Principles

Scrum Theory

Introduction

• The foundation of Scrum is the Empirical Process
• Pillars are:
  • Transparency
  • Inspection
  • Adaptation

Transparency

• Openness between management and the team
  • Management is willing to speak good news and bad news to the team
  • Team is willing to speak good news and bad news to the team
• Information Radiators
  • What the team is working on and how they are working on it
  • Burndown Charts
  • Scrum Task Board

Inspection

• Reviewing the things that we've done

Adaptation

• Having done the inspection, what are we going to do about it?
• What are we going to change?

Scrum Core Principles

Self-Organization

• Agile teams don't have a lead
• Agile teams manage themselves
• Hackman's Four Levels of Teams
  • Manager-Led
  • Self-Organizing
  • Self-Designing
  • Self-Governing
• Team Topologies
  • Stream-aligned team
    • Focus on a single, impactful stream of work
  • Platform team
    • Platform teams create capabilities that can be used by many stream-aligned teams
  • Complicated-subsystem team
    • Builds and maintains a part of the system that depends on specific skills and knowledge
  • Enabling team
    • Specialists in a given technical or product domain - research and experiment and make informed suggestions

Collaboration

Value-Based Prioritization

Timebox

Iterative Development

Empirical Process Control

Scrum Values