Mastering Agile Fundamentals · The Agile Manifesto Snowbird, UT – 17 Contributors, 2001 We...

Copyright, GR8PM, Inc, 2019, all rights reserved. No part of this presentation may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without prior written permission.

Mastering Agile Fundamentals

Applying Agile Best Practices Anywhere

1

1

Mastering Agile Fundamentals

Applying Agile Best Practices Anywhere

GR8PMTraditional Agile HybridTraining Coaching Consulting

Copyright, GR8PM, 2020, all rights reserved.

2

Mastering Agile FundamentalsApplying Agile Best Practices Anywhere

What You Already Know:

Agile Fundamentals in 7 Easy Slides

2

3


What We Already Know – Agile Fundamentals in 7 Easy Slides

DEFINITIVEBUDGETARYROUGH ORDER OF MAGNITUDEEngineering

SUB-PROJECTPROJECTPROGRAMPORTFOLIOTraditional PM

ITERATIONRELEASEROADMAPAgile PM

OPERATIONALTACTICALSTRATEGICManagement

The Challenge: Complexity & Uncertainty; Innovation or Stagnation

Non-Linear Distortion from Time and Size

4



The Solution: Shrink the Cone of Uncertainty


3

5



The Solution: Manage the Cone of Uncertainty


…3, 2, 1…13, 8, 5

… 34, 21… 89, 55

∞…144

6



Product 1MBI or MVP

Product 2MBI or MVP

Program 1.1MMF

Program 1.2MMF

Program 2.1MMF

Project 1.2.1FFC Milestones



Work PackageEPICS

Work PackageEPICS

Work PackageEPICS

PORTFOLIOMVO

Activity /Story

Activity /Story

Activity /Story

Task 1 Task 2 Task 3

TIME

T -450

T-360

T-270

T-180

T-90

T-00

The Method: Intelligent Process & Accessible Lexicon

Transform Stakeholders from Irrational to Rational

4

7



TIME

T -450

T-360

T-270

T-180

T-90

T-00


Transform Stakeholders from Irrational to Rational

Hours & $$

8




End Miracle Promises. Start Durable Derived Schedules!

5

9



Principle #1The core purpose of planning is to support decision making; nothing more, nothing less!

Principle #2“It is better to be roughly right… than precisely wrong!”

John Maynard Keynes (British economist, 1883-1946)

The Mantra: Unflinching Allegiance to Reality!

10


Treasure Map (Course Outline)Introductions & Team Formation1. Fundamental Principles2. User Stories3. Estimates4. SchedulesThe Agile Lexicon

Invitation to Discovery

The Most Dangerous Words in Any Language…

6

11

Applying Agile Best Practices AnywhereFundamental Agile Principles

What We Already Know – Agile Reality

Age of

12



When: High Complexity & Uncertainty; Innovation or Stagnation People-Centric: Leverage Biology

50,000Images process 50,000 times faster than text.

Zero effort to automagically interpret patterns.Almost instant comprehension.

0

80%+Information received by the brain is visual.

7

13



Agile & Traditional – Similar Goals. Different Processes.

Traditional

Agile

14



The Agile Manifesto Snowbird, UT – 17 Contributors, 2001

We Value…

Individuals and InteractionsWorking Software

Customer CollaborationResponding to Change

Processes and ToolsComprehensive Documentation

Contract NegotiationFollowing a Plan

overoveroverover

We would add…

“Communication is the Deliverable,

until you have the Deliverable.”

8

15



Agile Focus – Team (Micro) Dynamic

16



Agile & Traditional – Similar Taxonomy

Traditional:Graphical WBS

Objective

Phase 1 Phase 2

WorkPackage 1

WorkPackage 2

WorkPackage 1

WorkPackage 2

Activity 1 Activity 2 Activity 3


Agile / Scrum:Feature Structure

Product

Theme 1 Theme 2

Epic 1 Epic 2 Epic 3 Epic 4

Story1

Story2

Story3


DETAILS

Few &Broad

Many &Specific

9

17


Up-leveling to Disciplined Agile

Minimum Business Increment (MBI)

