Crash Course Scrum• Hugo Messer: Trainer Ekipa.co

• Arjan Franzen: Trainer ZEN software

• The “spaghetti” Game

• Manager vs Team (self)

Power of self organization

ToDo In Progress Done

Who are we

Lean

Theory

Kanban

Scrum

Ceremonies

Artifacts

Roles

Overview

Scrum

Who are we?• Arjan Franzen

• In professional software engineering since 2000 (hobby since I was 9)

• Titles & Roles: Engineer, Lead Engineer, Architect, Development Manager, Scrum master, Agile Coach

• Cheering agile since 2005, lean since 2010

• Hugo Messer• MBA Erasmus in Rotterdam• 2005: Start Bridge• 2008: lived in India 1,5 years• 2005-2010: cried many times• 2014: Wrote 6 books about managing remote teams• 2015: Ekipa.co & start workshops to help others

ToDo In Progress Done

Who are we

Agile

Theory

Lean

Kanban

Ceremonies

Artifacts

Roles

Overview

Scrum

What have we tried so far?

•Waterfall

•V-Model

•RUP

•Scrum

•Statistics are against us here:•Normal distribution? No!

Repeat the same solution

The Agile Manifesto –a statement of values (2001)

Process and toolsIndividuals and interactions over

Following a planResponding to change over

Source: www.agilemanifesto.org

Comprehensive

documentationWorking software over

Contract negotiationCustomer collaboration over

‘Elaborateness’Agile methodologies compared (Roles, Activities & Artifacts)

120+13 9 6 0

RUP XP Scrum Kanban Whatever

More adaptiveMore prescriptive

Agile & Scrum Compared

“ Scrum is an implementation for software projects that follows the values of the agile manifesto.”

12

Building a house

13

A Software house

Product Stakeholders

Product Owner

Team

Agile

Lean Startup

DevOps

Scrum Lean

Roles

Happy Customer

Lean Thinking

• Eliminate waste

• Build quality in

• Create knowledge

• Deliver as fast as possible

• Defer commitment

• Respect people

• Optimize the whole

Agile & Lean ComparedAgile and Lean are not exactly defined but rather are principles and practices

“ Agile focuses on well organized process which allows frequent delivery which makes it easy to adjust the course of development”

“Lean focuses more on limiting waste (Inc. WIP which is a waste) and making production and delivery workflow efficient”

ToDo In Progress Done

Who are we

Agile

Theory

Lean

Kanban

Ceremonies

Artifacts

Roles

Overview

Scrum

Kanban

Kanban Board

Kanban Flow Chart

• Kanban (method) = approach to incremental, evolutionary process improvement for organizations = change management tool = managing flow

• Scrum = an iterative and incremental agile software development framework for manageing software projects and products or application development (managing iterations)

Compare Scrum to Kanban

• Limit work in Progress (WIP)

• Visualize the workflow

• Manage flow

• Make policies explicit

• Implement feedback loops

• Improve Collaboratively, evolve experimentally (Scientific Method)

Kanban is Simplehas only 6 key principles

Limit Work In progress (WIP)

Visualize Workflow

• I.E: Only start when existing work is complete

• Predictable stream of work

Manage Flow

Break

ToDo In Progress Done

Who are we

Agile

Theory

Lean

Kanban

Ceremonies

Artifacts

Roles

Overview

Scrum

Scrum overview

Sprints

• Scrum projects make progress in a series of “sprints”

• Typical duration is 2–4 weeks or a calendar month at most

• A constant duration leads to a better rhythm

• Product is designed, coded, and tested during the sprint

Sequential vs. overlapping development

Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986.

Rather than doing all of one thing at a time...

...Scrum teams do a little of everything all the time

Requirements Design Code Test

No changes during a sprint

• Plan sprint durations around how long you can commit to keeping change out of the sprint

Change

ToDo In Progress Done

Who are we

Agile

Theory

Lean

Kanban

Ceremonies

Artifacts

Roles

Overview

Scrum

Product owner

• Define the features of the product

• Decide on release date and content

• Be responsible for the profitability of the product (ROI)

• Prioritize features according to market value

• Adjust features and priority every iteration, as needed

• Accept or reject work results

The ScrumMaster

• Represents management to the project

• Responsible for enacting Scrum values and practices

• Removes impediments

• Ensure that the team is fully functional and productive

• Enable close cooperation across all roles and functions

• Shield the team from external interferences

The team• Typically 5-9 people

• Cross-functional:

• Programmers, testers, user experience designers, etc.

• Members should be full-time

• May be exceptions (e.g., database administrator)

The team

• Teams are self-organizing

• Ideally, no titles but rarely a possibility

