Agile SW Development plus Scrum in - depth Slide 1 Plan-driven and - PowerPoint PPT Presentation

Software Engineering I Chapter 3 Agile SW Development plus Scrum in - depth Slide 1

Plan-driven and agile development  Plan-driven development  A plan-driven approach to software engineering is based around separate development stages with the outputs to be produced at each of these stages planned in advance.  Not necessarily waterfall model – plan-driven, incremental development is possible  Iteration occurs within activities.  Agile development  Specification, design, implementation and testing are inter-leaved and the outputs from the development process are decided through a process of negotiation during the software development process.  A cadence of multiple deliverables is better able to help a project keep progress and provide better estimates rather than having everything be "80% done" 30/10/2014 Chapter 3 Agile Software Development Slide 2

Why the break from Waterfall? On February 2001, 17 software developers met at the Snowbird resort in Utah to discuss lightweight development methods. They published the Manifesto for Agile Software Development Slide 3

Manifesto for Agile Software Development  We are uncovering better ways of developing software by doing it and helping others do it.  Through this work we have come to value:  Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan  That is, while there is value in the items on the right, we value the items on the left more. Slide 4

Twelve Principles of the Agile Manifesto 1. Our highest priority is to satisfy the 6. The most efficient and effective method of customer through early and continuous conveying information to and within a delivery of valuable software. development team is face-to-face conversation. 2. Welcome changing requirements, even late in development. Agile processes 7. Working software is the primary measure of harness change for the customer's progress. competitive advantage. 8. Agile processes promote sustainable 3. Deliver working software frequently, development. The sponsors, developers, and from a couple of weeks to a couple of users should be able to maintain a constant months, with a preference to the pace indefinitely. shorter timescale. 9. Continuous attention to technical excellence 4. Business people and developers must and good design enhances agility. work together daily throughout the 10. Simplicity--the art of maximizing the amount project. of work not done -- is essential. 5. Build projects around motivated 11. The best architectures, requirements, and individuals. Give them the designs emerge from self-organizing teams. environment and support they need, 12. At regular intervals, the team reflects on how and trust them to get the job done. to become more effective, then tunes and adjusts its behavior accordingly Slide 5

The primary measure of progress T RADITION AL A GILE DITIONAL W ATERFALL ALL Analysis Analysis 50% done Design Design Development Development Integration & Integration & Testing Testing Implementation Implementation 50% done Slide 6

Agile vs Scrum "The Agile movement is not anti-methodology, in fact many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely- used tomes. We plan, but recognize the limits of planning in a turbulent environment." Jim Highsmith, 1 of the 17 original signatories of the Agile Manifesto "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" ScrumAlliance, founded by Ken Schwaber, another original signatory of the Agile Manifesto "Scrum is a management and control process that cuts through complexity to focus on building software that meets business needs… Scrum itself is a simple framework for effective team collaboration on complex software projects." scrum.org, founded by Ken Schwaber, Slide 7

Agile Programming The aim of agile methods is to reduce overheads in the software process (e.g. by limiting documentation) and to be able to respond quickly to changing requirements without excessive rework. Slide 8

Scrum The most prevalent of the Agile Methodologies Slide 9

Definition of scrum  Scrum (n): A framework within which  The Scrum framework consists of people can address complex adaptive Scrum Teams and their associated problems, while productively and role ro les, eve vents ts, artif ifacts acts, and rule les. Each creatively delivering products of the component within the framework highest possible value. serves a specific purpose and is essential to Scrum’s success and  Scrum is: usage.  Lightweight  The rules of Scrum bind together the  Simple to understand events, roles, and artifacts, governing  Difficult to master the relationships and interaction  Scrum is a process framework that has between them. The rules of Scrum are been used to manage complex product described throughout this document. development since the early 1990s.  Specific tactics for using the Scrum  Scrum is not a process or a technique framework vary and are described for building products; rather, it is a elsewhere. framework within which you can employ various processes and techniques. Slide 10

Scrum Theory: Process Control Models PRED EDICTIVE ICTIVE EM EMPIRI IRICAL  Work and outcomes are  Frequent inspection and adaptation understood before execution. occurs as work proceeds.  Given a well-defined set of  Processes are accepted as inputs, the same outputs are imperfectly designed. generated every time.  Follow the pre-determined steps  Outputs are often unpredictable and to get known results. unrepeatable. Customer knows what he wants. Customer discovers what he wants. Engineers know how to build it. Engineers discover how to build it. Nothing changes along the way. Things change along the way. Slide 11

The Three Legs of Empiricism Empiricism asserts that knowledge comes from experience and making decisions based on what is known  T RANSPARENCY  Significant aspects of the process must be visible to those responsible for the outcome.  Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.  For example:  A common language referring to the process must be shared by all participants; and,  Those performing the work and those accepting the work product must share a common definition of “Done”.  Transparency allows all facets of any Scrum process to be observed by anyone. This promotes an easy and transparent flow of information throughout the organization and creates an open work culture. In Scrum, transparency is depicted through:  Artifacts  Meetings  Burndown Chart  Project Vision Statement  Sprint Review Meetings  Scrumboard  Prioritized Product Backlog  Release Planning Schedule  Inspection Slide 12

The Three Legs of Empiricism Empiricism asserts that knowledge comes from experience and making decisions based on what is known  I NSPECTION  Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances.  Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.  Inspection can be accomplished through:  Use of a common Scrumboard and other information radiators  Collection of feedback from the customer and other stakeholders during Sprint reviews, when creating a Prioritized Product Backlog, and during Release Planning processes  Inspection and approval of the Deliverables by the Product Owner and the customer in the Demonstrate and Validate Sprint process. Slide 13

The Three Legs of Empiricism Empiricism asserts that knowledge comes from experience and making decisions based on what is known  A DAPTATION  Adaptation happens as the Scrum Team and Stakeholders learn through transparency and inspection and then adapt by making improvements in the work they are doing., especially through Sprint Retrospectives and constant risk identification.  If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.  Scrum prescribes four formal events for inspection and adaptation, as described in the Scrum Events section of this document:  Sprint Planning  Daily Scrum  Sprint Review  Sprint Retrospective Slide 14

The Complexity of Software Development Agreement  Simple Far from  Everything is known Chaos  Complicated MENTS  More is known than IREME unknown Complex REQUIR  Complex Complicated  More is unknown than known  Scrum thrives here Agreement Close to Simple Complicated  Chaotic Close to  Very little is known Far from TECHN CHNOL OLOG OGY Certainty Certainty Slide 15

Characteristics of Waterfall vs Scrum Slide 16