Minimum Viable Outcome (MVO) is the product or service or option with sufficient features to satisfy Early Adopters and entice the Early Majority.

Minimum Marketable Feature (MMF) is a small, self-contained item that has value to both the organization delivering it and the Stakeholders using it.

Features, Functions and Capabilities (FFC) are “natural” groups, such as engine, transmission, and differential for automobiles, can be intelligently fragmented into more detail as the workflow progresses, providing transparent inspection that aids discovery, adaptation and innovation.

Minimum Viable Product (MVP)

18



Agile & Traditional – Similar Roles

Traditional:• Stakeholders & Sponsor

Agile / Scrum:• Stakeholders & Sponsor

• Program or Sr. Project Manager

• Jr. PM or Team Lead

• Team and SME’s

• Everybody else

• Product Owner

• Scrum Master

• Team and SME’s

• Everybody else

10

19



Beyond the Agile Manifesto Up-leveling to Disciplined Agile

Identify PotentialImprovement

Choose LearningExperiment

AssessEffectiveness

EffectiveAdopt

IneffectiveAbandon

ShareLearning

PLAN DO STUDY ACT

20


11

21

Applying Agile Best Practices AnywhereUser Stories

What Is a User Story?

A Tool for Stakeholder Discovery

Level 1 – MBI (MVP): iPad, v1.0, Web Access & Communication

Level 2 –MMF/FCC/Themes:

• Web Surfing

• Emailing

• Music Listening

Level 3 – Email Epics:

• Manage Contacts

• Send Messages

• Attach Content & Links

MANYEPICS

22




Level 3 – Epics (for E-Mailing):

• Manage Contacts

• Send Messages

• Attach Content & LinksLevel 4 – Stories:

• Create Contact

• Update Contact

• Delete Contact

• Sort Contacts

1 EPICMANY

STORIES

12

23




Level 4 – Stories:

• Create Contact

• Update Contact

• Delete Contact

• Sort Contacts

Level 5 – Tasks:

• Code Fields

• Configure DB

• Wireframe GUI

MANY

TASKS

ONE

STORY

24



What is a Good User Story?

Good stories have six characteristics:• Independent• Negotiable• Valuable (to the Customer)• Estimatable• Small• Testable

Bill Wake, author of Extreme Programming Explored and Refactoring Workbook, is credited with creating the mnemonic INVEST.

13

25



A Tool for Team–Stakeholder Communication

User Story Description

As a: User or Role

I want: Requirement or Functionality description

So that: Reason or Justification

Acceptance Criteria

Given: Specific situation

When: Specific action

Then: Desired result

26





As a: Email User

I want: To sort my emails

So that: I can find email from specific people

Acceptance Criteria

Given: I am logged into my email account

When: I click the “Sort by Sender” option

Then: All emails are displayed by Sender

14

27




User Story DescriptionAs a: Bank Customer

I want: To deposit cash into my account using an ATM

So that: I can make deposits during non-working hours

Acceptance Criteria

Given: I have logged into my account

When: I put the cash into the machine

Then: The ATM confirms the amount with me before finalizing the transaction.

28





As a: Frequent Flyer

I want: To recall past itineraries

So that: I can quickly rebooked flights to regular clients

Acceptance Criteria

Given: I am logged into my airline account

When: I select My Itineraries

Then: All previous flights are displayed

15

29





As a: Remote system user

I want: Access to sales order system via my tablet PC

So that: I can support client requests from their office

Acceptance Criteria

Given: I am servicing a client account remotely

When: I use my tablet PC to enter sales orders

Then: All needed input fields are displayed

30




Non-functional stories are “architectural” or “engineering” or “system” requirements, such as:

• Performance

• Portability

• Reusability

• Maintainability

• Accuracy (of data or reports)

• Adequacy (of data or reports)

• Security

• Interoperability

16

31




Team Formation (3 minutes)Choose a Project Manager Choose a Time KeeperChoose a Scribe

Document & Deliver (7 minutes)1. Your Team is planning a Vacation

using stories to identify the preparation needed.

2. As a Team write 2 User Story Descriptions. (Scribe record.)