• Membership should change only between sprints

Cross functional team

• Multiple ‘Hats’

• Web Developer ‘Hat’

• Test ‘Hat’

• Delivery Engineer ‘Hat’

• Code Analysis ‘Hat’

• Design ‘Hat’

• Database ‘Hat’

• Operations ‘Hat’

• Security ‘Hat’

ToDo In Progress Done

Who are we

Agile

Theory

Lean

Kanban

Ceremonies

Artifacts

Roles

Overview

Scrum

• Sprint Planning

• The Daily scrum

• Sprint Review

• Sprint Retrospective

•Backlog refinement (grooming)

Scrum Ceremonies

Sprint planning• Team selects items from the product backlog they

can commit to completing

• Sprint backlog is created• Tasks are identified and each is estimated (1-16 hours)

• Collaboratively, not done alone by the ScrumMaster

• High-level design is considered

As a vacation planner, I want to see photos of the hotels. Code the middle tier (8 hours)

Code the user interface (4)Write test fixtures (4)Code the foo class (6)Update performance tests (4)

Sprint planning meeting

Sprint prioritization

• Analyze and evaluate product backlog

• Select sprint goal

Sprint planning

• Decide how to achieve sprint goal (design)

• Create sprint backlog (tasks) from product backlog items (user stories / features)

• Estimate sprint backlog in hours

Sprint

goal

Sprint

backlog

Business

conditions

Team

capacity

Product

backlog

Technology

Current

product

2 Sprints and a backlog (Jira)

The daily scrum

• Parameters

• Daily

• 15-minutes

• Stand-up

• Not for problem solving

• Whole world is invited

• Only team members, Scrum Master, product owner, can talk

• Helps avoid other unnecessary meetings

Everyone answers 3 questions

• These are not status for the ScrumMaster• They are commitments in front of peers

What did you do yesterday?1

What will you do today?2

Is anything in your way?3

The sprint review

• Team presents what it accomplished during the sprint

• Typically takes the form of a demo of new features or underlying architecture

• Informal

• 2-hour prep time rule

• No slides

• Whole team participates

• Invite the world

Sprint retrospective• Periodically take a look at what is and is not working

• Typically 15–30 minutes

• Done after every sprint

• Whole team participates

• Scrum Master

• Product owner

• Team

• Possibly customers and others

Backlog refinement (grooming)

•Checkpoint

•Make stories better

•Product owner + Team

Start / Stop / Continue• Whole team gathers and discusses what they’d like to:

Start doing

Stop doing

Continue doingThis is just one of many ways to do a sprint retrospective.

ToDo In Progress Done

Who are we

Agile

Theory

Lean

Kanban

Ceremonies

Artifacts

Roles

Overview

Scrum

Artifacts

•Product backlog

•Sprint Goal

•Sprint Backlog

•Burndown chart

•Definition of Done

Product backlog• The requirements

• A list of all desired work on the project

• Ideally expressed such that each item has value to the users or customers of the product

• Prioritized by the product owner

• Reprioritized at the start of each sprintThis is the

product backlog

A sample product backlog

Backlog item Estimate

Allow a guest to make a reservation 3

As a guest, I want to cancel a reservation. 5

As a guest, I want to change the dates of a

reservation.3

As a hotel employee, I can run RevPAR reports

(revenue-per-available-room)8

Improve exception handling 8

... 30

... 50

The sprint goal• A short statement of what the work will be focused

on during the sprint

Database Application

Financial services

Life Sciences

Support features necessary for population genetics studies.

Support more technical indicators than company ABC with real-time, streaming data.

Make the application run on SQL Server in addition to Oracle.

Managing the sprint backlog• Individuals sign up for work of their own choosing

• Work is never assigned (push vs pull)

• Estimated work remaining is updated daily

Managing the sprint backlog• Any team member can add, delete or change the

sprint backlog

• Work for the sprint emerges

• If work is unclear, define a sprint backlog item with a larger amount of time and break it down later

• Update work remaining as more becomes known

A sprint backlog

Tasks

Code the user interface

Code the middle tier

Test the middle tier

Write online help

Write the foo class

Mon

8

16

8

12

8

Tues

4

12

16

8

Wed Thur

4

11

8

4

Fri

8

8

Add error logging

8

10

16

8

8

A sprint burndown chart (jr)

A sprint burndown chart (sr)

Ho

urs

40

30

20

10

0Mon Tue Wed Thu Fri

TasksCode the user interface

Code the middle tier

Test the middle tier

Write online help

Mon8

16

8

12

Tues Wed Thur Fri4

12

16

7

11

8

10

16 8

50

Definition of Done

• Stories allowed to move to done when they comply to this definition

