Agile Business Driven Development

WeBeAgile.com

webeagile.com

2

http://images.google.com/imgres?imgurl=http://www.classycars.org/Plymouth/logo_plymouth.jpg&imgrefurl=http://www.classycars.org/plymouth.html&usg=__7iaMD0tF5zc0_uzKpDhxHLJrEPo=&h=60&w=100&sz=2&hl=en&start=16&sig2=o_jkjWfIEdt41gMZlVM2FA&um=1&tbnid=XQTywVrN2z0vNM:&tbnh=49&tbnw=82&prev=/images?q=plymouth+logo&hl=en&rlz=1W1IBMA_en&um=1&ei=WnNNS_z8ApPutgPy493yAw

5

Agile/Lean Development

Delivering early and

often, giving ourselves

the best opportunity to

beat the competition to

market, realize revenue

and discover insights

that we can use to help

us improve

The actualization and effectively dealing with -

More Success + Greater Speed + Fewer Resources +

Constant Uncertainty + Increased Competition +

Quicker Time to Market

1. Agile puts the Product Owner (aka “the business” or customer representative) in

the driver’s seat – In the majority of the waterfall style projects the customer is involved, but in a

limited capacity. They get to define a scope up-front, but then any changes they deem necessary are

change ordered back to them. This practice assumes that the customer knows exactly what they want up

front and penalizes them for changing their minds later in the development process.

2. Agile allows the business to quickly react to changing market conditions and

needs – The only thing constant in today‟s economy is change. Businesses need to be able to make

quick course corrections in order to survive.

3. Agile provides visibility into the development process – For many customers software

development is a dark art. They don‟t have the background in order to understand the technical details

and in most cases the development team prefers it this way. The customer is left feeling helpless and

Agile engages them throughout the development lifecycle, providing enhanced visibility.

4. Agile also puts the Development Team in the driver’s seat - While the Product Owner is

responsible for “what” is to be developed the Development Team is self-directing and self-organizing as to

“how” to develop the system-software product

Copyright © 2008 Russell Pannone. All rights reserved.

1. Selecting Stories from the

Product Backlog based on

the team’s velocity

2. Identifying the tasks to

realize a selected Story

3. Estimating the hours

required to complete the

task

4. ScrumMaster validates total

estimated work against

total team capacity during a

Sprint (# of people *

productive hours/day * # of

days for the Sprint)

7


1. Selecting identified

tasks to complete

2. Completing them per

the team's definition of

done

3. This cycle repeats until

all Story points for the

Sprint are earned

and/or Sprint is

complete

8

10

SS Agile SS Agile


12

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

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

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

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

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

Working software is the primary measure of progress.

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

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

Continuous attention to technical excellence and good design enhances agility.

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

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

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


Delivering early and often,

giving ourselves the best

opportunity to beat the

competition to market,

realize revenue and

discover insights that we

can use to help us improve


Conceptualize

• Select the Customer

• Understand the Customer

• Express Feature Set

Realize

• Plan

• Test

• Develop

• Deliver

• Inspect

• Adapt

Operationalize

• Deployment

• Servicing

By delivering early and

often we give ourselves

the best opportunity to

beat the competition to

market, realize revenue

and discover insights

that we can use to help

us improve

16

Scrum Explained


In Scrum you work in iterations

delivering value-adding results

incrementally

“The… „relay race‟ approach to

product development…may conflict

with the goals of maximum speed

and flexibility. Instead a holistic or

‘rugby’ approach—where a team

tries to go the distance as a unit,

passing the ball back and forth—

may better serve today’s

competitive requirements.”- Hirotaka

Takeuchi and Ikujiro Nonaka, “The New New Product Development

Game”, Harvard Business Review, January 1986

17

Scrum Roles & Definitions(continued on next slide)


Copyright © 2005 Mountain Goat Software.

18

Scrum Roles & Definitions(continued on next slide)




Scrum Roles & Definitions(continued from previous slide)


US Airways Confidential – Do not distribute or duplicate

All

Requirements

All

Planning

All

Design

All

Development

All

Validation

All

Implementation

Problem /

Opportunity

Feedback

Traditional Development implied sequential “waterfall” time delay in obtaining feedback

Iterative & Incremental

Development and Delivery

