Agile Project Management – Tips

and Technique

Bhawani Nandan Prasad

B.E. IT and MBA Strategy &

Marketing

1

Agile for Scrum

Masters, PORs,

and PMs

2

Waterfall vs. Agile Success

Rates

3

Business Process Stakeholder • The Process Stakeholder “owns” a portion of

The Company’s business process and uses

software (the product) as a tool to execute the

process.

• Defines changes to the business process and

the corresponding changes to the software

product and prioritizes them by business value

• This leads to requests to IT for release date

and product content

• Works with Product Owner Reps and

Project Managers to define work.

• Accept or reject work results

Stakeholder

End User • The End User is the person who actually uses

the software product or business process we

develop

• Provide feedback on the utility and usability of

the product

• Often desires improved usability

and new features.

• Works with POR to define and test

End User

Product Owner

Representative

Product Owner Representative • Works with the Stakeholders to elicit the

product requirements, enters them into the

product backlog, and then communicates and

translates the stakeholder’s vision of the

product to the scrum team

• The Product Owner Rep is the person who

conveys the Stakeholder to the team

when the Stakeholder is not present.

• Helps prioritize features according to

business value and performs

backlog grooming

• Accept or reject work results

Project Manager • The Project Manager “Owns” a software

project chartered to develop a significant

enhancement to an existing software product

or develop a new software product.

• Works with the Stakeholders and POR to elicit

the product requirements, ensures that they

are entered into the product backlog.

• Helps prioritize features according to

business value and performs

backlog grooming

• Tracks and reports progress

• Coordinates with multiple scrum teams/PORs

Project Manager

IT Management Group • The IT Management Group “Owns” the

existing software products and the software

development resources.

• Works with the Stakeholders to prioritize new

features development, fixes, and

enhancements according to business value.

• Resolves priority conflicts among stakeholders

• Coordinates across multiple projects,

scrum teams, and PORs.

• Controls development pace and

order by prioritization

IT Management

Scrum Master

• Represents management to the project

• Responsible for enacting agile 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

• Work closely with the Product Owner Rep

Scrum Master

Scrum Team • Typically 5-9 people

• Cross-functional:

– BA, Programmers, testers, user experience designers, etc.

• Members should be full-time

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

• Membership should change only between iterations

Scrum Team

The Agile Process • Calling ourselves Agile is no guarantee of

success.

• Agile, just like Waterfall, must be done well

to be successful.

11

Requirements Envisioning

12

The

Stakeholder

shares their

vision with the

POR and (if a

large idea)

with a Project

Manager.

Product Owner

Representative

Requirements Capture

13

The POR and (if

working on a large

idea) Project

Manager capture

the requirements as

user stories (often

of epic size) and

enter them into the

product backlog.

Product Owner

Representative

Add Tickets and Bug Fixes

14

The POR

evaluates

tickets and

bugs, then

creates user

stories for

them.

Product Owner

Representative

Continuous Backlog Grooming

15

The POR and (if

working on a large

idea) Project

Manager review the

requirements (user

stories) to

determine if they

completely describe

the function. If not,

add more.

Product Owner

Representative

Continuous Backlog Grooming

will become very important

16

The POR and team

decompose the

user stories into

ready stories with

complete

acceptance criteria.

If stories have

dependencies note

this in the backlog.

Stories must be

sized. Scrum Team

Product Owner

Representative

Grooming Exercise

• What should the SM do if a high priority

story (epic sized) is assigned to a team for

the next sprint?

• What should the POR do if this story has

no acceptance criteria?

• What should the SM do if this story has a

dependency on team 3 completing story 6

before your story can be tested?

17

Backlog Prioritization

18

Management

prioritizes and

tentatively

assigns all the

user stories to

teams with input

from all

Stakeholders,

PORs, PMs, and

Scrum Masters.

High Priority

Low Priority

Project Tracking

19

PM tracks all

the user stories

for the project

release(s). If

project timeline

does not meet

user needs,

then PM must

escalate to

Management

High Priority

Low Priority

20

PMs Review Tracking and Estimate Project

Completion. (This is NOT a commitment)

Project Exercise

• Precisely when will Project A be released?

• When will Project C be released?

• What will happen if a high priority fix takes

all of team C’s time in Sprints 2 and 3 in

release 1?

• What should the Scrum Master do?

• What should the PM do?

• What can the POR do?

21

Team Tracking

22

SM tracks all

the user stories

assigned to the

team for future

iterations. If

team velocity

cannot support

the load, then

SM must

escalate to

Management

High Priority

Low Priority

Scrum Master

Backlog Grooming

23

As the user stories

approach the top

of the product

backlog, the POR

will review ready

stories with

Stakeholders to

ensure stories are

still ready and

clear.

High Priority

Low Priority

Product Owner

Representative

Sprint Planning

24

At the start of a

sprint, the scrum

master and team

commit to develop

the top user stories

assigned to them