3. Individually write 1 User Story Description.

QUESTIONS?

Exercise GuidelinesPlease do NOT do anything until I say “Go!”

You will have 10 minutes.

32




Large Group Discussion1. What part of this process was the

easiest or hardest, most confusing?

2. What challenge in your work might this help mitigate or solve?

3. Any questions or observations about writing the story Description?

Exercise Retrospective

17

33




What Are Acceptance Criteria?

• Validation that stories work the way the Customer expects

• A “bracketing” device so development stays Barely Sufficient

• A prompt to not overlook uncommon situations

• Sometimes called Conditions of Satisfaction

Best Practices:

• Criteria should be written as early as possible because they make development more effective and efficient

• Criteria should avoid jargon or tech spec overuse

34




Create Acceptance Criteria by Asking:

• What else does the Development Team need to know?

• What assumptions are being made about user behavior?

• What alternate situations may cause unanticipated user interactions? What will result from those actions?

• What can be done “wrong” when executing this story?

Best Practice:

• Always assume Murphy is coaching the End User

18

35




Document & Deliver (7 minutes)

1. Using your Team Descriptions, work together and add 1 Acceptance Criteria to each. (Scribe record.)

2. Individually write an Acceptance Criteria to your Description.

QUESTIONS?

Exercise GuidelinesPlease do NOT do anything until I say “Go!”

You will have 10 minutes.

36




Large Group Discussion

1. What part of this process did you find hard or confusing?

2. Where might you apply this tool in your work? How would you expect it to help?

3. What observations have you made about writing User Stories that you can share when you return to your work environment?

Exercise Retrospective

19

37




Consider the Acceptance Criteria for a Simple Task

Task: Make toast for breakfast. ( Remember, Murphy is involved!)

Let’s make toast American style: You burn, I’ll scrape.

W. Edwards Deming

38


20

39

Applying Agile Best Practices AnywhereAgile Estimates

What Is an Agile Estimate?

A Tool to Eliminate Waste via Team–Stakeholder Communication

Agile Estimates:

• Apply sizing to determine work effort.

• Use minimal (optimal) effort to provide planning-level accuracy and avoid additional effort that only increases cost.

• Support integration of uncertainty to manage schedule variance.

• Fit with frequent delivery of small working increments to reliably map progress for improved planning.

40



Recognize the Cone of Uncertainty & Non-Linear Distortion

…3, 2, 1…13, 8, 5

… 34, 21… 89, 55

∞…144


21

41




Apply Granularity to Avoid WasteInvestment Aligned to Planning Thresholds

PROGRAM 1

PROGRAM 2

PROGRAM 3

PROGRAM 4

MMFMBI /MVP

(ROADMAP)

MVO FFC STORY(ITERATION)(RELEASE)

BLUEPRINTS

PLANNING /SCHEDULING

LONG-LEAD

BUILD

R&DFunding

ROADMAPFunding

RELEASEFunding

DEVELOPMENTFunding

42




Apply Granularity to Avoid Waste

XL LARGE MEDIUM SMALL XS

Affinity Estimating (aka T-shirt Sizing)

22

43




Apply Granularity to Avoid Waste

Affinity Estimating Exercise

XL:3 Years

LARGE:2 Years

MEDIUM:1 Year

SMALL:6 Mos.

XS:3 Mos.

DEVELOP LAUNCHVEHICLE

MEDIUM

DEVELOPINTERPANETARY

COMMAND MODULE

DEVELOP MARSINSERTION

SYSTEM

LARGE

DEVELOP MARSLANDINGSYSTEM

DEVELOP MARSASCENTSYSTEM

DEVELOP EARTHINSERTION

SYSTEM

DEVELOP BASECOMMAND

STATION

DEVELOP VEHICLERECOVERY

SYSTEM

44




DEFINING Story Points Story Points:

• Are a relative type of measure

• Correlation to hours or days is unimportant

• Increase precision from the “T-Shirt” sizes used during Affinity Estimating for Releases or Road Maps

To avoid confusion about Story Points remember:

