The Agile PMP Workshop

Introductions

Product consultant and agile evangelist for VersionOne

Previously a Senior Project Manager for CheckFree Corporation

PMP, CSM, DSDM Agile Project Leader

Board member of APLN and the current Treasurer. Founder APLN Atlanta

The Agile elevator speech

Umbrella term to describe a family of methodologies:

XP

Scrum

DSDM

AUP

Crystal

FDD

Engineering best practices

Project management methodology

Leadership philosophy

Hidden PM Assumptions

Assumptions of Traditional PM

Assumptions introduce risk

We tend to assume that with enough up front planning that we can make projects predictable

Why Agile?

Not all projects are predictable

Market uncertainty drives change

The less certain we are about our requirements, the more we need to plan to adapt

Technical Pace Novelty Complexity * Reinventing Project Management by Aaron Shenhar and Dov Dvir

The Cost of Change

Cost of traditional change management is too high in many project contexts

Change control is bureaucratic and slow

We become resistant to change when we should embrace change

Ensures acceptable outcomes

Agile costs less when you factor in the cost of change management

Different way of looking at project control

Risk mitigation tactic that be used when assumptions about predictability don’t hold

Managing tradeoffs

New way of looking at the balance between time, cost, and scope

In traditional methodologies we start with scope and estimate time and budget

This results in a false sense of certainty about the features

Unrealistic expectations around the team’s ability to deliver

Time Scope Cost Traditional Project Management

Drive your projects

Turns the Iron Triangle upside down

Agile methodologies define the time and cost and vary the scope

Gives the Product Manger fine grained control on the projects outcome.

Time Cost Scope Agile Project Management

The Case for Agile

Agile Project Management

Empirical process control

Visibility, inspection, and adaptation

Deliver product in short cycles

Inspect what been delivered

Adapt process or requirements based on what the team has learned about the emerging product

Ensures acceptable outcomes

Agile costs less when you factor in the cost of change management

Different way of looking at project control

Risk mitigation tactic that be used when assumptions about predictability don’t hold

Paper Airplane Exercise

The 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:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

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

*www.agilemanifesto.org

12 Principles of the Agile Manifesto

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.

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

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.

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.

Agile Process Overview Vision Q1 Q2 Q3 Q4 Product Roadmap Release Plan

Writing the PM Plan

Process Groups

Initiating

Planning

Executing

Controlling

Closedown

Knowledge Areas

Time

Cost

Scope

Quality

Risk

Communication

Human Resources

Procurement

Integration

Project Doggie Daycare

As part of Doggie Daycare, the local high-end dog salon needs a system that allows customers to:

Schedule dog appointments online.

View dog grooming styles.

View stylist information.

Interact in an online community.

Product Planning

Backlog Fundamentals

Product backlog

A prioritized list of features that the customer would like to have developed into their software product

Backlog item

A high level description of an individual feature in the backlog. It is a placeholder for a future conversation about that feature

INVEST

I – Independent

N – Negotiable

V – Valuable

E – Estimateable

S – Small or Sized Appropriately

T - Testable

Which are Good Backlog Items?

As a dog owner, I want to select a stylist for my dog.

Administrator adds new style to the style catalog.

Develop database schema for the style catalog.

As a dog owner, I want to interact in an online community with other dog owners.

Susie Stylist updates her stylist profile.

Select a calendar day.

Research online credit card processing service.

As a system administrator, I want to add a new stylist profile so that the user may login.

Writing a Good Backlog Item

TEMPLATE

As a _____________ I want to be able to ______________

so that __________________ .

EXAMPLE

“ As a newly trained VersionOne user, I want to be

able to login to VersionOne.org so that I may

rate my instructor.”

Assumes architecture

Valuable to the user

Exercise 1: Doggie Day Care Backlog Items

Write the backlog items for the Doggie Day Care Style Catalog. Some basic requirements are:

Users want to search the catalog for both dog styles and stylist information

Stylists need to be able to update their own information in the catalog

A system administrator needs to be able to manage the stylist’s profiles and access to the style catalog administration area.

