Close to agile

© Copyright 2010 Hewlett-Packard Development Company, L.P. 1© Copyright 2010 Hewlett-Packard Development Company, L.P.

CLOSE TO AGILE-SCRUM INTRODUCTION

Wu GangiSAP, HPIT GADSC

© Copyright 2010 Hewlett-Packard Development Company, L.P. 2

BEFORE START

1. Have you touched Agile / Scrum before?

2. What do you want to learn from this session ?


AGENDA

– Why Agile

– What is Agile• Agile Value

• Agile Principle

• Scrum

– How Scrum • Scrum process

© Copyright 2010 Hewlett-Packard Development Company, L.P. 4 © Copyright 2010 Hewlett-Packard Development Company, L.P. 4

AGILE


WHY AGILE


AGILE IS POPULAR


IT REALITIES– IT project delivered late 90% Aberdeen

– IT project delivered over budget 50% Gartner

– IT project that fail to meet objectives 50% Gartner

– IT project cancelled prior to completion 30% Aberdeen


SITUATION FOR TRADITION SOFTWARE DEV– 35% project complete on-time within budget

– 31% project cancelled

– 64% feature rarely never used


COMPLEXITY

Can you understand enough in the beginning?


1 2 3 4 5

6 7 8 9 10

2. Requirement Metioned by Customer

3. Requirement Understanded by Project Manager4. Design given by Designer

5. Coding performed by programer

1. Promise Made by Sales 7. This is Installation Package

8. This is Cost

9. This is Support

10. This is What Really Want by Customer

6. This is document

LOSING INFORMATION


WHAT IS PROJECT SUCCESS

– Cover scope

– On time (before dead line)

– Under budgetScope

TimeCost


DEFINITION OF SUCCESS HAS CHANGED– Functionality

• 83% of respondents believe that meeting actual needs of stakeholders is more important that building the system to specific action

– Quality• 82% believe that delivering high quality is more important that delivering on time and

on budget.

– Money• 70% believe that providing the best ROI is more important that delivering under budget

– Schedule• 58% believe that delivering when the system is ready to be shipped is more important

that delivering on schedule

Source: software development project success survey, Scott Ambler , 2008


AGILE IS MOVING INTO MAINSTREAM


WATERFALL VS. AGILE


WATERFALL VS. AGILE - CONTManage Change


BENEFIT OF USING AGILE– Delivers faster time to market

– Increases productivity

– Reduces cost

– Easily adapts to changing requirements and priorities

– Lowers cost of change

– Provides better visibility into project progress

– Reduces risk

– Maximizes ROI

– Reduces waste

– Encourages higher quality and simpler code

– Delivers business value early and often

– Increases team morale


SURVEY FOR SCRUM PROJECT

– 88% increase productivity

– 93% increase quality

– 83% increase stakeholder satisfaction

– 49% reduce cost

Agile Methodologies: Survey Results, by Shine Technologies, 2003


AGILE


WHAT IS AGILE

– Ag-ile (adj.) Characterized by quickness, lightness and ease of movement; nimble

– Agile is simple (not easy)

– Agile is about doing the important things first and taking small steps

– It’s about people, values, principles, and practices that foster team communication and learning and improving as you go along to regularly deliver customer value through working software


AGILE MANIFESTO

1 2 3 4

Individuals and interactions over processes and tools

Customer collaboration over contract negotiation

Working software over comprehensive documentation

Responding to change over following a plan


AGILE PRINCIPLES1. Satisfy the Customer

2. Welcome Change

3. Deliver Frequently

4. Work as a Team

5. Motivate People

6. Communicate Face-to-Face

7. Measure Working Software

8. Maintain Constant Pace

9. Excel at Quality

10. Keep it Simple

11. Evolve Designs

12. Reflect Regularly


WHAT IS SCRUM


SCRUM


Scrum


SCRUM 100 WORDS

– Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time

– It allows us to rapidly and repeatedly inspect actual working software ( every two weeks to one month).

– The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features.

– Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.


WHAT SCRUM LOOK LIKE


SCRUM CHARACTERISTICS

– Self-organizing teams

– Product progresses in a series of time boxed Sprints

– Requirements are captured as items in a list of Product backlog

– No specific engineering practices prescribed

– Uses generative rules to create an agile environment for delivering projects

– One of the Agile processes.


HOW SCRUM


•Product owner•Scrum Master•Team

Roles

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

Ceremonies

•Product backlog•Sprint backlog•Burndown charts

Artifacts


WHAT SCRUM LOOK LIKE

Product Owner

Team

ScrumMaster

