Agile IntroductionModule 1 - General introduction

Agile according to Dilbert

2

Sprint 1 Backlog

3

TO-DO DOING DONE

What is Agile?

Scrum

XP

Kanban

User Story

4

As a traineeI want to understand Agile principlesTo be able to apply Agile in various situations

Agile Manifesto

5

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

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.

That is, while there is value in the items on the right, we value the items on the left more.

That is, while there is value in the items on the right, we value the items on the left more.

MoreAgile Manifesto

by Geert Bossuyt

Teamwork & responsibility over Individuals and Interaction

Deliver Value over Working software

Partnership elaboration over Customer collaboration

Embrace change over Respond to Change

While we value the Agile Manifesto, we state that MoreAgile is more Agile.

12 principles

6

Working software is the primary measure of progress.

Our highest priority is to satisfy the customerthrough early and continuous delivery of valuable software.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Continuous attention to technical excellence and good design enhances agility.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Simplicity--the art of maximizing the amount of work not done--is essential.

Business people and developers must work together daily throughout the project.

The best architectures, requirements, and designs emerge from self-organizing teams.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

1 7

2 8

3 9

4 10

5 11

6 12

Agile - protest movement

• Against:

• waterfall development

• micro management

• disdain for craftsmanship of developers

7

Principles no Rules• YAGNI - you ain’t gonna need it

• BDUF - big design up front

• BPUF - big planning up front

• Simplicity - the art of maximizing the amount of work NOT done

• Fail fast

• IKIWISI

8

Other planning principles

9

FIX

EDES

TIM

ATE

Scope

Time Cost

Traditional

Scope

Time Cost

Agile

Scrum in a Nutshell

10

Kanban in a Nutshell• Visualise workflow

• Limit WIP

• Measure lead time

11

XP in a Nutshell

12

Comparing methods

13

prescriptive: more rules to followadaptive: less rules to follow

Sprint 1 Backlog

14

TO-DO DOING DONE

What is Agile?

Scrum

XP

Kanban

User Story

15

As a traineeI want to know what Scrum is and XPBecause I might start applying it

Scrum

16

• PROJECT MANAGEMENT approach

• So, same goals as Prince2

• But, a completely different approach!

The big picture

Image available at www.mountaingoatsoftware.com/scrum

Three pillars

• Transparency

• Inspection

• Adaptation

18

Scrum framework•Product owner•ScrumMaster•Team

Roles

•(Release planning)•Sprint planning meeting•Daily scrum meeting•Sprint review meeting•Sprint retrospective

Events

•Product backlog•Sprint backlog•(Burndown charts)•Definition of Done

Artifacts

19

Scrum framework•Product owner•ScrumMaster•Team

Roles

•(Release planning)•Sprint planning meeting•Daily scrum meeting Sprint review meeting

•Sprint retrospective

Events

•Product backlog•Sprint backlog•(Burndown charts)•Definition of Done

Artifacts

20

Mountain Goat Software, LLC

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

Mountain Goat Software, LLC

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 Super Scrum Master

23

Mountain Goat Software, LLC

The team• PO, SM, Development Team

• Typically 3-9 people (excl. PO/SM)

• Cross-functional:

• Programmers, testers, user experience designers, etc.

• Members should be full-time

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

• Teams are self-organizing

• Ideally, no titles but rarely a possibility

• Membership should change only between sprint

Roles in Scrum

25

Product Owner Team Scrum Master

Responsible for VALUE the team delivers

Responsible for QUALITY of delivery

Responsible to remove Impediments

Responsible for WHAT Responsible for HOW (Content)

Responsible for HOW (Scrum process)

Owner of Product Backlog

Owner of Sprint Backlog

Facilitates Sprint Planning Meeting

One person, no committee Optimal size 6 ± 3 Servant leader

Is, or represents, the customer

Cross-functional, self-organising

Introduces Scrum in Project and Organisation

Scrum framework•Product owner•ScrumMaster•Team