More Backlog Fundamentals

Sizing your backlog

Story points

Ideal engineering hours

Ideal engineering days

Prioritizing your backlog

High, Medium, Low

MoSCoW Rules

Rank order

The Project Management Plan

Process Groups

Initiating

Planning

Executing

Controlling

Closedown

Knowledge Areas

Time

Cost

Scope

Quality

Risk

Communication

Human Resources

Procurement

Integration

Release Planning

Release planning is process of determining how much can be delivered in a project by a given date

Typically release planning will be done by fixing the release date, estimating the team’s capacity, and making an estimate of how many features can be delivered in that time

The team’s capacity is determined by considering their historical velocity or by predicting a planned velocity at the beginning of the project

Scoping a Release

Choose the highest priority features first

Include a mix of must have features, should have features, and could have features

DSDM recommends a 60%, 20%, 20% split

The reality is that the team’s velocity is unknown during the early sprints

As you begin to execute the project (and measure actual velocity, you will begin to understand what can really be accomplished.

The team needs flexibility to negotiate content if necessary

Release Planning – a Demonstration

Release goal:

Fully functional Doggie Day Care Style Catalog, with dog owners able to search, stylist able to login and administer their profiles, and system admin able to control security access.

Let’s estimate the backlog items

Prioritize the backlog items

Estimate our velocity

Allocate backlog items to the release

Process Groups

Initiating

Planning

Executing

Controlling

Closedown

Knowledge Areas

Time

Cost

Scope

Quality

Risk

Communication

Human Resources

Procurement

Integration

Sprint Planning

What is a Sprint?

Determining Sprint Length

Scrum recommends a 30 day sprint

Most Agile methodologies recommend between 1 and 4 weeks

Consider the size and complexity o the solution

Number of interdependencies

Degree of automation

Dynamics of the team

Shorter cycles are generally better

Sprint Planning - Part I

Four hours maximum

Attended by Product Owner, Scrum team, customers, management

Product Owner brings the “What”

Team selects as much Product Backlog Features as it believes it can develop during the next Sprint

Estimates may be revised upon review

Lower priority features may be included if appropriate and Product Owner agrees

Estimated effort/cost for selected features is a budget that team manages to; negotiate with Product Owner before exceeding.

Sprint Planning – Part II

Four hours maximum

Team defines how to build the “What”

Attended by product owner, delivery team, development management

Design is extended in this session by decomposing features into tasks, or writing backlog items

Tasks are estimated between 1/2 day – 2 days in size

The list of tasks is called the Sprint Backlog

Team verifies that estimates do not exceed capacity

Team members commit to the sprint

Sprint Backlog

Team collects the tasks in a Sprint Backlog

Similar structure to the Product Backlog

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

Estimates are assigned to tasks by the team

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

Work for the Sprint emerges during the planning session

Work (content, estimates, sign-up) can change during the Sprint

Sample Sprint Backlog

Exercise 2 – Doggie Daycare Planning Your First Sprint

Using the team scenario you are given:

Working from the prioritized product backlog, decide how many backlog items can be added into your sprint

Product owners present the backlog items to the development team and allow them to ask questons

Product owners define acceptance criteria for each backlog item

Developers break the backlog items into tasks, with hour estimates

Process Groups

Initiating

Planning

Executing

Controlling

Closedown

Knowledge Areas

Time

Cost

Scope

Quality

Risk

Communication

Human Resources

Procurement

Integration

Sprint Execution

Executing Through the Sprint

Daily Standup Meetings

Visible Progress/Information Radiators

Agile Reporting

Daily Standup Meetings

Rules:

Daily, 15-minute meeting

Same time, same place every day

No problem solving

Each team member answers three questions:

What did you do yesterday?

What are you doing today?

What is getting in your way?

Action the Impediments

Note the Decisions

Stakeholders are invited to observe but can’t talk:

Take issues to ScrumMaster after the Standup has ended

Optional: collect estimates at the end of the meeting

Visual Progress Indicators (by hand)

Visual Progress Indicators (w/VersionOne)

Exercise 3: Daily Standup Meeting

Using your team scenarios and roles, participate in the daily standup meeting.

Each team member answers three questions:

What did you do yesterday?

What are you doing today?

What is getting in your way?

Action the Impediments

Note the Decisions

Definition of Done

done [duhn] –verb

completed; finished; through: Our work is done.

cooked sufficiently.

worn out; exhausted; used up.

in conformity with fashion, good taste, or propriety; acceptable: It isn't done. —Idioms

be or have done with, to break off relations or connections with; stop.

done for, Informal. a.tired; exhausted. b.deprived of one's means, position, etc. c.dead or close to death.

done in, Informal. very tired; exhausted: He was really done in after a close race.

What is “Done” on an Agile Project?

Designed

Coded

Integrated

Documented

All tests pass

Process Groups

Initiating

Planning

Executing

Controlling

Closedown

Knowledge Areas

Time

Cost

Scope

Quality

Risk

Communication

Human Resources

Procurement

Integration

Sprint Closedown

Sprint Review

Has two parts, typically spans a full day:

Part 1: Demo and Review of Sprint results

Part 2: Retrospective to review Sprint process with the team

Takes place on the last day of the Sprint – no delays

Precedes the next Sprint Planning Meeting

Sprint Demo and Review

Team presents what it accomplished during the Sprint

Typically takes the form of a demo of new features or underlying architecture

Informal

2-hour prep time rule

Attendees

Team (Customer Representative, Developers, Testers, Architect, etc.)

ScrumMaster

Product Owner, Customers

Stakeholders

All other interested parties

No PowerPoint

What is being made visible

Delivered features

Incomplete features

Verifying ‘Done’ with the customer/product owner

Maintaining trust with customer by not “hiding” undone work

Team and Customer responds to the delivery

The Goal: Collaborative Decision-Making about the emerging product

Possible Sprint Outcomes

Removing features from the Product Backlog that the team unexpectedly completed

Restoring unfinished features to the Product Backlog (and reprioritizing if necessary)

Working with the ScrumMaster to reformulate the team (add, remove team members)

Reprioritizing the Product Backlog to take advantage of opportunities that the demonstrated functionality presents

Ask for a release Sprint to implement the demonstrated functionality, alone or with increments from previous Sprints

Choosing not to proceed further with the project and not authorizing another Sprint

Requesting that the project progress be sped up by authorizing additional teams to work on the Product Backlog

Retrospectives

Inspect and adapt at the end of every Sprint

Attended only by the team

Facilitated by ScrumMaster or objective third party

What went well, what could be improved

ScrumMaster prioritizes improvements based on team direction

Team devises solution to most vexing problems

Retrospectives Agenda

What were the major events in our timeline?

What can we observe about the flow of events?

What were the Sprint metrics (tasks completed, actuals versus estimates, resource distributions, builds, bugs etc.)

What have we learned about the product as a result of this Sprint?

What have we learned about the team as a result of this Sprint?

What worked well in our Sprint that we would want to do again?

What do we wish we’d done differently?

What recommendations are there moving forward with our next Sprint?

Inspect the Process not the People

“ Inspect and Adapt”

Exercise 4 – Sprint Review and Retrospective

Review the completed work for the Sprint

Make decisions on uncompleted work

Conduct a team retrospective, using SAMOLO:

What would we do the Same As before?

What would we do More Of?

What would we do Less Of?

Build a list of action items and assign them

Review the team issues list

Reviewing your PM Plan

Process Groups

Initiating

Planning

Executing

Controlling

Closedown

Knowledge Areas

Time

Cost

Scope

Quality

Risk

Communication

Human Resources

Procurement

Integration

Adopting Agile Culture

Agile PM Model

Project Manager as the center of the project

Project manager as an enabler

PM Team Team Team Team Team Team Team Team PM

Empowerment

Create the context

Social Engineering

Process has to be managed

Self-Organization " Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior.” Dee Hock, Founder and Former CEO of Visa International

Trust