Image available at www.mountaingoatsoftware.com/scrum



Roles


Ceremonies


Artifacts


PRODUCT OWNER

– What he is• Owner of project vision

• Represents the customer

– What he can do• Define features (according to vision)

• Prioritize features (according to ROI)

• Pick release dates• Give feedback• Manage stakeholders• Accept or reject results

Define Success


TEAM

– What he is• Typically 5-9 people

• Cross functional

• Full Time

• Self-Organized

– What he can do• Define tasks

• Estimate effort

• Develop product

• Ensure quality

• Evolve processes

Deliver Success


SCRUM MASTER

– What he is• Servant leader

• Team protector

• Troubleshooter

• Scrum guide

– What he can do• Remove impediments• Prevent interruptions• Facilitate the team• Support the process• Manage management

Ensure Success


PIGS AND CHICKENS

Product OwnerScrum MasterTeam Members

UsersManagersMarketing



Roles


Ceremonies


Artifacts


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 sprint

Product Backlog

OrderedValuedEstimated


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


USER STORIES

– As a <user> I want <functionality>( so that <benefit> )

• As a guest, I want to cancel a reservation,

• As a hotel employee, I can run RevPAR reports so that I can help to improve the quality of service


TYPICAL FIELDS

•Auto-incremented number

•Decomposed stories often use point technology

ID

•Short, descriptive name

Name

•Importance to product owner

Importance or priority

•Effort of story points, H/M/L

•Relative and consistent

Estimate

•Condition of satisfaction being placed on the system

•How to demonstrate? Example ?

Acceptance Test

•Anything else of note

•Details discovered through discussion and conversation between the team and product owner

Detail/conversation


PRINCIPLE OF CREATE USER STORY

Independent

Negotiable

Valued

Estimable

Small

Testable


SPRINT BACKLOG– Individuals sign up for work of

their own choosing• Work is never assigned

– Estimated work remaining is updated daily

– 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

Sprint Backlog

AssignableSmall (1-16hours)Team Estimated


SPRINT BACKLOGTasksTasks

Code the user interface

Code the middle tier

Test the middle tier

Write online help

Write the foo class

MonMon

8

16

8

12

8

TuesTues

4

12

16

8

WedWed ThurThur

4

11

8

4

FriFri

8

8

Add error logging

8

10

16

8

8


TASK BOARD

– Visible

– Editable

– Update Daily

– Own By team


PRODUCT BACKLOG VS SPRINT BACKLOG

Product Backlog Sprint Backlog

Large Small

More Business More Technical

Product Owner Team

User Story Task

Before Sprint planning

During Sprint planning

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)


BURNDOWN CHARTS

Date

Eff

ort

Left


BRUNDOWN CHARTS

– Update daily, usually during the daily stand-up

– Represent the amount of work remaining

– Different approaches to create burndown charts• Estimated remaining time

• Track done


Hou

rs

40

30

20

10

0Mon Tue Wed Thu Fri

TasksTasks

Code the user interfaceCode the middle tier

Test the middle tier

Write online help

MonMon

8

16

8

12

TuesTues WedWed ThurThur FriFri

4

12

16

7

11

8

10

16 850

BURNDOWN CHARTS


BURNDOWN CHARTS

Possible over commitment

Possible Under

commitmentCommitment

achieved. Keep this

velocity for next Sprint



Roles


Ceremonies


Artifacts


Cancel

Gift wrap

Return

Sprint2-4 weeks

Return

Sprint goal

Sprint backlog Potentially shippableproduct increment

Productbacklog

CouponsGift wrap

Coupons

Cancel

24 hours



SPRINT

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

• Analogous to Extreme Programming iterations

– 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

Sprint2-4 weeks


SPRINT

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

Change


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

– High-level design is considered

Sprint backlog


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

Sprintbacklog

Business conditions

Team capacity

Product backlog

Techno-logy

Current product

Sprint goal

SPRINT PLANNING


DAILY SCRUM MEETING– 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 unnecessary meetings


DAILY SCRUM MEETING

– Only the team talks

– Not to Scrum Master

– No problem solving

– Max 15 minutes

– Standing up

What have you done yesterday?11

What will be done today?22

Is anything in your way?33


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• ScrumMaster

• Product owner

• Team

• Possibly customers and others


SPRINT RETROSPECTIVE

What to start doing

What to stop doing

What to continue doing


REVIEW


3 – 3 – 5


Roles


Ceremonies


Artifacts


SCRUM PROCESS

Product Owner

Team

ScrumMaster



THERE’S NO SILVER BULLETS

Close to agile

Technology

Transcript of Close to agile