Kanban Board

Pending WIP Done

Test

Define

Design

Code

Build & Implement


Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

http://farm1.static.flickr.com/55/147874576_8a453079f3.jpg




















































23

Candidate Practices

24

Usage scenario

– When a project team wants to “be” agile they self-organize & self-direct around the 9 practices

– The team then selects 1 or more practice to apply to their work at hand

Benefits

– Iterative & Incremental adoption of “being” agile

– Gives team a context and narrow focus to rally around

– Provides a non-threatening easy way for team to learn together, “be” agile, apply an iterative and incremental approach, and get better at what we do

The actualization and effectively dealing with -

More Success + Greater Speed + Fewer Resources +

Constant Uncertainty + Increased Competition +

Quicker Time to Market

1. Agile puts the Product Owner (aka “the business” or customer representative) in

the driver’s seat – In the majority of the waterfall style projects the customer is involved, but in a

limited capacity. They get to define a scope up-front, but then any changes they deem necessary are

change ordered back to them. This practice assumes that the customer knows exactly what they want up

front and penalizes them for changing their minds later in the development process.

2. Agile allows the business to quickly react to changing market conditions and

needs – The only thing constant in today‟s economy is change. Businesses need to be able to make

quick course corrections in order to survive.

3. Agile provides visibility into the development process – For many customers software

development is a dark art. They don‟t have the background in order to understand the technical details

and in most cases the development team prefers it this way. The customer is left feeling helpless and

Agile engages them throughout the development lifecycle, providing enhanced visibility.

4. Agile also puts the Development Team in the driver’s seat - While the Product Owner is

responsible for “what” is to be developed the Development Team is self-directing and self-organizing as to

“how” to develop the system-software product

User Stories Business

Priority

Story Points

Story A 1 5

Story B 2 8

Story C 3 1

Story D 4 8

Story E 5 2

Story F 6 2

Story G 7 2

Story H 8 8

Story I 9 5

Story J 10 1

28Copyright@ 2008 Russell Pannone. All rights reserved.

The Product Owner/Customer tells us they want an implement for writing,

drawing, or marking that is easy to keep sharp, is comfortable to hold, and when

they want to they can easily make a correction.

We collaborate more with the Product Owner/Customer on their needs or

requirements and define the implement’s features and corresponding

benefit/value, as depicted in the table below. Take notice that we have benefits

that influence the implement’s functionality and constrain its design and final

form.

Features Benefits/Value

Is made of wood Easy to sharpen and smells good

Has a specific diameter Comfortable

Surface to be coated Won’t get splinters

Contains a lead composite filler Creates an impressive line

Has an eraser at the end Makes correcting easy

Copyright © 2008 Russell Pannone. All rights reserved. 30

• As an implement user I want an implement that is made of wood so it is easy to sharpen and smells good when sharpening

• As an implement user I want an implement that has a specific diameter so it is comfortable to hold

• As an implement user I want the surface of the implement to be coated so I won’t get splinters when I use it

• As an implement user I want the implement to contain a lead composite filler so I can create an impressive line

• As an implement user I want to have at the end of the implement an eraser so I can easily make a correction

Copyright © 2008 Russell Pannone. All rights reserved.31


A story is a “placeholder”

for a requirement formulated as a

brief description written in the

everyday language of the customer

or user describing desired

functionality; containing just

enough information so that the

product team can produce a

reasonable estimate of the effort to

implement it

Samples Stories

33

As a user, I want to cancel a reservation

As a vacation planner, I want to see photos of the hotels to help me determine if it meets my needs

As a frequent flier, I want to rebook a past trip, so that I save time booking trips I take often

34

Where Are the Details?

As a user, I can cancel a reservation Does the user get a full or partial refund?

Is the refund to her credit card or is it site credit?

How far ahead must the reservation be cancelled?

Is that the same for all hotels?

For all site visitors? Can frequent travelers cancel later?

Is a confirmation provided to the user?

How?

36

Details as Conditions-of-Satisfaction

The product owner‟s conditions of satisfaction can be added to a story These are essentially acceptance tests

As a user, I can cancel a reservation Verify that a premium member

can cancel the same day without a fee.

Verify that a non-premium member is charged 10% for a same-day cancellation.

