CAI - Agile Scrum Development Presentation

High Productivity Fixed Price On Time Within Budget Defined Processes MetricsHigh Productivity Fixed Price On Time Within Budget Defined Processes Metrics

Confidential

1

An Agile Approach to Application Development using Scrum

www.compaid.comwww.itmpi.org


2

Confidential

2

Agenda

• Introductions

• Problems With Traditional Development Approaches

• Agile Development Overview

• Scrum


3

Confidential

3

Software Projects Continue To StruggleProject Success Rates as Reported in the 2009

Standish Chaos Study:

• 32% Successful (On Time, On Budget, Fully Functional)

• 44% Challenged (Late, Over Budget, And/Or Less than Promised Functionality)

• 24% Failed (Canceled or never used)

These numbers indicate a downward trend in the success rates from the previous five studies.


4

Confidential

4

Traditional Development Methods

• Based on a manufacturing model

• Result in customer frustration and lack of trust

• Often deliver bloated products


5

Confidential

5

Manufacturing-Based Methodologies

• Early development methodologies borrowed heavily from manufacturing, which is repetitive with clearly defined outputs.

• The Waterfall methodology is based on:– Starting with a clear and accurate specification

(prevents rework by getting things right upfront)

– Perfecting a design specification before building (no changes to requirements at this point)

– Quick testing cycle with little rework needed

• Between 25% and 35% of requirements change on large projects (reported by Capers Jones)

• Valid change requests are often rejected in order to manage costs and protect delivery dates.

Get it right!


6

Confidential

6

Customer Frustration and Lack of Trust• Delivering software late, without all required

features, and with low quality, leads to a lack of trust from our customers

• Forces us to work in a contractual manner, rather than a more productive collaborative manner

• Sign-offs on all requirements needed before design work can start– Fosters a spirit of blame avoidance– Delay in sign-offs can significantly add to the project

schedule


7

Confidential

7

Software Bloat

• In many projects, the software eventually delivered ends up bloated with unused features

• 2009 Standish Chaos Study of software projects shows:― 45% of features were never used

― 19% of features were rarely used

Feature and Function Usage

Never

Rarely

Sometimes

Often

Always


8

Confidential

8

In Summary…

• Traditional approaches have been shown to be ineffective for many software development efforts, evidenced by:

– Resistance to changing requirements and priorities– Unreliability (late delivery, low quality, high cost)– Customer frustration and lack of trust– Bloated products

SO WHAT CAN WE DO ???


9

Confidential

9

An Agile Approach to Projects

• Work as one team

• Work in short iterations

• Deliver working software each iteration

• Focus on business priorities

• Inspect and adapt


10

Confidential

10

Popular Agile Methods– Scrum

• Software developed in time-boxed iterations called Sprints (e.g., 30 days)• Daily 15 minute Scrum meetings – daily team measurement• Working software developed in each Sprint• Prioritized product backlog drives Sprints• Customizable/adaptable based on project characteristics

– Rational Unified Process (RUP)• Process developed to complement Unified Modeling Language (UML), an industry-standard

software modeling method.• Iterative approach for object-oriented software development• Multiple successive phases, consisting of iterations in duration from 2 weeks to several months

– Extreme Programming (XP)• Test driven development• Pair programming• Continuous integration of code• Lightweight documentation • 1-2 week iterations


11

Confidential

11

Rational Unified ProcessAn Iterative Incremental Methodology

• Characteristics:– Software is built in iterative and

incremental phases.– Use case centric, architecture

driven.

• Cons:– The time to delivery of a working,

production ready system can be long.

– Iterations not time-boxed– Customer is not an integral part of

the development team.

• Pros:– Some flexibility to accommodate

change– Delivery of software more

frequent and visible to the business

– Early focus on architecture


12

Confidential

12

Scrum


13

Confidential

13

Scrum


14

Confidential

14

Scrum Overview• A lightweight approach for planning and executing iterative

development projects

• Used at product companies and IT organizations since 1990 including Microsoft, Google, Honda, and Xerox

• Wraps existing engineering practices

• Delivers working business functionality every 30 days

• Encourages “building quality in” rather than “testing defects out”

• Extremely simple but very hard

• Scalable

• Scrum feels completely different!


15

Confidential

15

Scrum Terminology

• Product Backlog – prioritized list of desired customer features

• Sprint – iterative development cycle with a duration of 2-4 weeks

• Sprint Backlog – the list of tasks that the Scrum team commits to complete in the current Sprint. Items on the Sprint Backlog are drawn from the Product Backlog


16

Confidential

16

The Scrum Process


17

Confidential

17

1. Customer lists known requirements (to a high level), then prioritizes them.2. Frequently deliver time-boxed increments of high-value Working software.3. The Customer can release the software any time they want.4. The Customer can add, delete or reprioritize features at any time (“embrace change”)5. We protect schedule commitments, despite change.6. Stop at any time, and still use what has been built.

Scrum Principles

time

All

features

prioritized

ProductBacklog

Working softwareeach iteration

Relea

se

Learn from the market

Source: Vision Consulting, 2006

PromisedRelease

Date


18

Confidential

18

Scrum Roles

• Product Owner

• Scrum Team

• ScrumMaster


19

Confidential

19

Role – Product Owner

• Critically important, must be trained in Scrum

• Should be a Business representative

• Develops and maintains the Product Backlog

• Prioritizes the Product Backlog

• Presents and explains Product Backlog to the team

• Empowered to make decisions for all customers and users

• Attends Sprint planning meeting and Sprint review meeting


20

Confidential

20

Product Backlog• List of functionality, technology, issues