Roles

•(Release planning)•Sprint planning meeting•Daily scrum meeting•Sprint review meeting•Sprint retrospective

Events

•Product backlog•Sprint backlog•(Burndown charts)•Definition of Done

Artifacts

26

Release Planning

27

Product Vision

User Story

User Story

User Story

User Story

User Story

User Story

User Story

User Story

User Story

User Story

User Story

User Story

User Story

User Story

User Story

User Story

Epic

User Story

User Story

Epic

User Story

Epic Epic

1 2 3 4 5 6 7 8

User stories are the Agile way of documenting

requirements.As a <user role>

I want <something>So I can achieve <value>

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

Sprintgoal

Sprintbacklog

Business conditions

Team capacity

Product backlog

Technology

Current product

28

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)

29

The daily scrum• Parameters

• Daily

• 15-minutes

• Stand-up

• Not for problem solving

• Whole world is invited

• Only team members, ScrumMaster, product owner, can talk

• Helps avoid other meetings30

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

31

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

32

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

working

• Typically 15–30 minutes

• Done after every sprint

• Whole team participates

• ScrumMaster

• Product owner

• Team

• Possibly customers and others

33

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.

34

•Product owner•ScrumMaster•Team

RolesScrum framework

•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting

Ceremonies

•Product backlog•Sprint backlog•Burndown charts•Definition of Done

Artifacts

35

Product backlog

This is the product backlog

36

•The features, functions, requirements, enhancements and fixes

•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

•Ordered by the product owner

•Re-ordered at the start of each sprint

A sample product backlogBacklog 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

37

Or use T-Shirt sizes (S/M/L)

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.

38

The Sprint Backlog

Definition

• subset of product backlog

• selected for this sprint

• plan for delivering the increment and realising the sprint goal

39

Managing the sprint backlog

• Individuals sign up for work of their own choosing

• Work is never assigned

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

• Work for the sprint emerges

40

Definition of Done

• Wanneer is een taak (een stuk code) af?

41

From a presentation by Ken Schwaber:1. I can readily understand the software and where and how things

happen;2. When I change or add to part of the software, there are no

unintended or poorly designed dependencies;3. I can read the code without lookin for tricks or poorly defined and

labeled variables or data;4. I don’t need the person(s) who wrote the code to explain it to me;5. There are a full set of (automated) tests to check that the function

works as expected;6. When I change something and add to the test, I can check that the

entire change and product continuous to work;7. How thing work and hang together is transparent, and8. Standard, well-known design principles have been adhered to.

Definition of Done• Ten behoeve van de test wordt een voorstel voor een testaanpak opgeleverd.

• Een oplevering moet volledig zijn getest (door middel van een functionele en een regressietest) en de testresultaten moeten zijn beschreven / bevindingen zijn geregistreerd in een testrapport.

• Issues worden geregistreerd zoals beschreven in bijlage 1. Een oplevering mag per ernstcategorie niet meer dan het aantal bij de betreffende categorie vermeldde maximum toegestane open bevindingen bevatten.

• 80% van alle pagina’s moet binnen 2 seconden volledig zichtbaar zijn, de overige pagina’s moeten binnen 5 seconden zichtbaar zijn.

• Rapporten en overzichten welke dagelijks kunnen worden opgevraagd door teamleiders moeten binnen 15 seconden in beeld verschijnen, voor de overige rapporten is geen performance eis gesteld.

• Er moeten meerdere mensen tegelijk kunnen raadplegen en muteren.

• Coding guidelines van Microsoft worden gehanteerd.

• Per oplevering wordt een installatiehandleiding met release notes meegeleverd waarin o.a. het datamodel en de samenhang van de technische modules staan vermeld. Daarnaast wordt een set met User Stories die in de betreffende oplevering zitten meegeleverd.

• Elke oplevering moet op zowel de acceptatie- als productieomgeving geïnstalleerd kunnen worden, wat betekent dat iedere oplevering na de eerste oplevering een upgrade moet zijn in plaats van een full install. Deze moet voldoen aan de eisen van de beheerorganisatie van <klant>.