• Story points from one team ≠ Story points from another team

• The sum of the estimates of Tasks ≠ The original User Story

23

45




WHY Planning Poker WorksPlanning Poker uses:

• Multiple sources of Expert Judgment = the Team

• Independent Expert Judges = improve reliability

• Comprehensive peer-level discussion = improve accuracy

• The Bell Curve compensates for uncertainty and missing information

• Fun to unlock collaboration, creativity, and commitment

46




HOW Planning Poker WorksCentral Limit Theorem (Bell Curve)

• Any one story point estimate will be skewed – underestimated or overestimated

• An iteration's sample of stories will be normally distributed

The result is imperfect estimates reliably predict the work of an iteration. Imperfect and reliable!

24

47




Sizing a Group (Sample) of User Stories

1. Choose a midpoint.

2. Compare the relative size of the other items in the group

HOW Planning Poker Works

48



Planning Poke Exercise – Round 1

1. As a Large Group pick the “midpoint” object; define it as size 8.

2. Individually, size to the other objects (1, 2, 3, 5, 8, 13, 21)

3. Number can occur more than once, or not at all.4. After everyone is done,

as a Team review and size the objects.

Use this process:(a) Start at top of list.(b) Share your numbers.(c) Outliers, explain why.(d) Re-vote.(e) Negotiate the final size.

25

49



Planning Pokers Cards

Laminated cards, Apps & DIY index cards.

Using a ? or an ∞ card.

50



Planning Poke Exercise – Round 2

1. As a Large Group pick the “midpoint” car; define it as size 8.2. Start at the top and individually choose a card as the car size.

(1, 2, 3, 5, 8, 13, 21, 34, 55 or 89)

3. On the count of 3, everyone shout their number at once!

4. Outliers, explain why.5. Re-vote.6. Negotiate final size.

26

51




52


27

53

Applying Agile Best Practices AnywhereAgile Schedules

What Is an Agile Schedule? A Team–Stakeholder Communication Tool

Scheduling Principles

Principle #1The core purpose of planning is to support decision making; nothing more, nothing less!

Principle #2“It is better to be roughly right… than precisely wrong!”

John Maynard Keynes (British economist, 1883-1946)

Principle #3Derived schedules “auto-magically” correct estimation bias!

54



Scheduling Principles

Principle #3 (expanded)

Derived schedules “auto-magically” correct estimation bias!

• By measuring velocity, the actual progress being made, a Derived Schedule can reliably forecast the probability of achieving future outcomes!

• Derived Schedules also achieve reliable forecasts of future outcomes without re-estimating the remaining work items by replacing forecast velocity with actual velocity and calculating the impact.

28

55



Scheduling – Core Concepts

1. Agile defines work in User Stories.

2. Agile estimates Size and calculates (derives) the Schedule.

3. Schedule Duration is planned and managed using Velocity.

• Velocity is the unit-of-measure for Schedule progress.

• Velocity is the sum of story points completed in an Iteration.

• The number of Iterations in a Release or Roadmap can be planned using Forecast Velocity and evaluated using Actual Velocity.

• The number of Iterations is the Derived Schedule.

56




4. Velocity is a simple way to plan and measure progress towards Customer Value.

• Velocity emerges and stabilizes, quickly, because Iterations are short delivery cycles.

• Sometimes, for example when doing Bid & Proposal work, it is not feasible to wait a few Iterations to observe Velocity.

• Use Forecast Velocity during planning and the first iteration.

• Replace Forecast Velocity with Actual Velocity as soon as it is available.

29

57




5. Forecast Velocity can be estimated and/or calculated.

Example 1: Group batches of work (i.e., estimate), sum the Story Points, and “smooth” using “expert judgment.”

Example 2:

• Development Team = 6 SME’s

• 6 SME’s x 5 days x 4 weeks = 120 Actual days

• 120 days x 60% efficiency = 72 Planning (Ideal) days

• 72 days = Iteration Planning Limit

• Iteration Planning Limit = Forecast Velocity

58



Scheduling – Velocity Charts

ITERATION

ST

OR

Y P

OIN

TS

CO

MP

