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

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?

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

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

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

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

...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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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.

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

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

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

● 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

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

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

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

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

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

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

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

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!

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

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

Thanks for your attention! ^__^