Introduction to Agile and SCRUm

Thursday 19 March 2009

Implementing SCRUMResponding to change

Training & Education


Objectives



Building a house


Some history


Software Engineering



The people who build this


0

1.25

2.5

3.75

5

Bugs/ KLOC

Industry NASA

NASA’s Defect Density


0

1.25

2.5

3.75

5

Bugs/ KLOC

Industry NASA

pretty good, right?

NASA’s Defect Density


0

1.25

2.5

3.75

5

Bugs/ KLOC

Industry NASA

Another data point...

0

225

450

675

900

Cost ($/LOC)


heavy method...


high risk


high cost


less flexibility to change


Waterfall



Requirements


Requirements

Design


Requirements

Design

Develop


Requirements

Design

Develop

Verify


Requirements

Design

Develop

Verify

Maintain


Strengths


Weaknesses


People make mistakes


Pitfalls


big


big Bang


early change



late change



Change is expensive!


Fixed Plans


predicting change...


is difficult ...


without a crystal ball


Adversarial Relations


and hence...


not fun!


Introducing Agile


An approach


given human reality


Guiding Values


Feedback


Communication


Courage


Simplicity







build your manifesto


Individuals & Interactions

Working Software

Customer Collaboration

Responding to Change

Processes & Tools

Contract Negotiation

Comprehensive Documentation

Following a plan


Individuals & Interactions

Working Software

Customer Collaboration

Responding to Change

Processes & Tools

Contract Negotiation

Comprehensive Documentation

Following a plan

Over

Over

Over

Over

The Agile Manifesto


Your Approach


SCRUMThursday 19 March 2009

Moving from...


Software Delivery Marathon

Analysis Design Develop Test Maintain


Moving to...


Sprint

Analysis Develop Test

Sprint


Sprint


Tw

eak

Tw

eak

Simple DesignContinuous IntegrationBuild & Deployment Automation


Incremental Development






Iterative Development






once != iteration


The Scrum Master


Guru NOT Nanny


Sprint Planning







Typical of a SCRUM Team


Typical of a SCRUM Team

Yesterday’s Weather


Collective ownership


Moving from...



My Project Plan


Moving to...


In Analysis Ready for Dev In Dev Dev Complete In QA QA Complete


In Analysis Ready for Dev In Dev Dev Complete In QA QA Complete

Our Card Wall!


Scope Planned Actual Projected

Burn Up Chart


I1 I2 I3 I4 I5 I6 I7 I8 I9 I10 I11 I12 I130

37.5

75

112.5

150


Burn Up Chart


I1 I2 I3 I4 I5 I6 I7 I8 I9 I10 I11 I12 I130

37.5

75

112.5

150


Burn Up Chart


I1 I2 I3 I4 I5 I6 I7 I8 I9 I10 I11 I12 I130

37.5

75

112.5

150


Burn Up Chart


I1 I2 I3 I4 I5 I6 I7 I8 I9 I10 I11 I12 I130

37.5

75

112.5

150


Burn Up Chart


I1 I2 I3 I4 I5 I6 I7 I8 I9 I10 I11 I12 I130

37.5

75

112.5

150


Burn Up Chart


I1 I2 I3 I4 I5 I6 I7 I8 I9 I10 I11 I12 I130

37.5

75

112.5

150


When we planned to finish

Burn Up Chart


I1 I2 I3 I4 I5 I6 I7 I8 I9 I10 I11 I12 I130

37.5

75

112.5

150



When we should finish

Burn Up Chart


Planned Actual Projected

Burn Down Chart


Day1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 90

37.5

75

112.5

150


Burn Down Chart



37.5

75

112.5

150


Burn Down Chart



37.5

75

112.5

150


Burn Down Chart



37.5

75

112.5

150


Burn Down Chart



37.5

75

112.5

150



Burn Down Chart



37.5

75

112.5

150



When we should finish

Burn Down Chart


Tips for Implementation


Analysis Development Management


Analysis


Moving from...


Name

FR-4: Case sensiti

vity in search-and-replace

Requirements

When a user invokes the search-and-replace function, the

software must g

ive the option to do a case-sensitive search.

By default, the search will match any text w

hich has the same

letters as the search term, even if the case is

different. If

the user

indicates that the search is t

o be done with case-sensitivity turned

on, then the so

ftware will o

nly match text in the document w

here

the case is identical to

that of the search term.

During a search and replace, when the so

ftware replaces original

text in the document w

ith the replacement text specified by the

user, the softw

are retains the case of th

e original text as follows:

•If th

e original text was all uppercase, then the replacement

text must b

e inserted in all uppercase.

•If th

e original text was all lowercase, then the replacement

text must b

e inserted in all lowercase.

•If th

e original text had the first character uppercase and the

rest of th

e characters lowercase, then the replacement text

must reflect th

is case as w

ell.

•If th

e original text was sentence case (w

here the first letter of

each word is uppercase), th

en the replacement text must b

e

inserted in sentence case.

•In all o

ther cases, the replacement text sh

ould be inserted

using the case that was specifie

d by the user.

References

UC-8: Search

Nonfunctional Requirements

Nonfunctional requirements impose constra

ints on the design or im

plementation (such as performance re

quirements,

quality sta

ndards or design constraints).

Users have implicit e

xpectations about how well the so

ftware will w

ork. These characteristi

cs include how easy the

software is

to use, how quickly it executes, h

ow reliable it is, a

nd how well it behaves w

hen unexpected conditions

arise. The nonfunctional re

quirements define these aspects about th

e system. (The nonfunctional requirements a

re

sometimes re

ferred to as “non-behavioral requirements” or “softw

are quality attrib

utes”.)

The nonfunctional requirements s

hould be defined as precisely as possible. Often, th

is is done by quantify

ing them.

Where possible, the nonfunctional re

quirements should provide specific measurements which the softw

are must

meet. The maximum number of se

conds it must ta

ke to perform a task, th

e maximum size of a database on disk, th

e

number of hours per day a system must b

e available, and the number of concurrent users supported are examples of

requirements that th

e software must im

plement but do not change its behavior.

This section will contain multip

le nonfunctional requirements, e

nough to define all of th

e performance and quality

attributes of the softw

are. Nonfunctional requirements can use the same template as functional requirements

(above). The following table shows an example of a nonfunctional re

quirement:

Name

NF-7: Performance constraints for search-and-replace

Summary

The search-and-replace feature must perform a search quickly

Rationale

If a search is n

ot fast e

nough, users will a

void using the software.

Requirements

A case-insensitive search-and-replace performed on a 3MB

document with twenty 30-character search terms to be replaced

with a different 30-character se

arch term must take under 500ms

on a 700mhz Pentium III running Microsoft W

indows 2000 at

50% CPU load.

Applied Software Project Management

Andrew Stellman & Jennifer Greene

http://www.stellman-greene.com!

4!

Requirements specification


Moving to...


As a Role

I want to Process

So that Goal

User Stories


A useful resource


]


Lo/Mid Fi Prototypes






Development


Testing


Unit Tests


Test Automation


Test Automation


Test Automation


Test Automation


Developers


Moving from...


Solo Coding


Moving to...



Pairing


Mentorship

Pairing


Continuous Integration




Management


Story Wall



Self Organizing Team


Standup Meeting


Big, Visible Charts


Retrospectives




Questions?


Thank You


Technology

Introduction to Agile and SCRUm