Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Introduction to Scrum

Gianluca Costa
September 20, 2021

Introduction to Scrum

Creating software is an elegant mix of Art and Science.

However, its inherently unpredictable nature makes it much more difficult to organize and control: for example, how many times have you heard of delayed software releases all over the planet?

Tackling complexity is not always entirely feasible, but it anyway requires precision and a strategy.

We are now going to explore Scrum as a modern and effective process framework – focusing on software development.

Gianluca Costa

September 20, 2021
Tweet

More Decks by Gianluca Costa

Other Decks in Technology

Transcript

  1. Gianluca Costa
    Introduction to
    Scrum
    Scrum
    Latest update: 2021-09-20 gianlucacosta.info

    View full-size slide

  2. Introduction
    ● Creating software is an elegant mix of Art and
    Science

    However, its very nature is unpredictable, difficult
    to organize and control
    ● Tackling complexity is not always entirely
    feasible: how to define an effective strategy?

    View full-size slide

  3. About this presentation

    We are going to explore Scrum as a
    lightweight process framework

    Far from being a reference textbook,
    this is just an exploratory pamphlet

    For the official documentation,
    please consult the Scrum Guide,
    mentioned in the bibliography

    View full-size slide

  4. Waterfalls make gorgeous
    landscapes
    ...especially when there are pandas! ^__^
    However, waterfalls tend to be risky in
    the context of software development

    View full-size slide

  5. The waterfall model
    ● The original waterfall model is a one-way process:
    Requirements → Design → Implementation → Testing →
    Maintenance

    It is a simple and linear approach to problems, but its
    main drawback is the lack of feedback, which can
    lead to significant risks

    View full-size slide

  6. Waterfall...
    The basic waterfall model assumes that all the
    requirements are:
    ● perfectly known at the beginning of the project

    absolutely immutable
    →It expects a comprehensive design to be ready
    before the implementation phase

    View full-size slide

  7. ...and Software!
    On the contrary, software development is a craft
    often having:
    ● partially-defined and ever-changing requirements
    ● technological issues – for example, version
    compatibility when mixing or upgrading
    architectural components
    ● frequent obsolescence – as new patterns and
    more sophisticated technologies emerge

    View full-size slide

  8. Waterfall applied to software
    Requirements Deployment
    Stakeholders consulted
    only at the beginning
    of the waterfall process
    Is the product really
    what the stakeholders
    were expecting?
    +
    Issues found here are
    far more expensive
    How is the project evolving?
    The stakeholders know nothing
    about the development

    View full-size slide

  9. The major risks of pure waterfall
    A famous Internet picture is worth a thousand words

    View full-size slide

  10. Feedback-based waterfall
    Nowadays, even traditionally waterfall-based
    sectors, such as the ones requiring massive initial
    investments in machinery, actually start with:
    ● Simulations
    ● Prototypes
    in order to receive accurate feedback and enhance
    the initial design

    View full-size slide

  11. What is Scrum?
    «Scrum is a lightweight framework that helps
    people, teams and organizations generate value
    through adaptive solutions for complex problems»
    → not limited to software projects
    Scrum is part of the Agile movement, firmly focused
    on the principle that complex projects should rely
    not only on processes – but also and much more on
    human interactions and team playing

    View full-size slide

  12. The essence of Scrum

    First of all, Scrum is a lightweight framework –
    that is, a core set of rules capable of supporting a
    variety of additional elements

    Scrum is based on:
    – empiricism: knowledge comes from experience
    – lean thinking: optimization at different scales

    View full-size slide

  13. Inspect & Adapt

    The very heart of Scrum is the «inspect and
    adapt» binomial
    →Scrum is designed for constantly receiving
    feedback from every actor, as the goal is
    continuous improvement:
    – of the product
    – of the process itself

    View full-size slide

  14. History of Scrum
    While studying
    Optics, Alhazen
    is the first
    designer of a
    sort of scientific
    method
    ~1000 ~1600
    Galileo is the
    pivotal figure
    of the scientific
    revolution, as
    he defines
    the scientific
    method
    1986
    A few Scrum concepts are
    foreseen in an article by
    Hirotaka Takeuchi and
    Ikujiro Nonaka:
    the name «Scrum» is
    a reference to that
    article
    ~1950
    William
    Edwards
    Deming
    introduces
    the PDCA
    (Plan-Do-
    Check-Act)
    cyclic
    framework
    1995
    Scrum is
    presented – by
    Ken Schwaber
    and
    Jeff Sutherland

    View full-size slide

  15. Sprint
    Scrum Team
    (≤ 10)
    Scrum at a glance
    Scrum
    3 Roles
    Product
    Owner (1)
    Scrum
    Master (1)
    Developers
    3 Artifacts
    5 Events
    Product
    Backlog
    Sprint
    Backlog
    Increment
    Sprint Planning
    Daily Scrum
    Sprint Review
    Sprint Retrospective
    5 Values
    Commitment
    Courage
    Focus
    Openness
    Respect
    3 Pillars
    Transparency Inspection Adaptation

    View full-size slide

  16. Scrum Artifacts

    Scrum adopts an iterative, incremental approach
    focused on adding valuable features to a Product

    The purpose of the 3 prescribed artifacts is to
    foster transparency, thus enabling inspection
    and adaption

    View full-size slide

  17. Product Backlog

    A sort of “wish list” containing items that
    would improve the product
    ● Items at the top of the Product Backlog
    are more valuable, so they should be more
    refined and, consequently, short and ready
    to be implemented
    ● Visible and accessible to anyone

    View full-size slide

  18. User stories

    Product Backlog items describe features adding
    value to the Product, and usually consist of:
    – A short title
    – A description having the format «As a I want
    so that I can »
    – Acceptance criteria
    – Estimate of the required effort
    – One or more reasons why it is valuable

    View full-size slide

  19. Definition of Done
    ● Everyone must agree on a shared definition of
    Done → which, of course can evolve and become
    stricter over time
    ● There is no “Partially done”, in Scrum

    To foster clarity, the definition of Done should be
    as simple as a checklist

    View full-size slide

  20. Sprint Backlog
    Sprint
    Goal
    Items – mainly from the
    Product Backlog - that
    would contribute to the
    Sprint Goal
    Development
    plan

    View full-size slide

  21. User stories and Tasks
    ● User stories describe deliverable features and
    are focused on the user experience → stories
    deliver user value
    ● Tasks are units of work – activities that are
    required in order to implement a story → tasks are
    only known to the team as part of the
    development plan. There can also be technical
    tasks emerged from a Sprint Retrospective

    View full-size slide

  22. Increment

    The Increment is the set of all the Done items in
    the current Sprint and in the previous ones

    It is potentially releasable because of its high
    quality standards

    It can be released at any moment - not
    necessarily at a Sprint Review

    View full-size slide

  23. Further artifacts
    Further artifacts are not mandatory, but are often
    useful and widely employed:
    ● Task board: visible to everyone and containing at
    least 3 columns – To do, In progress, Done
    ● Burn-up / Burn-down charts: to quantitatively
    display and analyze how activities proceed over
    time

    View full-size slide

  24. The Scrum Team

    Scrum introduces the Scrum Team, with 3 accountabilities:
    – Product Owner → 1
    – Scrum Master → 1
    – Developer

    Scrum Teams usually consist of no more than 10 people

    Nothing prevents the Product Owner and the Scrum Master
    from also being developers

    Outside the Scrum Team, there are stakeholders - third
    parties interested in the Scrum Team’s work

    View full-size slide

  25. Product Owner
    Fine expert of the
    product and its market
    Has the vision on the
    product
    Must be a person,
    not a committee
    Sorts the items in the
    Product Backlog in a
    way that maximizes value
    Refines the Product
    Backlog, often with the help
    of the rest of the team
    Is always available for
    explaining the backlog items
    Represents the interests
    of the stakeholders
    Decides when to
    release an Increment
    Translates features
    into Product Backlog items
    P.O.

    View full-size slide

  26. Scrum Master
    Ensures that Scrum is
    correctly applied by the
    team and the company
    Constantly coaches the
    team, leading to a smoother
    and smoother process
    Maximizes the effectiveness
    of human interactions
    Teaches not only in terms
    of practices, but also
    in terms of Agile values
    Collaborates with the
    other Scrum masters
    in the company
    Removes impediments – of
    different nature – hampering
    the work of the developers
    Helps the stakeholders to
    interact with the Scrum Team
    S.M.
    Helps in expressing
    features as
    Product Backlog items

    View full-size slide

  27. Developers
    Self-organizing, just
    like the whole Scrum team
    The only actor entitled to
    defining the effort estimates
    of backlog items
    Cross-functional team – just like
    the whole Scrum team – including,
    for example, testing
    Team of equal peers,
    just like the whole
    Scrum team
    Focused on the actual
    creation of an Increment
    Dev.

    View full-size slide

  28. Scrum events

    Scrum events are time-boxed meetings → they
    have a maximum duration

    Given the empiricist nature of Scrum, shorter
    Sprints lead to more feedback and, therefore,
    more adaption
    – Furthermore, the stakeholders can have more
    visibility - thus making informed choices and
    controlling risk

    View full-size slide

  29. Sprint
    ● Duration: fixed, ≤1 month; most often, 2 weeks
    ● Goal: releasing a useful, potentially releasable
    Increment
    ● Container for all the other Scrum events

    There is no interval between consecutive Sprints

    View full-size slide

  30. Sprint Planning
    ● When: at the beginning of the Sprint
    ● Max duration: 8 hours for a 1-month Sprint
    ● Goal: defining the Sprint Backlog
    ● Who participates:
    – The whole Scrum Team
    – Anyone invited by the team to provide advice

    View full-size slide

  31. ● Phase 1: defining the Sprint Goal – why the Sprint
    would increase the Product value
    ● Phase 2: choosing the Product Backlog items that
    can be Done during the Sprint. This phase is
    mainly led by the developers, who must actually
    provide estimates, often on the basis of recent
    velocity metrics
    ● Phase 3: defining an implementation plan, often in
    the form of tasks; this is a duty of the developers
    Sprint Planning – 3 phases

    View full-size slide

  32. Daily Scrum
    ● When: every day; for simplicity, it should always be
    held at the same time and venue
    ● Max duration: 15 minutes
    ● Goal:
    – Promptly clarify and resolve impediments
    – Constantly adapt the Sprint Backlog to maximize
    effectiveness – to ensure that the Sprint Goal is reached
    ● Who must participate: the Developers

    View full-size slide

  33. Organizing the Daily Scrum

    The Daily Scrum must be kept short
    → Should issues be raised by one or more developers,
    solutions are discussed after the event
    ● Main topics for each participant:
    – What I did yesterday
    – What I’m going to do today
    – What impediments I noticed yesterday
    ● Format: arbitrary, often as fixed interview questions

    View full-size slide

  34. Sprint Review
    ● When: at the end of the Sprint
    ● Max duration: 4 hours for a 1-month Sprint
    ● Goal:
    – presenting the Increment to the stakeholders
    – actively interacting – it should not be just a
    presentation
    – considering future directions
    It is the public conclusion of the Sprint

    View full-size slide

  35. Sprint Retrospective
    ● When: at the end of the Sprint, just after the Sprint Review
    ● Max duration: 3 hours for a 1-month Sprint
    ● Goal: the Scrum team inspects the overall process. It is the
    private conclusion of the Sprint
    ● Focus on:
    – The tools, the process, perhaps even the Definition of Done
    – Positive aspects during the Sprint – also in terms of happiness
    – Problems and related solutions – that could become backlog
    items for the following Sprint

    View full-size slide

  36. Canceling a Sprint
    ● Canceling a Sprint is a traumatic event, that should
    only occur in case of drastic goal changes → since
    Sprints should be short, that is definitely rare
    ● No-one but the Product Owner can cancel a Sprint

    The developers must interrupt their work and
    rollback any non-Done activity

    It is usually good practice to still perform a Sprint
    Retrospective

    View full-size slide

  37. Why is Scrum challenging?

    Scrum actually consists of a minimalist set of
    rules that are very simple to understand

    However, Scrum is difficult to apply because:
    – It demands transparency – and therefore constant
    effort - during the whole development process
    – Its empiricism, based on a stream of feedback,
    highlights a wide variety of issues - implicitly
    requiring to address them

    View full-size slide

  38. Should everyone just adopt Scrum?

    First of all, it is essential to be aware that “adopting Scrum”
    requires compliance with its rules – otherwise, one
    would still be performing empiricist Agile, but not Scrum

    Most importantly, introducing any process framework
    without a careful strategy might be detrimental – so
    one must first ensure that one’s current scenario would
    actually benefit from Scrum

    Finally, the first Sprints might be rather inefficient – but
    the inspect and adapt binomial, if correctly applied, can
    quickly lead to improvements

    View full-size slide

  39. Last, but not least...
    ● Agile is more than a movement – it is a veritable
    universe

    You might well be interested in exploring other
    fascinating domains as well - such as Kanban
    ● Be creative! ^__^ Choose the pattern
    combination that best suits your needs!

    View full-size slide

  40. Conclusion
    ● This presentation introduced Scrum, with no claim of
    completeness: for details, please refer to the bibliography
    ● Scrum is an empiricist framework based on core concepts
    such as iterative and incremental approach, transparency,
    inspection, adaptation and constant feedback flow

    It is up to you to consider whether to introduce Scrum in your
    context – what matters is that you make informed choices,
    especially when choosing your methodologies

    View full-size slide

  41. Bibliography

    «The Scrum Guide» - from Scrum.org

    Introduction to Professional Scrum

    Scrum Alliance

    The professional ScrumMaster’s Handbook

    Agile Alliance

    View full-size slide

  42. Thanks for your attention! ^__^

    View full-size slide