$30 off During Our Annual Pro Sale. View Details »

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

  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?
  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
  4. Waterfalls make gorgeous landscapes ...especially when there are pandas! ^__^

    However, waterfalls tend to be risky in the context of software development
  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
  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
  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
  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
  9. The major risks of pure waterfall A famous Internet picture

    is worth a thousand words
  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
  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
  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
  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
  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
  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
  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
  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
  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 <role> I want <a feature> so that I can <do something useful>» – Acceptance criteria – Estimate of the required effort – One or more reasons why it is valuable
  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
  20. Sprint Backlog Sprint Goal Items – mainly from the Product

    Backlog - that would contribute to the Sprint Goal Development plan
  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
  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
  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
  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
  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.
  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
  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.
  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
  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
  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
  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
  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
  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
  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
  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
  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
  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
  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
  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!
  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
  41. Bibliography • «The Scrum Guide» - from Scrum.org • Introduction

    to Professional Scrum • Scrum Alliance • The professional ScrumMaster’s Handbook • Agile Alliance
  42. Thanks for your attention! ^__^