© Freddie Mac 2010 1

Our Expertise and Commitment – Driving your Success

Agile 101 Training

February 2014

By: Jean Ballard and Kurt Rasmussen

2

Agile 101 Training Agenda

Part I: Agile Overview» Agile– What it is?

» Agile vs. Waterfall

» Why Agile

» Who - Agile teams

» Key terms

» Assessment

Part II: Project Management with Agile» Project lifecycle

» Planning

» Requirements

» Key milestones

What is an Agile Process?

3

In principle: Any process that adheres to the principles of 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 toolsWorking software over Comprehensive documentationCustomer collaboration over Contract negotiationResponding 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.”

Manifesto for Agile Software Development, www.agilemanifesto.org

Agile principles

4

The Agile Manifesto is based on twelve principles:

1. Customer satisfaction by rapid delivery of useful software2. Welcome changing requirements, even late in development3. Working software is delivered frequently (weeks rather than months)4. Close, daily cooperation between business people and developers5. Projects are built around motivated individuals, who should be trusted6. Face-to-face conversation is the best form of communication (co-location)7. Working software is the principal measure of progress8. Sustainable development, able to maintain a constant pace9. Continuous attention to technical excellence and good design10. Simplicity—the art of maximizing the amount of work not done—is

essential11. Self-organizing teams12. Regular adaptation to changing circumstances

5

What is Agile Software Development?

Process that allows focus on delivering the highest business value in the shortest time.

It allows rapid and repeated inspection of actual working software (every 2 weeks to 1 month).

The business sets the priorities. Teams self-organize to determine the best way to deliver

the highest priority features. Can see real working software and decide to release it ‘as

is’ or continue to enhance it for another sprint.

Mountain Goat Software LLC

6

What is Agile? (continued)

What is it: Provides complete project transparency Facilitates continuous communication Maintains team continuity and team focus Pro-active mitigation of project risks Appropriately aligns expectations

What Agile is NOT: Not a panacea for perfect Project Management Not just a management reporting tool Not one size fits all Not just for application development

7

Agile vs. Waterfall

Command and control

Detailed planning up front

Sign-offs

Protect project scope

Show results at end

Weekly project meetings

Working together

Communication frequency

Getting things done

Planning

Scope

Getting feedback

Leadership, facilitation, communication

Commitments

Detailed planningIn chunks

Project Sprint scope

Show results at endof every sprint

Daily Scrum meetings

Waterfall Agile

8

Earlier delivery of value to the customer

Faster time to market; higher priority functionality deployed first

Reduced waste and costs; increased quality

Improved predictability of delivery

Increased productivity from self-organizing, collaborative, adaptive, and cohesive teams

Increased project team satisfaction

Lower project risk through higher visibility

Improved stakeholder satisfaction!!!

Why Agile?

9

Agile Team Composition

Composition of an Effective Agile Team

A. Select domain experts that cover the spectrum aligned with project delivery

B. Ensure that all team members are willing and able to accept multiple roles

C. Make sure that appropriate knowledge is spread across the team

D. Establish core team principles (e.g. team will be self organizing) and a shared vision that is clearly defined

E. Promote effective communication (e.g. face-to-face), mutual trust, and collaboration

F. Set up an environment that rewards constant improvement

G. Ensure that the Product Owner / Business Customer is hands on - They are Team Members too.

10

Agile Key Terms

Term Definition

Backlog also known as product backlog. A prioritized features list, containing short descriptions of all functionality desired in the product.

Epic states the theme of a group of features. A user story which describes a large amount of customer value and must be broken down into smaller user storied.

User Story states the functionality of a feature as told from the point of view of the Business User. Describes the Who, What, Why in simple-to-understand language.

Release An increment of potentially shippable product from the development team into routine use by customers.

Iteration A period of time in which software development activities take place and result in delivery of working software. Similar in nature and definition as a sprint.

Sprint  a “time-boxed” period of work, with a closely defined and agreed output - generally 2-4 weeks.