• Emergent, prioritized, estimated

• Product Owner responsible for priority

• More detail on higher priority backlog

• Derived from Business Plan or Vision Statement, which sometimes have to be created with customer

• Each Product Backlog Item must include a definition of “Done”

– Test conditions identified

– Code complete

– Unit and Integration Tested

– Accepted by Product Owner


21

Confidential

21

Example Product Backlog


22

Confidential

22

Role – Scrum Team

• Self-organizing, highly collaborative

• Cross-functional

• Ideal Team Size = Seven plus or minus two

• Converts selected Product Backlog items into tasks on the Sprint Backlog

• Responsible for committing to work defined on Sprint Backlog

• Authorized to do whatever is needed to meet commitment

• Synchronizes at the Daily Scrum Meeting


23

Confidential

23

Sprint Backlog

• Tasks to turn product backlog into working product functionality

• Tasks are estimated in hours, usually 1-16

• Tasks with more than 16 hours are broken down later

• Team members sign up for tasks, they aren’t assigned

• Estimated work remaining is updated daily

• Any team member can add, delete, or change the Sprint Backlog

• Work for the Sprint emerges

• Update work remaining as more is known, as items are worked


24

Confidential

24

Example Sprint Backlog


25

Confidential

25

Role – Scrum Master

• Coach and Advocate

• Responsible for managing the process

• Sets up and conducts meetings

• Representative to management

• Representative to team


26

Confidential

26

Scrum Meetings

• Sprint Planning

• Daily Scrum

• Sprint Review


27

Confidential

27

Sprint Planning Meeting

• A full-day meeting that precedes each Sprint

• 1st 4 hours - team selects Product Backlog Items and sets goal with Product Owner

• 2nd 4 hours - team defines Sprint Backlog to build functionality

• Anyone can attend, but primary conversation and work is between team and Product Owner


28

Confidential

28

Daily Scrum

• Daily 15 minute status meeting• Same place and time every day• Three questions

–What have you done since last meeting?–What will you do before next meeting?–What is in your way?

• Impediments discussed• Decisions made


29

Confidential

29

Sprint Review Meeting

• Duration = 4 hours

• Maximum 1 hour preparation

• Demo conducted on equipment where software was developed and tested

• Presented by team to Product Owner and customers/users

• Basis for planning next Sprint

• Must represent potentially shippable increment of product functionality (features are “done”)


30

Confidential

30

Scrum Metrics

• Sprint Burndown Chart

• Product Burndown Chart

• Velocity Measure

• Sprint Results


31

Confidential

31

The Burndown Chart

• Displays number of task units (typically hours) remaining

• Overall trend is important to monitor

• Daily fluctuations are acceptable and expected

• Actual Line should eventually reach 0 hours and should roughly follow Expected Line

• Across Iterations, a less granular measure is used that is tied to the deliverables, e.g., Story Points


32

Confidential

32

Progress During An IterationSprint Burndown Chart

Iteration n Burndown Chart

0

200

400

600

800

1000

1200

1400

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29

Days

Ho

urs Expected

Actual


33

Confidential

33

Progress Across IterationsProduct Burndown Chart

Burndown Chart

0

20

40

60

80

100

120

140

160

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Iterations

Sto

ry P

oin

ts

Expected

Actual


34

Confidential

34

Velocity (8 iterations)

0

2

4

6

8

10

12

14

16

1 2 3 4 5 6 7 8

Iterations

Vel

ocit

y

Velocity

Velocity Measure

Velocity (last 3 iterations)

Velocity (last 8 iterations)


35

Confidential

35

Sprint Results


36

Confidential

36

Scrum Is No Silver Bullet

• Extremely simple but very hard

• Many organizations are not used to releasing software so frequently

• Each iteration involves planning, requirements analysis, design, coding, and testing

• Highlights existing disfunctionality and bottlenecks within the organization that were previously hidden

• Scaling Scrum beyond an initial pilot project requires significant change management skill


37

Confidential

37

Impediments To Using Agile

• Ability to change organizational thinking and culture

• Hard to break command and control management style– Management changes from telling people what to do to leading

and helping everyone do their best to achieve goals

– People aren’t resources, and managers aren’t bosses

• Requires dedicated participation from customers and end users

• Agile puts pressure on the product development organization to improve its engineering skills

• The phrase “That can’t be done here” really means it will be very difficult to do so


38

Confidential

38

Critical Success Factors For Agile Adoption

• Complete commitment to Agile from the top-down

• Qualifying and selecting an appropriate pilot project– Non-disruptive

– Relatively short in duration

• Staffing a team with enthusiastic, talented, self-managing people

• Identifying and training a dedicated Product Owner from the business

• Specifying a clear definition of “done” for Product Backlog Items


39

Confidential

39

Benefits of Agile Development• Accelerated time to market

• Ability to accommodate changing requirements and priorities

• Productivity is increased

• Staff morale is improved

• Product quality is improved

• Product features meet customer needs

• Value is generated early

• High probability of meeting fixed-date commitments


40

Confidential

[email protected]

WWW.COMPAID.COM

Contact CAI for more information

40


41

Confidential

41

Additional InformationLinks• http://www.scrumalliance.org• http://www.controlchaos.com• http://www.mountaingoatsoftware.com• http://www.xprogramming.com

Books• Agile Project Management with Scrum

by Ken Schwaber• Agile Estimating and Planning

by Mike Cohn• Agile Software Development with Scrum

by Ken Schwaber, Mike Beedle

CAI - Agile Scrum Development Presentation

Documents

software late

software development

scrum process

software bloat

change delivery of software

development team

iterative development

timeboxed customer