Verify that an email confirmation is sent.

Verify that the hotel is notified of any cancellation.

Continued next page

37

Story - As an eligible user, I can pay the one-time registration fee of $10, so that I can access my driver’s

record in the future

Conditions-of Satisfaction:

• verify that a payment can be made

• verify that once a payment is made, the user can view their record (with any subsequent fees)

• verify that payment option is not available if registration has already been paid

Story - As an eligible user, I can create a unique user name and password so that my access is limited to

my record and to track activity and payment


• verify that a user account can be created

• verify that a user name that is already in use (assigned) is not accepted and the user notified then

prompted for a different user name

• verify that the user name conforms to naming convention (length, caps, etc.)

• verify that the password conforms to naming convention (length, caps, symbols, etc.)

• verify that the legal compliance conditions and consequences of use are displayed and accepted

• verify that if the user does not accept the legal compliance conditions and consequences than no

user name is created

Story - As an eligible user, I can access my record, so that I can verify that it is correct


• verify that the user‟s record is displayed

• verify that the user cannot access records other than his/her own (or dependents)

• verify that user is charged $10 for the first access and $5 for subsequent accesses.

• verify that the user is limited to three record access each year.

• verify that the system displays user profile information including: names, addresses, email

addresses, credit cards, and PayPal.

• verify that records for any nonresident individual with a driving record in the state can be accessed

(by March 1)

Another Example of Details as Conditions-of-Satisfaction

38

INVESTing in Good Stories

Independent- Dependencies lead to problems estimating and prioritizing

- Can ideally select a story to work on without pulling in 18 other stories

Negotiable- Stories are not contracts

- Leave or imply some flexibility

Valuable- To users or customers, not developers

- Rewrite developer stories to reflect value to users or customers

Estimatable- Because plans are based on user stories, we need to be able to estimate them

Sized appropriately- Complex stories are intrinsically large

- Compound stories are multiple stories in one

Testable- Stories need to be testable

Bill Wake, xp123.com

BusStrategy

BusinessModel

System RequirementsFunctional

&Non-Functional

Solution/IT-Services

Sometimes You Have to See the

Big Pictureto Know How the

PiecesFit Best Together

Use Cases


Optional

Optional

OptionalOptional

Copyright © 2008 Russell Pannone. All rights reserved. 40

Five factors to consider when prioritizing1.The commercial or operational value of having the story

2.Degree of uncertainty - the amount and significance of learning and new

knowledge gained by developing the story; focused on requirements

and technology

3.The amount of risk removed by developing and delivering the story –

focused on schedule, budget, scope, operation, technology

4.Dependencies – stories that must be developed together and are

delivered together to provide value to the customer

5.The cost of developing and delivering the story

User Stories Business

Priority

Story Points

Story A 1 5

Story B 2 8

Story C 3 1

Story D 4 8

Story E 5 2

Story F 6 2

Story G 7 2

Story H 8 8

Story I 9 5

Story J 10 1



42

Story Points: Relative Measure of the Size of a Story


1. Selecting Stories from the

Product Backlog based on

the team’s velocity

2. Identifying the tasks to

realize a selected Story

3. Estimating the hours

required to complete the

task

4. ScrumMaster validates total

estimated work against

total team capacity during a

Sprint (# of people *

productive hours/day * # of

days for the Sprint)

43


1. Selecting identified

tasks to complete

2. Completing them per

the team's definition of

done

3. This cycle repeats until

all Story points for the

Sprint are earned

and/or Sprint is

complete

44

Collaboratively and adaptively develop value-adding product increments in a continuous flow from requirements to deployment

Be objective and see things as a whole

Be value-driven not plan/task-driven

Identify and continually discuss individual, team and enterprise strengths, weaknesses, opportunities and challenges

Put together a coalition to lead by example and teach

Create a vision to help direct change

Use every vehicle possible to constantly communicate the vision and strategies

Get rid of barriers to being agile

Generate short-term wins

Develop people who can implement the change

Anchor being agile in the culture

46

Roadmap to “being” agile

Agile Transition

Program

Agile Coaching & Training

Scrum Coaching & Training

Organizational Change

Management

Cultural Renewal

Agile Business Driven Development

Technology

Transcript of Agile Business Driven Development