based on the team

velocity and

availability. The

POR helps clarify

the user story.

High Priority

Low Priority Scrum Team

Scrum Master

Sprint Planning

25

If the user story is

not clear, or has

dependencies that

are not yet met, or

is too big to do in

one sprint, then do

not commit. Do

not assume DB or

outside groups will

deliver on your

schedule.

High Priority

Low Priority Scrum Team

Scrum Master

Sprint Planning Exercise

• Why is the “one team” concept helpful in

planning?

• What should the SM do if it looks like the

sum of the tasks are 10 hours longer than

time available?

• If another team has 10 hours of available

time, could the work be sent to them?

• What should you do if the story suddenly

looks much bigger than initially sized? 26

Sprint Execution

27

The scrum team

designs, codes, and

unit tests the user

stories. QA tests

the code (based on

acceptance criteria)

and must certify

that it is “done”.

The code is now

ready for Integration

Testing.

Scrum Team

User

story

User

story

User

story

Sprint Execution

28

SM uses sprint burn

down chart to find

stories that are not

likely to be “done”

on time. These

should be split,

dropped, or must be

sent into the next

sprint. Scrum Team

User

story

User

story

User

story Scrum Master

SM Exercise

• If a story is not ready on the last day of the

sprint, what can I do?

• Can I break stories into two new stories:

– A. Code , B Test

– A. Spike , B Initial Story

– A. ½ Story , B Other ½ story

• What will this do to my team velocity?

29

Sprint Demo (end of sprint)

30

The scrum team demos the

coded features to the POR and

Stakeholder. They accept or

reject the features. Rejected

move to next sprint.

Scrum Team

User

story

User

story

User

story

Release to Production

31

Every 6 weeks (3 sprints) the

accepted features are put into

Minimal Functional Releases

and deployed to production.

User

story

User

story

User

story

User

story

User

story

User

story

MFR

Release to Production

32

PMs, PORs, and Scrum Masters

must define MFR content with

help from Stakeholders and

Management. Features not

released must be held for next

MFR.

User

story

User

story

User

story

User

story

User

story

User

story

MFR

MFR Exercise I need to charge taxes on a service stories

(each is 1 sprint of effort):

1. Tax calculation logic

2. Display tax

3. Enter tax exempt number

4. Validate tax exempt number

5. Manual code to override tax (MI is exempt)

6. Remove tax from subtotal

7. Automate tax override with codes

•What order if I am starting 2nd sprint in the

release? What are potential MFRs?

33

MFR Exercise • What happens if these stories are part of a

ILMS phase 7 project?

• Who decides in what order the stories

should be developed?

• What if story 4 (Validate tax exempt

number) has a dependency on web

services creating the access to the fed

database?

• What will you do if a high priority fix

causes you to delay story 6 (remove tax)

by 1 sprint? 34

Our Goal: Deliver Value Faster

35

Agile is Adaptive

• Agile planning is adaptive.

• It also means that because our

requirements are vague, so are any

estimates.

• PMs use story point size estimates and

team velocity to forecast ranged delivery.

• Adaptive teams can plan which features

they intend to do next month, but this is

not a commitment.

36

Commitments • Confusing Estimates with Commitments

is commonplace, and leads to failed projects

• Estimates are the responsibility of the people doing the work

• Targets are set by the people paying for the work

• Commitments are agreements between the people doing the work, and the people paying for the work

• Commitment is achieved through negotiation

Backlog Growth • Agile Backlogs tend to grow, especially at the

start of a project.

• This is normal since jumping into

development with minimal requirements

envisioning means that some features are

missing, many are poorly defined, and most

are underestimated. (just like waterfall)

• All of these lead to expected growth, which

should be encouraged through emphasis on

good, initial backlog grooming sessions.

Backlog Tracking

39

This was expected

as epics were

defined better.

Dark Matter • Both waterfall and agile projects have the

same amount of dark matter (missed or

unknown requirements).

• Agile finds dark matter faster since the

iteration reviews force users to visualize

and then realize what is missing.

• Agile is adaptive, so it allows the backlog

(requirements) to incorporate these

missed requirements while the project is

being developed.

Backlog Tracking

41

True Panic

Set In As

Dark Matter

Appeared

Stakeholder Priority Changes • Sometimes Stakeholders are forced to

change priorities, making the current

project less important or adding high

priority fixes or enhancements to the mix.

• This is another reason why agile does not

try to be predictive.

• Agile POs and PMs update their estimates

at this point so that they can have a

discussion with stakeholders about the

impact of these changes.

How Should I Work With Agile?

1. Ensure user involvement

2. Use adaptive planning.

3. Prioritize release content to maximize

business value.

4. Use adaptive measurement

5. Work to overcome drawbacks of large

and distributed projects

6. Be transparent. All our reports and

findings are published to Share Point.

43

Stakeholder Involvement • Active support, and engagement of

business users is the most critical factor.

