Introduction to agile development and scrum

Notes on some topics are omitted as they were also covered in places such as Introduction to DevOps.

Introduction

• Principles

  • Individuals and interactions over processes and tools

  • Working software over comprehensive documentation

  • Customer collaboration over contract negotiation

  • Responding to change over following a plan

• Scrum

  • Uses fixed-length (~2 week) iterations called sprints

  • Each sprint should produce a shippable increment

  • Steps

    • Plan the sprint and produce a sprint backlog

    • Daily scrum meetings

    • Sprint execution (do the work)

    • Sprint review (present the work and gather feedback)

    • Sprint retrospective (reflect on the sprint and identify areas for improvement)

    • Backlog refinement/grooming

    • Sprint closure

  • Roles

    • Product owner

      • Represents stakeholder interests

      • Articulates the vision

      • Defines and prioritizes the backlog

    • Scrum master

      • Facilitates the process

      • Removes impediments

      • Shields the team from external interference

      • Ideally not the team's manager

    • Scrum team/development team

      • The team should be self-organizing

      • Individual members choose tasks to work on from the sprint backlog

  • Artifacts

    • Product backlog

    • Sprint backlog

    • Done increment

• Kanban

  • Uses a continuous flow

  • Continuous delivery

  • No defined roles

  • Measures cycle time rather than velocity

  • Tasks can be changed at any time rather than being fixed for the duration of a sprint

• Teams should be loosely coupled but tightly aligned

• Each team should have its own business-aligned mission and own the end-to-end process, acting like a mini-startup

• Unsurprisingly, sticking sprints in the development part of a waterfall plan is not agile, despite what many companies claim

Planning

• You can't plan everything upfront as that's when you know the least

  • There was a "navigating through penguins" analogy, which was better than I expected given the premise

• Don't just naively translate traditional roles to Scrum

  • Product managers are not product owners

  • Project managers are not scrum masters

  • Development teams are not scrum teams

• Consider ZenHub, which allows you to integrate project-management functionality with GitHub

• Stories

  • Description of the need and business value

  • Any details/assumptions

  • A definition of "done"

• If it would be too big for a single sprint then it would be an epic instead

• Backlog items tend to be epics, which can then be broken down into stories for a sprint

• Story points

  • Abstraction measuring how big a task is in terms of effort, complexity, and uncertainty

  • Think t-shirt sizes (is this small? medium? large?) rather than specific time estimates

  • Often based on Fibonacci numbers

  • It can be useful to have a reference story (e.g., a medium-sized story that you've scored as a five)

• Refining the backlog

  • Rank by priority

  • The highest-priority stories should be broken down into ones small enough to fit in a sprint

  • Can be useful to have a dev representative present when refining in addition to the product owner and scrum master

• Team velocity is the number of story points per sprint

Execution

• Developers should assign themselves the highest-priority story from the sprint backlog that is appropriate for them

• You shouldn't have more than one story at once unless you're blocked

• Daily scrums are not a status update for the product owner; the product owner can be there to answer questions, but they're not there to ask them

• Each person's update covers

  • What did I do yesterday?

  • What will I do today?

  • Are there any blockers?

• Discussion of any new topics should wait until after the meeting

• Burndown charts show how the proportion of the story points that have been completed changes over time

• The sprint review is a demo for the product owner and stakeholders

• The sprint retrospective answers three questions

  • What went well?

  • What didn't go well?

  • What should we change for the next sprint?

• The retrospective should usually be limited to the scrum master and the development team