LE

TE

D

TIMENOW

FORECAST VELOCITY23

30

59



Scheduling – Velocity Driven Planning

ITERATION

ST

OR

Y P

OIN

TS

CO

MP

LE

TE

D

LOWAVG

=18

HIGHAVG

=26

AVGOF 10 = 22

REMAINING WORK= 184 STORY POINTS

BEST CASE = 7.1 ITERATIONS

AVG. CASE =8.4 ITERATIONS

WORSE CASE =10.4 ITERATIONS

60



Scheduling – Velocity Guidelines

• Do not overcomplicate Velocity’s innate simplicity.

• New teams should be cautioned about over-reaching because getting to Done-Done is more challenging than they realize!

• New teams should only commit to an Iteration Goal that is one-third of their estimated capacity.

• The best forecast of Future Velocity is “Yesterday’s Mail” or “Yesterday’s Weather.”

31

61

Applying Agile Best Practices AnywhereThe Agile Lexicon

Understanding Agile Speak

Cross-functional Teams

• Ideal Team Size = 7 +/- 2

• Too Big = Ineffective due to communication break down

• Too Small = Inefficient due to “overhead” costs

• Self-directed, Self-organized or Self-managed

• Tacit knowledge and Tribal knowledge

• Teams benefit from coaching and on-going training

62



Sprint (Iteration) Planning Meeting

• Attendees are Product Owner, Scrum Master and Development Team

• Product Owner proposes the Sprint (Iteration) Backlog

• Team clarifies assumptions about User Stories until making “Soft Commitment”

• Team decomposes User Stories into Tasks and decides on development approach then makes “Hard Commitment”

• This process negotiates a Reciprocal Commitment.

32

63



Daily Scrum (Stand-up) Meeting

• Time-boxed to 15 minutes

• Every Team member must attend and participate

• Uses three key questions:

1. What have I done since our last meeting?

2. What will I do before our next meeting?

3. What obstacles are hindering or delaying my work?

Best Practice:• Seven Second Rule

64



Review Meeting

• The meeting is Product-centric

• Demonstrate completed work and reduce uncertainty

• Not a surprise to the Customer/Proxy

• Shows User Stories completed and aligned to Done-Done

• Affects Backlog grooming and defines Velocity

Best Practices:

• Invite all Stakeholders to ask questions and request/suggest changes.

33

65



Retrospective Meeting

• The meeting is Process-centric

• Objective is to improve the Team’s development process

• The Prime Directive’s governing principle is, “Regardless of what we discover, we understand and truly believe everyone did the best job they could have, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.

Best Practice:

• This should be a fun meeting with a high team WIIFM

66



Retrospective Meeting

• Time-boxed to 2 hours

• Agenda:

• What Went Well

• What To Improve

• What To Find Out

ALTERNATE SCHEMA:1. Try – Keep – Stop2. Fears – Hopes – Expectations3. Same – More – Less 4. Enjoyable – Frustrating – Puzzling

34

67



Definition of Done

• Governing Principle: A a clear understanding of “Done” is required to avoid over- or under-development

• The PMBOK® Guide says, “…everything the customer contracts for, nothing more and nothing less…”

• Agile says, “Barely Sufficient”

• Done-Done is defined as, “A product feature that is complete, tested, defect-free, and may be put into production (i.e., released to the customer).”

• Four Levels of Done is defined as Unit Tested, Regression Tested, System Tested and User Acceptance Tested.

68



Information Radiator – Story Board

PRODUCT BACKLOG

ACCEPTEDDONEIN-

PROGRESSITERATIONBACKLOG

= GREEN = YELLOW = RED

35

69



Information Radiator – Kanban Board

Analysis& Prep

ProductBacklog

Queue PDR Queue CDR Queue Mock-Up

70



Information Radiator – Burn-down Chart

(Baseline)

Mastering Agile Fundamentals · The Agile Manifesto Snowbird, UT – 17 Contributors, 2001 We...

Documents

Transcript of Mastering Agile Fundamentals · The Agile Manifesto Snowbird, UT – 17 Contributors, 2001 We...