Scrum Agile development project management framework based around sprints and generally comprised of the scrum team.

Velocity how much product backlog effort a team can handle in one sprint

Task a unit of work generally between 4 and16 hours. 

11

Agile Basics Assessment

?

12

Part II: Project Management with Agile

13

Agile Lifecycle Overview

14

Agile Planning

Planning Level Planning Description

A. Product vision What, who, why, when, assumptions constraints determined by Product Owner

B. Product roadmap Releases – dates, feature sets, objective, product backlog

C. Release planning Sprint / Iteration, team capacity, user stories, priority, size, estimates, definition of done

D. Sprint planning User Stories – tasks, level of effort, commitment, sprint backlog

E. Daily planning What did I do yesterday?, What am I going to do today? What are my obstacles?

15

Release Planning

Product

Owner

Introduce

s Goal

• Allows team to understand motivation behind release goal• Positions team to identify the scope that can be completed by the release date

Estimate

Team Veloc

ity

• Best used if team hasn’t changed• For Fixed Release Date: Velocity = # of Sprints in Release X Velocity of Last Iteration

Review

User Stories

• Product Owner presents User Stories to Development Team• Developers ask questions about User Stories• User Story are described at a high level (Avoid getting into the weeds!)

Estimate

User Stori

es

• Developers produce estimates based on predetermined scaling schema• Each User Story is discussed for 2-minutes MAX

Assess

Technical Risk

• Development team assesses technical risk for each User Story• Risk is classified as High, Med, Low

Select User Stories for Relea

se

• Prioritize User Stories based on value, estimates, and technical risk• Consensus needs to be reached on the release plan with everyone present stating their commitment

verbally

16

Sprint Planning

• Team selects items from the product backlog they can commit to completing

• The team commits to completing what they select• It’s a team commitment, not a set of individual commitments

• Sprint backlog is created– Tasks are identified and each is estimated (1-16 hours)

– Collaboratively, not done alone by the ScrumMaster

• High-level design is considered

As a Claims Reviewer, I’m able see what claims are assigned to me, so I don’t miss reviewing a claim.

As a Claims Reviewer, I’m able see what claims are assigned to me, so I don’t miss reviewing a claim.

Code the middle tier (8 hours)Code the user interface (4)Write test fixtures (4)Code the foo class (6)Update performance tests (4)

17

Sprint Management: Daily Scrum

• Parameters

– Daily, 15-minutes, Stand-up

• Not for problem solving

– Whole world is invited

– Only team members, ScrumMaster, product owner, can talk

• Helps avoid other unnecessary meetings

Three questions answered by all participants:

1. What did you do yesterday?

2. What will you do today?

3. Is there anything preventing you from completing your tasks?

18

Documenting Requirements

The requirements (user stories)

A list of all desired work on the project for a product

Ideally expressed such that each item has value to the users or customers of the product

Prioritized by the product owner

Reprioritized at the start of each sprint

This is the product backlog

This is the product backlog

Product backlog

19

Documenting Requirements

Backlog item

User Story #1399: As a Manager, I'm able to view all the claims in the workflow (Management View), so I know what claims need to be paid.

User Story #1403: As an Assignee, I'm able to receive an alert email with a link to my To Do View, at certain time increments and if status is Red, so I can easily access the claims in my queue.

User Story #1452: As an Insurance Ops Associate, I'm able to BATCH separately LAE & Commutations in CPMS, so Cash Mgmt & Finance can review the Batch Report for each. (One-to-One)

User Story #1467: As a Cash Management User, I'm able to upload a document confirming that US Bank received wire from MBIA, so I can confirm that the wire was sent and the task is approved.

User Story #1477: As a Claims Reviewer, I'm able to Terminate a claim, so it will be removed from the CPMS and will not get paid.

...

A sample product backlog:

20

Post-Sprint: Sprint Demo

• 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

• No slides

• Whole team participates

• Invite the world

21

Putting It All Together