Presented by Only Agile. Agile Project Management

Agile

Project Management

Introductions

Roy Schilling

Agile Coach/Trainer

CSM, CSPO, CSP, PMI-ACP

30+ years in IT

10+ years practicing Agile

Session Approaches

Approaches to learning in this session:



Cell phones on silent



One conversation at a time



The goal is understanding vs. slide coverage



Use Backlog for future discussions

Session Objectives



Present Agile benefits



Provide a solid understanding of Agile

principles and practices



Present methods for planning, tracking

Exercise:

Distribution

2 Minutes

Agile/Lean Knowledge

1 Awareness – heard of it, read about it.

2 Limited – dabbled in it, used some of the techniques.

3 1-2 years of experience with some practices and principles.

4 3+ years of experience with some practices and principles.

5 5+ years of experience with practices and principles.

Burning Questions

10 Minutes

In Each Group

• Introduce yourselves, if you haven’t already

• Develop questions about Agile that your group would like to have answered before the end of the course

• Write each question on a post-it - 1 question per note

• Each group read their top question

Why Agile?

9% 10% 11% 14% 15% 16% 18% 23% 26% 29% 37% 39% 37% 40% 39% 35% 42% 46% 42% 48% 39% 51% 46% 38%

Improve/Increase Engineering Discipline Enhance Software Maintainability/Extensibility Improve Team Morale Reduce Cost Simplify Development Process Reduce Risk Project Visibility Enhance Software Quality Better Align IT/Business Increase Productivity Manage Changing Priorities Accelerate Time to Market

Highest Importance Very Important Somewhat Important Not Important

What is Agile?

Practices

Principles

Values

“Agile is an idea supported by a set of values and

principles. Agile defines a target culture for

successful delivery of product.”

Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

That is, while there is value in the items on the right, we

value the items on the leftmore.

Individuals and interactions

over

processes and tools

Working software

over

comprehensive documentation

Customer collaboration

over

contract negotiation

Agile Principles

1)

Satisfy the

Customer

2)

Welcome

changing requirements

3)

Deliver

working software frequently

4)

Business people and developers

working together

daily

5)

Build projects around

motivated

individuals

6)

Face-to-face

conversation

is the best form of communication

7)

Working software

is the principle measure of progress

8)

Agile processes promote a

sustainable

pace

9)

Continuous attention

to technical excellence & good design

enhances agility

10)

Simplicity

11)

Self-organizing

teams

Methodologies

52% 14% 9% 8% 3% 3% 2%2% 2% 2% 1%1%1% Scrum Scrum/XP Hybrid Custom Hybrid Don't Know Kanban Scrumban Feature-Driven Development Extreme Programming XP Lean Other

Agile Unified Process (AgileUP) Agile Modeling

Dynamic Systems Devlelopment Method (DSDM)

Scrum in a Nutshell



Split your organization into small cross-functional

teams.



Split your work into small concrete deliverables.

Prioritize and estimate relative to other work.



Split time into short, fixed-length iterations.



Optimize and update priorities in collaboration with

your customers.



Optimize your process through retrospectives after

each iteration.

Kanban in a Nutshell



Visualize the workflow

 Split the work into small pieces

 Use named columns to visualize the state in the workflow



Limit Work in Progress (WIP)

 Assign explicit limits to how many items may progress in each workflow state



Measure the “Lead” time

 Lead Time = average time to complete one item

 Optimize the workflow to make the lead time as small and predictable as possible

Which Tool is Best?

Tool

= anything you use to accomplish a task or purpose

Prescriptive or Adaptive

Waterfall (Many) RUP (120+) XP (13) Scrum (9) Kanban (3) Do Whatever (0)

Fixed

Estimated

Plan Driven or Value Driven

Features Time Time Features/Value Budget Budget Plan Driven Value/Vision Driven

Traditional

Agile

We tend to build the wrong stuff

Never 45% Rarely 19% Sometimes 16% Often 13% Always 7%

Prioritization



Financial Value

 Return on Investment (ROI)

 Net Present Value (NPV)

 Internal Rate of Return (IRR)



Customer Value

 MoSCoW

 Must Have, Should Have, Could Have, Won’t Have

 Kano Analysis

 Must Be, Performance, Delighter, Not Relevant

 Cost of Delay / Weighted Shortest Job First



Risk-Adjusted Backlog

 Expected Monetary Value (EMV) = Risk Impact ($) * Risk Probability (%)

 Risk Factor (RF) = Risk Impact (Days) * Risk Probability (%)



Relative Prioritization / Ranking

 Ranked Order List

Risk

High Risk

Low Value

High Risk

High Value

Low Risk

Low Value

Low Risk

High Value

Source: Agile Estimating & Planning by Mike Cohn Do last, if at all

High

Low

Minimize Risk and Realize Value

Agile delivers value incrementally while

reducing the risk of failure over time.

Resource Allocation

Build Test Define Build Test Define

Multiple projects Assigned but not many tasks yet Multiple projects,

rolled off some

Build

Test Define

Resource Optimization

Exercise:

Focus

Rules:

• Instructor will give you the rules

Materials:

• Sheet of paper and writing utensil

Team Structures

Features Features Product Backlog Features Features Features Features Middleware UI Backend Feature A UI MW BE Product

In

te

g

ra

ti

o

n

Feature A UI MW BE Feature B Feature C Feature A UI MW BE UI MW BE Features Features Product Backlog Features Features Features Features Agile Team B Agile Team A Agile Team C Component Teams