• “Done” or “Done Done”

• Example:• Code Complete

• Unit tests written and executed

• Integration tested

• Performance tested

• Documented (just enough)

ToDo In Progress Done

Who are we

Agile

Theory

Lean

Kanban

Ceremonies

Artifacts

Roles

Overview

Scrum

Scrum in Practice: Help a city planner

• Form teams of 4-6 people• Each Team 1 lego box

• There is 1 Product Owner (who is also a trainer)

Scrum in PracticeRules

• Pre-game (50 min)• Organizing teams

• Defining the Process

• Project chartering

• Building the Backlog

• Estimating

• Game (3 sprints)• Sprint Planning (3min)

• Sprinting (7min)

• Sprint Reviewing (5min)

• Post-game• Debriefing

Phases

• All teams will be building a single product – they are not competing, rather they work for the same vendor.

• The product is a CITY with certain features.

• The main building elements are LEGOs, though any other material can be used in addition.

• The PO is the main decision maker of the product – it is my city.

• I will be involved in the development process by being available to answer questions and provide feedback.

Goals

What to build

• 1 storey-buildings (several)

• 2 storey-buildings (several)

• Shop

• School

• Hospital

• Kindergarten

• Bus Stop

• Intersection

• Park

• River

• Bridge

Debriefing

• What did you observe?

• How did it feel being on a scrum team?

• How did the short iterations go?

• How accurate were the estimations (provided the Release Burndown is there)

• What would we have done differently from the beginning, if we had another chance to play the game?

• How did it feel after the first sprint when almost all items required re-work?

• What did the scrum master do?

• How will your strategy change, if you know the Product Owner is unavailable during sprints?

• How did inter-team communication go? Where there any dependencies? How were they resolved?

• What did students learn?

Scaling Agile

Scalability

• Typical individual team is 7 ± 2 people

• Scalability comes from teams of teams

• Factors in scaling

• Type of application

• Team size

• Team dispersion

• Project duration

• Scrum has been used on multiple 500+ person projects

Scaling through the Scrum of scrums

Scrum of scrums of scrums

To DevOps

Customer

Delivery team

Constant flow of new features into production

Operation + Release

Analysis + Design

Integration + QADevelopment

Testing + DemonstrationCustomer

Centralized QA Centralized IT Operations

Agile team

The Last Mile

“If it hurts, do it more often”Frequent Releases Infrequent releases

Smaller releases, Less risk

Effort peaks, High risk

Ch

an

ge

Time

Ch

an

ge

Time

Frequent Releases Infrequent releases

Smaller releases, Less risk

Effort peaks, High risk

Ch

an

ge

Time

Ch

an

ge

Time

Development / DevOps Culture

• Continuous Improvement

• Ideas are experimented with (Kata) instead of squashed

• Feedback instead of fire fighting

• Visualized overview instead of unread documents

• Team Autonomy instead of Centralized control

• Eliminate all costly work handover

• Context , not Control

• Tribes, Guilds, Chapter

• System owners/ Architects

• Loosely coupled & tightly aligned

Is it Continuous

• ‘How long does it take to change a single line of code?’

• Small releases

• Continuous Integration• Branching/Merging

• Continuous Deployment• Automated tests

• DevOps

User Stories

Agile Software Requirements

• Use Cases, User Stories

• S.M.A.R.T• Specific

• Measureable

• Attainable

• Relevant

• Timely

• Lean Startup (Customer Development)

Problems with User Stories: Actors

83

84

uc my real User Story

Administrator

User

General requirement

Configure recorder

Record Stuff

External System

Interface with

recorder

My Real User Stories: Roles and Systems

User Story

• Always use the Narrative

• Always describe the benefit

• User Stories in central location (not email)

• Dan North article

User Stories: Pitfalls

• Describe the problem, not the solution• As a Home owner

• I want to Shovel Snow

• So that I can get out of my driveway to get to work

• Problems!

• Better:• As a home owner

• I want my driveway to be cleared of snow

• So that I can drive in and out of my driveway to get to work

1. Focus on the user

2. Use stories to facilitate a conversation

3. Story writing is teamwork

4. Keep your stories simple and concise

5. Progressively decompose

6. Don’t forget the acceptance criteria

7. Consider grouping user stories into themes

8. Use paper cards

9. Keep your stories visible

10. Some things aren’t stories

Roman Pichler’s 10 tips for user stories

Suggested Reading

Page 88

Continuous Delivery, Lean & DevOps

Thank you!

• http://blog.ekipa.co/CSM_training (scrum Alliance Training)

• http://sparkeducation.nl/scaling-up-summit/ (Jeff Sutherland)