• Helpteksten dienen in de applicatie te staan om zodoende een gebruikershandleiding overbodig te maken, maar het is niet vereist dat deze ook middels een beheerscherm in de applicatie beheerd kunnen worden.

• Voor elke oplevering wordt er een architectuurcontrole uitgevoerd waaruit blijkt dat men zich gehouden aan de voorgeschreven architectuur.

• Voor elke oplevering wordt een installatie-test uitgevoerd waaruit blijkt dat de software succesvol installeerbaar op de infrastructuur zoals in gebruik bij <klant>

42

Definition of Done

• Tested & bugfree• Deployed to test server,

so PO can test• All user actions• All supported browsers•IE7/8•Chrome•Firefox•Safari on Mac• Comments in code

43

• Refactoring• Code reviewed when

needed• Remember to check

the Style_guideline• Maintain wiki page• Maintain ERD document• Versions of components• License overview• Check the constraints

ResponsibilitiesPO

Team

Scrum Master

Scrum

• Lightweight

• Simple to understand

• Extremely difficult to master

45

Sprint 1 Backlog

46

TO-DO DOING DONE

What is Agile?

Scrum

XP

Kanban

XP - eXtreme Programming

47

• DEVELOPMENT approach

XP Practices

48

Sprint 1 Backlog

49

TO-DO DOING DONE

What is Agile?

Scrum

XP

Kanban

On day in Kanban land

50

On day in Kanban land

51

On day in Kanban land

52

On day in Kanban land

53

On day in Kanban land

54

On day in Kanban land

55

On day in Kanban land

56

On day in Kanban land

57

On day in Kanban land

58

On day in Kanban land

59

On day in Kanban land

60

On day in Kanban land

61

Sprint 1 Backlog

62

TO-DO DOING DONE

What is Agile?

Scrum

XP

Kanban

Sprint 2 Backlog

63

TO-DO DOING DONE

XP Game

Context

Sprint 2 Backlog

64

TO-DO DOING DONE

XP Game

Context

65

The Rhineland Way

66

Anglo-american RhinelandBoss has authority Expert has authority

Individualism Solidarity

Unlimited growth Human limits

Soll as starting point Ist as starting point

Heroes Teamplay

Rule driven Principle-driven

Specialists Craftsmanship

Measuring = knowing Measuring is knowing

Quarterly reports Long term

Cynefin

67

Visible Order C&E obvious

Hidden Order C&E discoverable

Complex Un-order C&E coherent in retrospect

Chaotic Un-order No perceivable C&E

Sense Categorise Respond

Act Sense

Respond

68

Visible Order C&E obvious

Hidden Order C&E discoverable

Complex Un-order C&E coherent in retrospect

Chaotic Un-order No perceivable C&E

Novel Practice

Best Practice

Good Practice

Worst Practice

69

Intervention types

70

Empirically Known The domain of

the actual Legitimate best practice

STANDARD PROCEDURES PROCESS RE-ENGINEERING

Empirically Knowable The domain of the probable

Analytical/Reductionist SCENARIO PLANNING SYSTEMS THINKING

Complex The domain of many

possibilities Pattern Management

PERSPECTIVE FILTERS COMPLEX ADAPTIVE SYSTEMS

Chaos The domain of the

inconceivable Stability focused intervention

ENACTMENT TOOLS CRISIS MANAGEMENT

House of commons

71

RhinelandersAnglo-americans

Cynefin observers

Position: current Anglo-american management

style is the best for our companies

Position: we definitely need to change to The Rhineland

Way

Observe the debate:were the solutions

(interventions) in line with the 4 Cynefin domains?

Sprint 2 Backlog

72

TO-DO DOING DONE

XP Game

Context

Credits• Several slides have been taken from the

Redistributable Scrum Introduction - Scrum Alliance

73