An Introduction to Scrum Practices February 2nd 2016 John Williamson, PMP

Today's presentation will provide a brief overview of core Scrum practices focusing on the Scrum framework's roles, activities and artifacts. If time permits, I will provide a demonstration of how a Scrum team might use a web based agile platform.

Another bucket list

1

Question

So, what would you do if… You were a Scheduler on a $450M project You have spent two years perfecting and customizing a beautiful waterfall schedule You had resolved all documented schedule issues And

The project suddenly pivots and decides to use an agile methodology

2

The Answer… and thus this presentation

You get Agile in a hurry!

3

“Read all about it”

4

California Plans Modular Approach, Multiple RFPs for Child Welfare System Modernization BY MATT WILLIAMS | NOVEMBER 20, 2015

The Child Welfare System — New System (CWS-NS), one of California’s largest IT modernization efforts, will be divided into multiple bid opportunities with the intent of making the project less risky and more agile, officials announced Thursday. The first RFP will be released in December 2015, and the Department of Social Services and Office of Systems Integration expect the project’s first deliverable will be completed during the 2016-17 fiscal year. “Instead of the monolithic approach that was envisioned that we were getting ready to release [in a single RFP on Nov. 24], we’re going to a modular approach. We’re going to break up the RFP into a series of RFPs that will tackle each of the different modules — we haven’t settled on the exact number of those and the sequencing of them. We think this approach is going to be less risky and that it’s going to be quicker to deliverables,” said Michael Wilkening, undersecretary of the California Health and Human Services Agency. It also means a series of vendors likely will participate in the project, rather than having a lone system integrator. Wilkening believes California is the first state to utilize this type of modular approach in the development of a child welfare system. The federal government, including the Administration on Children, Youth and Families, has started using a similar agile approach in its procurements, Wilkening added. The General Services Administration is helping California with technical expertise.

5

Little Hoover Event Highlights Innovative Service Delivery in Government The Little Hoover Commission convened a broad range of speakers from federal, state and local government during a "UX Showcase" on Thursday afternoon in Sacramento, exploring how California might be able to transform and improve service delivery for constituents. The session reinforced a report the commission last fall called "Customer-Centric Upgrade For California Government,” which suggests the state of California designate a chief customer officer and follow the lead of the federal government’s digital strategy, among other reforms to improve the public’s trust and confidence in government. Little Hoover Commissioner David Beier said the report doesn't focus on organizational change in a structural sense. "It is more a framework or a state of mind about making government customer-centric, or centering on the experience of the citizen dealing with the government," Beier said. "What does customer-centric government mean? It means experimenting. One of the maybe most important recommendations, and it'll seem very subtle but I think we heard it pretty consistently, is give state agencies and state leaders an opportunity to experiment and fail. If you're not failing, you're not trying hard enough and not being imaginative enough," Beier said. One of the Little Hoover's report recommendations is for California to launch an agile, customer-focused digital unit along the lines of what the federal government has done with the "18F." That group was formed in 2014 within the General Services Administration and has grown to 185 employees working on behalf of federal agencies in a fee-for-service mode 18F Executive Director Aaron Snow and Deputy Director Hillary Hartley were on hand to explain how 18F works and the lessons they've learned about agile development and "hacking bureaucracy." Code for America Project Manager Jacob Solomon discussed how he has worked with a small team to overhaul and streamline the user experience for constituents applying online or via a smartphone for CalFresh benefits, the state's food stamp program. Attendees also heard from DocuSign Account Executive Jennifer Baker; Mai-Ling Garcia, online engagement manager for the city of Oakland; Citizen Experience Advocate Cyd Harrell; and Code for Sacramento Director Joel Riphagen. The Little Hoover Commission said video of the session will be posted on its website soon. BY MATT WILLIAMS | JANUARY 22, 2016 6

An Introduction to SCRUM

• http://www.scrumhub.com/

7

Scrum Overview Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is: • Lightweight • Simple to understand • Extremely difficult to master

8

Scrum Framework

