AGILE & TECHNOLOGYENABLED BUSINESS

Velocity. Scalability, and Reliability Driving Time-to-Value

2Agenda

5 min: Welcome30 min: Scrum Overview5 min: Form teams10 min: Game(s) Explanation15 min: Team Planning7 min: Sprint 17 min: Demo & Retrospective 17 min: Sprint 27 min: Demo & Retrospective 2

LESSON COVERAGE& KEY OBJECTIVES

History of Agile

Scrum : History of an Agile Me thodology

Scrum : In a Nutshe ll

Sprint0

Managing Sprints

Maintaining the De vOps backlog

Working with Story Points

Use r Storie s

Distribute d Agile for De vOps

Kaize n

Kanban

Board Vie ws

Burndown

4History of Agile

Agile started centuries ago with the scientific method created by Francis Bacon in 1620.

Fast forward 300 years to Walter Shewhartfrom Bell Labs with Plan-Do-Study-Act.

Shewhart taught W. Edwards Deming who turned it into the Toyota Production System and the birth of “lean”.

Different angles on lean applied to software with Scrum, Guerilla Programming, eXtremeProgramming, Feature Driven Development.

Large amount of geeks meet at Snowbird in Utah and come out with Agile.

Agile applied to software, infrastructure, project management, culture all coalesce in DevOps – DevSecOps –ChatOps –DevBizSecPerfQAOps.

*https:/ / hbr.org/ 2016/ 04/ the-secret-history-of-agile-innovation

5Scrum: History of an Agile Methodology

Scrum has not been immune to controversy, and its history of invention is a topic of frequent debate.

Jeff Sutherland and Ken Schwaber conceived the Scrum process in the early 90's. They codified Scrum in 1995 in order to present it at the Oopsla conference in Austin, Texas (US) and published the paper “SCRUM Software Development Process”.

Others believe that Jeff Sutherland, John Scumniotales, and Jeff McKenna invented Scrum in 1993.

Others point to Hirotaka Takeuchi and Ikujiro Nonaka inventing Scrum in 1986.

6Scrum Main Artifacts

PRODUCT BACKLOG BURNDOWN CHART SPRINT BACKLOG

Dynamically maintained list of prioritized and estimated requirements. Key notions of adaptability and sustainability.

Shows the amount of work remaining per Sprint and provides visualization of the correlation between work remaining at any point in time and the progress.

Contains all the committed User Stories for the current Sprint broken down into Tasks by the DevOps Scrum Team.

PRODUCT INCREMENT

Tangible development of the product or service during the sprint. Typically reviewed with the product owner and/ or stakeholders

7User Personas

INVENTOR ZACH INVESTOR SUSAN CITY ENGINEER ALEX CITY MANAGER MAYA INVENTOR GEOFF(1-100 EMPLOYEES) (100-2,000 EMPLOYEES) (100 - 500 EMPLOYEES) (100-1,000 EMPLOYEES) (1-100 EMPLOYEES)

8Scrum Team

Product Owner• Build and m anage p roduct

backlog• Provide tim e line s for

p roduction de live ry

ScrumMaster• Unde rstands the work in

p rogre ss from both busine ss , de ve lopm e nt and ope rations pe rspe ctive s

• Maintains sp rint scope and shie ld de ve lopm e nt te am from d is traction or de lay

Scrum team• Sm all, tightly collaborative De vOps te am • Pull work from the backlog and de live ry pe r

ite ration

9ScrumMaster Skill Check

Operating Scrum Process – guide teams in Scrum and understand how to iteratively improve products, services, and processes.

Facilitating Team Meetings – Facilitation is a key skill for ScrumMasters and Coaches, and is used in helping people collaborate, create shared understanding, and have meaningful discussions.

Holding Retrospectives – sprint retrospectives should drive continuous improvement and adaptability.

Coaching – showing teams the reason for what they’re doing so they understand the importance, showing product owners the value of their product to drive innovation, and showing individuals the successes and opportunities in their performance.

Knowledge Sharing – bring successes and opportunities to the entire company in key areas around the people, process and technology.

Change Agent – Feedback and iteration can bring continuous improvement to life in an organization.

Conflict resolution – transparency and candor can result in healthy conflict, but when they go beyond the ScrumMaster must navigate tough conversations.

Mirroring – ScrumMasters must place the mirror for team members, product owners, leaders to foster growth.

10Down on the Farm: Chickens and Pigs

Pigs and Chickens – Committed, Involved, or Neither?

The three described Scrum Roles are committed to the project and are essentially on the hook to get the work done with agility, quality, and predictability.

Scrum makes a clear parting between these two groups• Committed: The Roles who are responsible for the project have

the role, responsibility and authority to do DevOps work.• Involved: Stakeholders who aren't responsible for the direct

success, but need to be included for overall DevOps success..• Everyone else

11Down on the Farm: Chickens and Pigs

12Scrum: In a Nutshell

ScrumMaster ensures people follow the process. In standard methodology is not part of the Scrum Team and is focused on knocking down any roadblocks to Team success. Typically this role is the deciding vote on the user stories in a the sprint backlog and sprint length.

A DevOps Scrum-based project starts with a vision of the product or system to be developed based on business requirements.

Product Owner (PO) converts the vision by writing a Story Map.

Story Map drives creation of User Stories into the Product Backlog with prioritization (releases).

Team develops/ operates/ engineers the sprint from the backlog with quality, reliability, velocity and sustainability.

Each sprint should result in some tangible result, e.g. automation, configuration, data set, …

Flash builds and Spikes can be used as mechanisms for short duration development validation, ensuring the larger solution we are pursuing is on the right track.

Scrum enables rapid innovation with disciplined

execution by collaborative

teams.

13Project Charter