Colocated / Distributed Teams



Common Practices



Team norms



Core hours



Working agreements



Colocated



Osmotic Communication



Tacit Knowledge



Distributed



Webcams



Instant Messaging



Interactive Whiteboards



Heavier reliance on documentation



Colocate geographically

Cone of Uncertainty

Requirements Design Code Test Deploy

Uncertainty

Cost of change increases over time

Progressive Elaboration

The process of adding more detail as information emerges



Plans



Architectural designs



Risk assessments



Requirements definitions



Acceptance criteria



Estimates



Test scenarios

Continuous Planning

Vision Roadmap Release Sprint Daily Big Picture

As necessary by Product Owner/Stakeholders

Ties Vision to Approach

Every release by Product Owner

View of Horizon

Every release by Product Owner and Team

Near-term Plan

At the start of each sprint by Team

Inspect and Adapt

Traditional Roadmap

Days 90 180 270 360 0

12 Month Roadmap

Project A Project B Project C Enhancements

Agile Roadmap

Days

90

180

270

360

0

Release Plans– MVP/MMF

Search

Search PayPay ShipShip

By Title By Title By Credit Card By Credit Card Via UPS Via UPS Via USPS Via USPS By Gift Card By Gift Card Via FedEx Via FedEx By Pay Pal By Pay Pal By Genre By Genre By Author By Author

Buy a Book

Buy a Book

Buy known book by credit card and ship via UPS ground

Buy known book by credit card and ship via UPS ground

Story Map

Pay Ship Search by Genre Pay by Gift Card Pay by Credit Card Ship Via USPS Search by Author Ship via FedEx Ship via UPS Pay by Pay Pal Select Shipping Options Wish List Store Account Data Modify Account Data Delete a Book Enter Payment Info C ri ti c a li ty Always Use Seldom Use

Requirements



Brief, simple statement from a User perspective



Emphasize verbal rather than written communication.



Clearly defined acceptance criteria



Great for planning



Starting point for a conversation



Details will come later

As apatient,

I want access to my test results online,

so that I don’t need to call the doctor. Story ID Risk Estimate Value Who What Why

The system shallprovide access to test results online

Acceptance Criteria



Instead of replacing the conversation with an upfront,

detailed document, we allow the details to emerge

through conversations



Acceptance Criteria is the result of the conversations

that we had about the User Story



Acceptance criteria spell out what the Product Owner

expects and what a team needs to accomplish



Acceptance criteria are the story-specific part of the

definition of done

Estimates



Wideband Delphi and Planning Poker



Team-based Estimation



Consensus



Ideal Time



Relative Sizing / Story Points



Based on

Size

and

Complexity

,

not time



Triangulate with other known factors



Smaller stories



Similar stories



Larger stories



Use abstract unit of measure:

Story Points

Yesterday’s Weather



Velocity



Average number of story points completed in a sprint



Lead Time



Average time to complete one item

A good predictor of the future

is what we’ve done in the past

Managing Issues

Potential

Issue

Tooling

The Agile Application Lifecycle Management Tools:



Track all aspects of an Agile Project



Stories



Defects



Iterations



Scrum/Kanban boards



Team member capacity



Progress



Etc.

Tracking Progress - Team

Source: Henrik Kniberg



Whole team maintains task boards



Low-tech, high-touch approach

0 20 40 60 80 100 120 E ff o rt

Burnup

Total Planned Completed Planned

Tracking Progress - Project

0 20 40 60 80 100 1 2 3 4 5 6 7 8 9 10 E ff o rt Date

Burndown

Tracking Investments

Track expenditures by Investment Category –

Where are we spending our money?



Gartner Value Model



Run, Grow, Transform



Geoffrey Moore



Optimize, Neutralize, Differentiate



Custom



New Market, Maintenance, Cost Savings

Definition of Ready

How do you know when you’re ready?

Story Ready:



INVEST



Acceptance Criteria



Estimated



Understood



Dependencies



Risks

Sprint/Release Ready:



Little or all research



Dependencies



Goal understood



Infrastructure



Resources

Definition of Done

How do you know when you’re done?

Story Done:



Code



Test



Integration



Documentation



Configuration

Sprint/Release Done:



User Manual



Training



Release Notes



Install Docs



Scripts

Measuring Teams

Reliability

Value

Quality

Improvement

Agile Contracts



Money for Nothing, Change for Free

 Standard fixed price contract, some T&M for extra work

 “Change for Free” allows change to occur for no extra cost

 “Money for Nothing” allows for early termination if no value



Fixed Price Work Packages

 Smaller sequential SOWs

 Vendor can re-estimate subsequent packages based on new information/risks Fixed Estimated Features Time Time Features/Value Budget Budget Plan Driven Value/Vision Driven Traditional Agile

Scaling – SAFe

Keys to Agility



Small, Empowered Teams



Small, Frequent Releases



Transparency



Continuous Improvement



Eliminate Waste



Limit Work in Progress

Exercise:

Simulation

Rules:

• Each ball must be touched be each team member

• A pass must have air time

• Cannot pass to neighbor (shoulder to shoulder)

• Drop or bad pass, is considered a defect

Planning (2 minutes):

• Plan/design your process

• Give estimate

Iteration 1 (2minutes)

• Pass as many balls as possible

Retrospective (2minutes):

• Review design and plan – Improve

Iteration 2 (2minutes)

• Pass as many balls as possible

Wrap-Up

Only Agile

Email: rschilling@onlyagile.com

URL: www.onlyagile.com