The Scrum framework consists of Scrum Teams and their associated roles, activities, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.

The rules of Scrum bind together the roles, activities, and artifacts, governing the relationships and interaction between them.

9

Scrum Theory

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.

10

Transparency 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, • A common definition of “Done” must be shared by those performing the work and those accepting the work product. 11

Adaptation 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. Scrum prescribes four formal opportunities for inspection and adaptation: • • • •

Sprint Planning Meeting Daily Scrum Sprint Review Sprint Retrospective

12

Inspection

Scrum users must frequently inspect Scrum artifacts and progress toward a goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work.

13

SCRUM Practices

14

Scrum development efforts consist of one or more Scrum teams, each made up of three Scrum roles: •product owner •Scrum Master •development team • There can be other roles when using Scrum, but the Scrum framework requires only the three listed here. 15

Service Delivery Manager – (Product Owner)

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. The Product Owner is the sole person responsible for managing the Product Backlog. 16

ROLES - Scrum Master

Is responsible for ensuring Scrum is understood and enacted. This is done by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.

The Scrum Master is a servant-leader and impediment remover for the Scrum Team and establishes the environment for success.

17

Scrum Master Service to the Product Owner

The Scrum Master serves the Product Owner in several ways, including:

• Finding techniques for effective Product Backlog management • Clearly communicating vision, goals, and Product Backlog items to the Development Team • Teaching the Scrum Team to create clear and concise Product Backlog items • Understanding long-term product planning in an empirical environment

• Understanding and practicing agility; and, • Facilitating Scrum events as requested or needed 18

Scrum Master Service to the Development Team

The Scrum Master serves the Development Team in several ways, including: •

Coaching the Development Team in self-organization and cross-functionality;

•

Teaching and leading the Development Team to create high-value products;

•

Removing impediments to the Development Team’s progress;

•

Facilitating Scrum events as requested or needed; and,

•

Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

19

Scrum Master Service to the Organization

The Scrum Master serves the organization in several ways, including: •

Leading and coaching the organization in its Scrum adoption;

•

Planning Scrum implementations within the organization;

•

Helping employees and stakeholders understand and enact Scrum and empirical product development;

•

Causing change that increases the productivity of the Scrum Team; and,

•

Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

20

Development Team The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness. Development Teams have the following characteristics: •

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

•

Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;

•

Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;

•

Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole; and,

•

Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis. 21

SCRUM Practices

22

Scrum Activities Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum; Scrum uses time-boxed events… every event has a maximum duration. Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something; These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.

23

Activities & Artifacts

• The product owner has a vision • Grooming: the large cube is broken down into a set of features that are collected into a prioritized list called the product backlog • A sprint starts with sprint planning, encompasses the development work during the sprint (sprint execution), and ends with the review and retrospective. 24

The Sprint

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint. During the Sprint: • No changes are made that would affect the Sprint Goal; • Development Team composition remains constant; • Quality goals do not decrease; and, • Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

25

Sprints The work completed in each sprint should create something of tangible value to the customer or user

Sprints are timeboxed so they always have a fixed start and end date, and generally should be of the same duration.

26

Sprint Planning Meeting

The work to be performed in the Sprint is planned at the Sprint Planning Meeting. This plan is created by the collaborative work of the entire Scrum Team. The Sprint Planning Meeting is time-boxed to eight hours for a one-month Sprint. The two parts of the Sprint Planning Meeting answer the following questions, respectively: 1. What will be delivered in the Increment resulting from the upcoming Sprint? 2. How will the work needed to deliver the Increment be achieved?

27

Sprints Planning • A product backlog may represent many weeks or months of work… more that can be completed in a single, short sprint • Determines the most important subset of product backlog items to be built in the next sprint • During planning, the product owner and development team agree on a sprint goal that defines what the upcoming sprint is supposed to achieve • The development team reviews the product backlog and determines the high priority items that the team can realistically accomplish in the upcoming sprint •The collection of these tasks, along with their associated product backlog items, forms a second backlog called the sprint backlog

