Introduction to Scrum

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.

84cfa5aa96405be9af4874ba266785af?s=128

Gianluca Costa

January 23, 2018
Tweet

Transcript

  1. Gianluca Costa Introduction to Scrum Scrum http://gianlucacosta.info/

  2. Introduction • 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
  3. About this presentation • We are now going to explore

    Scrum as a modern and interesting process framework – focusing on software development • This is not a textbook on management, but an exploratory pamphlet: there are no silver bullets in the world, so it’s up to you to decide if Scrum – just like any other idea – can be effective in your company’s scenarios • This presentation was inspired by the interesting material that you can find in the bibliography
  4. Waterfalls make gorgeous landscapes ...especially when they have pandas! ^__^!

    Most unfortunately, they tend to be risky when it comes to software development
  5. The waterfall model • The original waterfall model describes a

    one-way production process: Requirements→Design→Implementation→Test→Maintenance • It is a simple and linear approach to problems, but its main drawback is the lack of feedback. →even sectors that traditionally adopted a waterfall-based approach, such as the ones requiring massive initial investments in machinery, actually start with simulations and prototypes, in order to receive accurate feedback and enhance the design
  6. Waterfall and Software • The theoretical waterfall model assumes that:

    – all the requirements are perfectly known at the beginning of the project – all the requirements are stable and immutable – the tasks to perform can be designed by someone – and then executed by someone else (usually a manufacturing robot, for example) • On the contrary, the software domain is quite often: – Nuanced: there can be vague requirements, to refine as the project goes on – Fast-moving: requirements can change at lightning speed, even in weeks – Difficult to predict – as technological trends considerably vary – A craft, difficult to monitor in terms of productivity: good metrics could be customer satisfaction and code design clarity – which leads to the valuable Protected Variations GRASP pattern
  7. The major risks of pure waterfall A famous Internet picture

    is worth a thousand words:
  8. The major risks of pure waterfall - Explained • In

    the plain waterfall model, the stakeholders are only consulted during the first phase (Requirements) • Consequently, the final result could well be what was expected – or sometimes not • On the other hand, involving stakeholders – and showing them a partial product having a subset of working features – is a strategy that can effectively drive the overall process to satisfy actual needs, therefore creating software that is valuable at any moment
  9. Waterfall as the root of all evil? • Of course

    not – in order to be healthy and competitive, any enterprise requires: – Skilled professionals – Team playing – Competent management – A vision • Given the above requirements, the choice of methodology depends on specific factors of the company, of the customers, … • The world is nuanced: for example, a waterfall model can also be customized to become a simple iterative approach – e.g., by introducing checkpoints (i.e., milestones) to receive feedback from the stakeholders • In the very end, no methodology can replace software quality
  10. What is Scrum? «Scrum is an Agile framework for completing

    complex projects. Scrum originally was formalized for software development projects, but it works well for any complex, innovative scope of work. The possibilities are endless. The Scrum framework is deceptively simple.» - Scrum Alliance →Scrum is part of the Agile movement, firmly focused on the fact that complex projects should rely not only on impersonal processes – but much more on human interactions and team playing
  11. The essence of Scrum • First of all, Scrum is

    a lightweight framework – that is, a simple set of rules – which is why its essence is described in a document whose subtitle is «The Rules of the Game» • As a framework, it can coexist with almost any development process you may have already chosen (including XP, Kanban, Lean, ...) – actually enhancing it • The very core of Scrum is empiricism – just like Science.
  12. Empiricism • The scientific method is constantly based on observing

    reality, creating models to explain it - and verifying them→Iterative process • Empiricism = asserting that knowledge – and, consequently, decisions - ultimately derive from experience. It is especially effective when we do not know the exact solution to a problem • One of the focus points around which Scrum revolves is the «inspect and adapt» binomial, that is found in almost every aspect of the framework →Scrum is designed for constantly receiving feedback (from the clients, from the business, from the team), and the goal is continuous improvement – not only of the product, but also of the process itself
  13. History of Scrum • The empiricist heart of Scrum dates

    back to centuries ago: 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 derives as a reference to that article ~1950 William Edwards Deming introduces the PDCA (Plan-Do- Check-Act) cyclic framework 1995 Scrum is presented – by Jeff Sutherland and Ken Schwaber
  14. Sprint Scrum Team Scrum at a glance Scrum Roles Product

    Owner (x1) Scrum Master (x1) Dev. Team Member (x5-7) Artifacts Events Product Backlog Sprint Backlog Increment Sprint Planning Daily Scrum Sprint Review Sprint Retrospective Values Commitment Courage Focus Openness Respect Pillars Transparency Inspection Adaptation
  15. Scrum Artifacts • Scrum fosters an iterative and incremental approach

    focused on adding valuable, useful features to a product • The purpose of the 3 prescribed artifacts is to foster transparency, enabling inspection and adaption • The expected artifacts are: – Product Backlog – Sprint Backlog – Increment
  16. Product Backlog • Single source of requirements for the product

    →a sort of “wish list” expressed by the stakeholders via the Product Owner • Features are expressed as user stories sorted by decreasing importance • Stories closer to the top of the Product Backlog are more valuable, so they should be short and well-defined – ready to be implemented • Its lifespan coincides with the lifespan of the product – usually, the more successful the product, the more dynamic its Product Backlog • Is visible and accessible to anyone, but can only be edited by the Product Owner → however, despite some possible influence of the Product Owner, estimates are always performed by the Development Team • The Product Owner must constantly revise, refine and clarify its stories
  17. User stories • Each user story is about a feature

    – something that creates value for the user – and, consequently, for the company • Each user story is usually characterized by: – A short title – A description having the format «As a <role> I want a <feature> so that I can <do something useful>» – Acceptance criteria, based on the team’s definition of Done – First estimate of the required effort →the precise estimate will be performed later, by the Development Team – One or more reasons why it is valuable (including advantages for the company itself)
  18. Sprint Backlog • Contains the user stories - at the

    top of the Product Backlog – that the Development Team is implementing in the current Sprint • All the stories in the Sprint Backlog are locked within the Product Backlog as well: they can be neither moved nor edited • Each story in the Sprint Backlog is also expressed as a sequence of tasks (i.e., activities) required to implement it →such sequence of tasks is not locked, because it is does not pertain to stakeholders – so it can be arbitrarily revised • Only the Development Team can change its tasks • The Development Team should also periodically update the progress status, in order to provide a transparent picture of their activity
  19. 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
  20. Increment • The Increment is the set of all the

    Done stories in the current Sprint and in the previous ones →therefore, increments have an associated value • An Increment might not be released, but it’s potentially shippable, as its quality standards must remain very high
  21. 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, Doing, Done – Burn charts: to quantitatively display and analyze how activities proceed over time
  22. The Scrum Team • Scrum introduces the concept of Scrum

    Team, which is self- organizing, fairly autonomous and cross-functional • Within each Scrum team, there are 3 roles: – Product Owner → 1 – Scrum Master → 1 – Development Team (DevTeam) member → from 5 to 9 • Outside the Scrum Team, there are stakeholders: – The company managers and business teams – Customers – Other parties interested in the Scrum Team’s work
  23. Product Owner Fine expert of the product and its market

    Has the vision on the product – from its origin to its possible evolutions Must drive the team to reach a product having maximum value Is the owner of the Product Backlog and controls its items’ order Is the only one in the company who can assign work to the DevTeam Ensures that the whole team understands the requirements Is always available for explaining the requirements Represents the interests of the customers – and of the business Creates the acceptance criteria for the items in the Product Backlog Is the ultimate responsible for the outcome of the product Translates the requirements into User Stories, that are the items of the Product Backlog
  24. Definition of Done • Scrum is empirical, so it is

    paramount to make results constantly visible and inspectable • Everyone (team, stakeholders, ...) must agree on a shared definition of Done, to prevent frequent misunderstanding • Each user story can be considered Done when it adds value to the product, with high quality standards • To foster clarity, it would be a great idea to print out the definition of Done as a checklist
  25. Scrum Master Ensures that Scrum is correctly applied by the

    team and the company Suggests more efficient ways of organizing the Product Backlog Constantly coaches the team, leading to a smoother and smoother process Leads the team to higher levels of performance Maximizes the effectiveness of human interactions Teaches not only in terms of practices, but also in terms of Agile values Is not a “project manager” in the pure waterfall sense Helps the Product Owner to communicate requirements Collaborates with the other Scrum masters in the company Removes impediments – of different nature – hampering the work of the DevTeam Helps the business and stakeholders in general to interact with the Scrum Team Distinguishes between 2 kinds of impediment: project constraints and company dysfunctions
  26. Development Team They create valuable product increments by implementing user

    stories Self-organizing: after committing to user stories at the beginning of a Sprint, they autonomously decide how to organize their activity Is the only actor in charge of defining the schedule/effort estimates of the user stories The whole team is accountable for the success/failure of their activity Despite being highly-skilled specialists, they also try to be as cross-functional as possible All members are equal peers in terms of Scrum rules, no matter their actual work The Scrum Master tells them how to apply Scrum and suggests ideas for smoother operations, but cannot tell them how to actually work Must focus on the development of the product – while the Scrum Master removes impediments
  27. Scrum events • The benefits of Scrum events are twofold:

    – They create regularity →fostering control over chaos – They make additional meetings unnecessary by construction • Scrum events are time-boxed →they have a maximum duration – In the case of the Sprint, the duration is fixed at the beginning - even better, all Sprints could have the same, short duration (usually 1 or 2 weeks) – All the other events can last just as required – but no more than the maximum duration • Considering the empiricist nature of Scrum, shorter Sprints lead to more feedback and, therefore, more adaptation • Furthermore, the business can have more visibility and can make informed choices
  28. Sprint • Max duration: 1 month. 2 weeks or 1

    week often preferred • Goal: releasing a useful, potentially shippable increment of the product → it is like a short-term project • Container for all the other Scrum events → the life of the product is divided into an uninterrupted sequence of Sprints: they are actually subsequent Agile and incremental iterations • The quality goals of the Sprint cannot be lowered – but the scope can be renegotiated, usually just for clarifying details and only between the Product Owner and the Development Team →additional work can only be requested by the DevTeam
  29. Sprint Planning • When: at the beginning of the Sprint

    • Max duration: 8 hours for a 1-month Sprint • Goal: defining the work for the current Sprint, in the form of a Sprint Backlog • Who participates: – The Product Owner and the Development Team have a very active role – The Scrum Master mediates and ensures everything runs smooth and time-boxed – Specialists, mainly when the features concern complex domain aspects – Stakeholders can participate as spectators
  30. Sprint Planning – Phase 1 • Phase 1: commitment to

    a set of deliverables – Led by: the Product Owner – Core question: What are we going to do? – What happens: A negotiation: • The Product Owner lists the user stories that considers more valuable – i.e., that should be Done during the opening Sprint • The Development Team reviews such stories, the related acceptance criteria and whether they can all be Done. In the end, the Development Team commits to delivering the negotiated set of user stories – Goal: defining the current Sprint Goal, which describes how the Sprint is valuable
  31. Sprint Planning – Phase 2 • Phase 2: defining the

    actual tasks – Led by: the Development Team – Core question: How are we going to achieve the Sprint Goal? – The whole Scrum Team discusses how each user story can actually be implemented → Stories are expressed as tentative sequences of tasks – While decomposing stories into tasks, it might happen to discover that one or more stories are actually not feasible during the Sprint – this can lead to: • Splitting stories into more stories, some of which can be delayed to subsequent Sprints • Renegotiating the stories to be Done during the Sprint – actually performing a sort of iteration between Phase 1 and Phase 2
  32. After the Sprint Planning • The output of the Sprint

    Planning is the Scrum Artifact called Sprint Backlog – which is a subset of the Product Backlog • The corresponding stories in the Product Backlog are locked for all the duration of the Sprint – the Product Owner cannot edit them • The work for the Sprint begins immediately after the Sprint Planning
  33. Daily Scrum • When: every day, except the days of

    Sprint Planning. It should always be at the same time • Max duration: 15 minutes • Goal: optimizing the probability of achieving the Sprint Goal by inspecting the situation in order to detect and solve problems • Who participates: open to anyone, but only the Scrum Team has an active role
  34. Organizing the Daily Scrum • The Daily Scrum must be

    short – It is a duty of the Scrum Master to ensure this condition – Considering that the development team includes 7±2 people, each person has about 2 minutes – Should issues be raised by one or more team members, solutions are discussed, by all the involved parties, after the meeting • Main topics: – What I did yesterday – What I’m going to do today – What impediments I noticed yesterday • Format: arbitrary. Common choices are free-form dialog or fixed interview questions
  35. Sprint Review • When: at the end of a Sprint

    • Max duration: 4 hours for a 1-month Sprint • Goal: informally showing the stakeholders what was Done during the Sprint. It is the public conclusion of the Sprint • Who participates: everyone actively takes part in the review, according to the different roles
  36. Sprint Review – Main activities • The Product Owner explains

    what was Done – and what was not feasible • The Development Team usually: – Shows a demo of the new features – Briefly describes the main problems encountered, and the solutions found • The stakeholders: – Provide feedback – Ask questions • The Scrum Master: – Focuses on any organizational issues and the related solutions – Ensures that everything runs smoothly, especially in terms of communication • Everyone debates on the product and on possible new features to add to the Product Backlog
  37. Sprint Retrospective • When: at the end of a Sprint,

    just after the Sprint Review • Max duration: 3 hours for a 1-month Sprint • Goal: the Scrum Team inspects their overall process. It is the private conclusion of the Sprint • Focus on: – The team itself, the relationships, the tools, the methodology – Highlighting what was learned and new positive aspects during the Sprint – Identifying problems in the development process and proposing solutions – Fostering not only productivity, but also enjoyability and happiness • Generally speaking, just 2 or 3 ideas are approved – as they are immediately applied to the new Sprint
  38. Canceling a Sprint • Canceling a running Sprint is quite

    a traumatic event, that should only occur in case of drastic goal changes →since Sprints should be short, that’s fairly rare • No-one but the Product Owner can cancel a Sprint • The Development Team must interrupt their work and rollback any non-Done activity. →Done artifacts are to be reviewed, one by one, by the Product Owner in the light of the new goals • It is usually good practice to still perform a Sprint Retrospective
  39. Why is Scrum challenging? • Scrum actually consists of a

    basic set of rules that are very simple to understand • However, Scrum is difficult to apply because: – It demands transparency during the whole development process – an approach that demands constant effort (and the presence of daily meetings is a frequent subject of criticism) – Its empiricism, based on a stream of feedback from everyone, brings issues – of different nature – to the surface, implicitly requiring to address them
  40. Should you adopt Scrum? • Should your team or your

    company adopt Scrum? →Answering this question is up to you • First of all, you must be aware that «adopting Scrum» requires compliance with its rule book – otherwise, you are still performing empiricist Agile, but not Scrum • Most important, introducing a process framework without careful pondering might be detrimental – so you must be sure that your current scenario actually supports Scrum’s approach • Finally, please remember that the first period might be rather inefficient – but the inspect and adapt binomial, if correctly applied, can actually enhance the situation quite quickly
  41. Conclusion • This presentation introduced Scrum, with no claim of

    completeness: for details, please refer to the bibliography • Scrum is an empiricist framework based on paramount 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 working context – what matters is that you make informed choices, especially when choosing your methodologies
  42. Bibliography • «The Scrum Guide™ - The Definitive Guide to

    Sc rum: The Rules of the Game» • Scrum Alliance • Scrum: a Breathtakingly Brief and Agile Introducti on • The professional ScrumMaster’s Handbook
  43. Thanks for your attention! ^__^