Group the team and ask:• What is the project's goal? • What are its most important aspects? • Whose problem are we solving? • What resources do we have at our disposal?

Creating a project charter, and even more crucially, ensuring that its contents are "known and approved by all members of the team", should improve alignment of effort within the team.

Team alignment is a key determinant of project outcomes.

DRAFT THE CHARTER

SOCIALIZE DRAFT WITH KEY STAKEHOLDERS

FOR INPUT

REFINE THE CHARTER BASED ON FEEDBACK

REVIEW WITH SPONSOR AND TEAM FOR SIGN-OFF

EXECUTE THE PROJECT BASED ON THE CHARTER

REVISE THE CHARTER AS NECESSARY

14Story Mapping - 1

15Story Mapping - 2

16

More than a bridge from Waterfall to Agile.

Kickoff is key to success.

Start with small tactical goals while forming the team.

Optimally Sprint0 would be one to four weeks.

Required DevOps team members must be ready to create something tangible.

Leader should be someone who understands running an agile team, as well as, the SDLC process for which DevOps and Agile are being applied.

Sprint 0

SPRINTPLANNINGCOLLABORATIVE PLANNINGSESSION TO DEFINE WHATWILL BE BUILT.

THE DAILY SCRUMINTERNAL TEAM INSPECT/ ADAPT MEETING TO UPDATE STATE AND RESOLVE PROBLEMS.

THE SPRINTDEVELOPMENT TIME; ITERATION LENGTH DECIDED BEFORE PROJECT STARTS.

SPRINT REVIEWFUNCTIONING, POTENTIALLY-SHIPPABLE PRODUCT INCREMENT IS INSPECTED BY TEAM AND CUSTOMER; REQUESTED CHANGES NOTED FOR NEXT SPRINT.

17Managing Sprints

Sprints in DevOps include both development and operations, as well as, business, executive, security, performance and testing teams.

Sprints are the base units of time and work for iterative prototype-based development.

Sprints and Agile address the Uncertainty Principle of Software Engineering postulated by Hadar Ziv.

• "Uncertainty is inherent and inevitable in software development processes and products."

Management requires getting the correct cadence.• Requirements• Product backlog• Sprint planning/ backlog• Development and daily standup• Sprint review/ retrospect

18Maintaining the DevOps Backlog

Product backlog• The product backlog is the list of all user stories the team will

develop for the product.• Sprint backlog• Collaborative communication • Business priorities• Team ability• Interleaving new features and maintenance work

19Working with Story Points

Don’t be overly aggressive initially.

DevOps teams with no Agile experience are usually overly optimistic or pessimistic.

Leave time for ticket management, standups, and the tasks to manage.

Tighten up the schedule over time.

Sprint burndown to show progress and for continuous monitoring, measurement and tuning.

Story points are a unit of measure for sizing relative to the development team. A story that is assigned two points should require twice as much effort as a story that is assigned one point.

Hey, how do you estimate?

Well, 8 story points is like 1 week of work. 3 is about 2 days of coding. You’ll get the drill.

20Agile Estimating

Planning Poker• Planning poker is mostly used to estimate the effort or the

relative size of tasks in software development. The members of the project team come together and estimate each item in a few rounds using the planning poker cards until the team reaches consensus on the size of each item or task.

Magic Estimation• Exercise for the team to estimate an entire product

backlog with story points in a reasonable short amount of time. A useful format to gain insights of the size of a backlog. Is it one month, 3 months or 6 months of work we’re talking about?

Card Sets• Fibonacci ( 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ?, Pass )• Modified Fibonacci ( 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, Pass )• T-shirts ( xxs, xs, s, m, l, xl, xxl, ?, Pass )• Powers of 2 ( 0, 1, 2, 4, 8, 16, 32, 64, ?, Pass )

21User Stories

A user story describes what the system should do, in a way that emphasizes value to a user or customer. It is usually written in one or two sentences of everyday language. “Real-life” perspective.

Requirements gathered into user stories.• Ensure that stories for business goals include areas like

release engineering, network engineering, and testing• Critical nonfunctional requirements—such as those for

compliance, security and performance

User story should be clear for:• As who• I want what• Why

As a (role), I want (something) so that (benefit ).

22User Stories Questions

Do all business requirements actually need to be user stories?

When should user stories be atomic or further broken down?

Are defects user stories?

Should there be Acceptance Criteria for every story?

Do we include Non-Functional Requirements as user stories?

23Distributed Agile for DevOps

Communication is key to scale in Agile DevOps.

Project team separation can increase complexity.• Region• Culture• Time zone

There can be advantages to having teams working in different geographies, but clear handoffs and regular touch points are required.

Escalation for issues to avoid losing significant blocks of time.

Communication captain’s log/ wiki/ blog/ shared-document to capture the moving parts over time.

24Kaizen

Continuous quest for improvement in development, testing, time-to-market, business continuity, project management, requirements, planning, etc.

Encapsulating the continuous quality process.• Identify opportunities for improvement• Execute on improvements• Use retrospectives to create patterns, anti-patterns and best

practices from the work completed

Can be applied to talent management.• Everyone knows what each person’s knowledge sphere

contains • Range graded skillsets• Development/ Engineering/ Operations areas• Targets for development

25Kanban

Framework for Agile development.

Focused on work that is in current sprint.

Product owners work collaboratively with the development team to adjust the backlog.

Cycle time is the key metric in turning out code.• Time-to-market• Time from requirements to production rather than

just focused on development

Limit volume of changes in flight to minimize task switching.

Kanban boards visualize the flow, making it easier for product owners, developers, operations, and testers to see where tasks are and the volumetrics of tasks at each step in the process.

26Scrumban Board

27Burndown Chart

QuestionsEnjoy a positive Agile journey!