28

Sprint Execution • Once the Scrum team finishes sprint planning and agrees on the content of the next sprint, the development team, performs all of the task-level work necessary to get the features done where “done” means there is a high degree of confidence that all of the work necessary for producing good-quality features has been completed • Nobody tells the development team in what order or how to do the task-level work in the sprint backlog • Instead, team members define their own task-level work and then self-organize in any manner they feel is best for achieving the sprint goal

29

Daily Scrum The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one.

The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, each Development Team member explains:

• What has been accomplished since the last meeting? • What will be done before the next meeting? • What obstacles are in the way?

30

Sprint Review A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done.

31

Sprint Review continued The Sprint Review includes the following elements: •

The Product Owner identifies what has been “Done” and what has not been “Done”;

•

The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;

•

The Product Owner discusses the Product Backlog as it stands.

•

The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings.

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

32

Sprint Retrospective

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning Meeting. This is a three-hour time-boxed meeting for one-month Sprints. Proportionately less time is allocated for shorter Sprints. The purpose of the Sprint Retrospective is to: • Inspect how the last Sprint went with regards to people, relationships, process, and tools; • Identify and order the major items that went well and potential improvements; and, • Create a plan for implementing improvements to the way the Scrum Team does its work. 33

SCRUM Artifacts

34

Scrum Artifacts Scrum’s artifacts represent work or value in various ways that are useful in providing transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information needed to ensure Scrum Teams are successful in delivering a “Done” Increment.

35

Scrum Artifact – Product Backlog The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. A Product Backlog is never complete. The Product Backlog evolves as the product and the environment in which it will be used evolves.

The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, and estimate.

36

Process – Product Backlog Grooming

The product backlog is a constantly evolving artifact

Items can be added, deleted, and revised by the product owner as business conditions change, or as the Scrum team's understanding of the product grows The activity of creating and refining the product backlog items, estimating them, and prioritizing them is known as grooming

37

Product Backlog Grooming: Estimating Story Size • Before finalizing prioritizing, ordering or arranging the product backlog, we need to know the size of each item in the product backlog • Scrum does not dictate which, if any, size measure to use with backlog items • In practice, many teams use a relative size measure such as story points

• A relative size measure expresses the overall size of an item in such a way that absolute value is not considered. • For example, feature C is size 2 and feature E is size 8 • We can conclude that feature E is about four times larger than feature C

38

Sprint Backlog The Sprint Backlog is the set of Product Backlog items selected for the Sprint plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality.

The Sprint Backlog defines the work the Development Team will perform to turn Product Backlog items into a “Done” Increment. The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal.

39

Potentially Shippable Product Increment Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it. Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together. As Scrum Teams mature, it is expected that their Definition of “Done” will expand to include more stringent criteria for higher quality.

40

Activities & Artifacts

• The product owner has a vision • Grooming: the large cube is broken down into a set of features that are collected into a prioritized list called the product backlog • A sprint starts with sprint planning, encompasses the development work during the sprint (sprint execution), and ends with the review and retrospective. 41

Acknowledgements The Scrum Guide: The Definitive Guide to Scrum – The Rules of the Game

Authors: Ken Schwaber Jeff Sutherland

42

The Visual AGILExicon

43

Pivotal Tracker Demo

44

The Tale of two Cities… Methodologies

45

GAO

46

47

GAO continued

48

GAO

49

Conclusion - For Your Consideration

50

Definitions Scrum (n): A term borrowed from the sport of rugby. •

A framework for managing complex product and service development

•

An iterative and incremental approach to developing products and managing work

•

Scrum is not a process or technique for building products, rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management… so that you can improve

User Story: A user story describes functionality of a system that will be valuable to a non-development team stakeholder of a system or software. User stories are composed of three aspects: •

a written description or short title of the story used as a token for planning and as a reminder to have conversations

•

Conversations about the story that serve to flesh out the details of the story

•

acceptance tests that convey and document details and than can be used to determine when a story is complete

51