• Without significant, constant product

owner participation, the agile teams have

no way to derive requirements and no

feedback to tell whether the system is

meeting those requirements.

• Agile is evolutionary only when users

provide feedback and recognize the “dark

matter” requirements early in

development. 44

What Must You Do?

• Work with Stakeholders as needed (daily)

to define their vision and clarify stories.

• If there is lack of stakeholder participation,

you must escalate to management.

• This could result in planned delays.

• Work with Management to groom backlog

(establish priorities, break down stories)

• Review the product and release plans on

a regular basis to determine if they will

deliver functionality within targeted dates. 45

Adaptive vs. Predictive Planning • Negotiate Scope and

decompose features to achieve

scheduled targets

• Use ranged estimates which

reflect the amount of uncertainty

in the information which our

estimates are based on.

• Focus on delivering maximum

value within each release

• Revisit and refine plans every

iteration and release

46

Plan Releases to Production

• Frequent releases to production provides

maximum value to the business.

• Ask how can I plan to gain maximum value

in each release?

47

48

Build out releases based on VALUE (three

general classifications for product features: must-have, one-dimensional, and delighter )

“This car has many flaws. Buy it

anyway. It’s so much fun to drive”

-- from a NY Times review of the

Mini Cooper

Must-haves The products must

have this features for

me to be consider the

product acceptable One-dimensionals The more of this I get,

the better Delighters I love this element of

the product!

49

Use these classifications to both

prioritize and split

Brakes

(must have)

Basic brakes

(must have)

Stopping

distance (one dimensional)

Anti-locking

(delighter)

Cool dashboard light when slipping

(delighter)

Keep in mind: you must know your customers and users to determine subjective value.

One person’s delighter may leave others apathetic.

Another’s must have is useless to other customers

50

featu

res

release

en

gin

e

tra

nsm

issio

n

su

sp

en

sio

n

bra

ke

s

ex

te

rio

r b

od

y

In

te

rio

r se

atin

g

tire

s

sprint 1 2 3 4

Product goal: (in 4 sprints) be driving the coolest car in town

Let’s look at what happens if we take

an incremental only approach to

construction of our dream car. We want to release

in 4 sprints.

51

user

tasks to s

upport

release D D D D D I I B- C C- D D D D A- B B- B B B B- A- A B A A- A- B-

sprint

1 2 3 4

Product goal: (in 4 sprints) be driving the highest quality car possible

Instead, building up quality iteratively

ships the best product

• Early iterations build bare necessities, later

iterations build up quality

• Evaluating readiness based on subjective quality

to understand doneness

en

gin

e

tra

nsm

issio

n

su

sp

en

sio

n

bra

ke

s

ex

te

rio

r b

od

y

In

te

rio

r se

atin

g

tire

s

52

Release Strategy

Opening Game: Build all necessary features

first Mid-Game: Add flexibility and safety next

End Game: Finish with comfort, performance,

and luxury

Reserve time in the remaining third for

unforeseen additions and adaptations

53

Look at the release of business

value over time

To finish on

time we may

“trim the tail”

by deferring

stories of

modest value

Guidelines for releasing on time

• PMs and PORs must thin and decompose

aggressively during early sprints to build all

essential functionality on time.

• Build up capability, flexibility, and safety

only after all necessities are in place.

• Protect time in the final sprints for product

refinement (adding more safety and then

usability, performance, and sex appeal).

• Assess release readiness at the end of

each sprint as part of product review.

54

Large and Distributed Projects

• As project size (and hence timescale)

increase, the failure rate increases for

Agile Projects (but less than for waterfall).

• If Stakeholders and PORs do not have a

clear vision, the project can drift until

money runs out.

• Distributed teams are still a challenge.

• Since face to face communication is a key

practice, scrum masters and their teams

must work hard to bridge this gap.

55

Establish and Follow Common

Agile Processes

56

• We are developing common agile

development and release processes.

• We will meet in Scrum of Scrum meetings

to escalate blockages that cannot be

handled within a team to the management

level.

• We will work in Scrum Master meetings to

help each other with our agile practices.

• We will communicate extensively to

ensure group awareness.

Establish More Development

and Test Environments

57

• Software needs to be tested in an environment

that resembles the production environment

• This is a large challenge for many organizations

adopting an iterative approach

– They do not have enough testing

environments to provide appropriate isolation

– They have difficulty configuring appropriate

environments as quickly as they are needed

– They are not used to having teams deploy

software into testing environments with high

frequency

You Will Experience Failure

• Failure is not a single, cataclysmic event. You don't fail overnight. Instead, failure is a few errors in judgment, repeated every day. Jim Rohn

• My great concern is not whether you have failed, but whether you are content with your failure. Abraham Lincoln

• A failure is not always a mistake, it may simply be the best one can do under the circumstances. The real mistake is to stop trying. B. F. Skinner

58

Questions

59

Class

Retrospective

60