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.

Transcript

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

   View 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 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 Slide

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

   View 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 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 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 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 Slide

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

   View 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 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 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 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 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 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 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 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 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 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 Slide

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

    View 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 Slide

41. Bibliography
    ●
    «The Scrum Guide» - from Scrum.org
    ●
    Introduction to Professional Scrum
    ●
    Scrum Alliance
    ●
    The professional ScrumMaster’s Handbook
    ●
    Agile Alliance
    

    View Slide

42. Thanks for your attention! ^__^
    

    View Slide