Agile

An introduction for PMPs

Agile beginnings

1990 circa: Many late schedules and death marches to delivery

2001: Agile Alliance created

1995 circa: Many new SW development methods piloted XP, Scrum, FDD, etc

The Agile Manifesto (2001)

We are uncovering better ways of developing software by doing it and helping others do 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
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas www.agileAlliance.org

Principles of Agile
1.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2.

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. 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. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. http://agilemanifesto.org

3. 4. 5.

6.

Principles of Agile
7. 8.
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. essential.

9.

10. Simplicity--the art of maximizing the amount of work not done--is

11. The best architectures, requirements, and designs emerge from
self-organizing teams.

12. At regular intervals, the team reflects on how to become more

effective, then tunes and adjusts its behavior accordingly
http://agilemanifesto.org

Why should we change to Agile?

Improve productivity
with focused teams

Meet quality requirements

by getting to done done at the end of each iteration

Increase customer satisfaction

by engaging endusers/beta sites early

Increase project transparency

with demoing & delivering working software early
and often

Lots of Agile methods & practices

They are all similar!!!

Scrum

Dynamic System Development Method (DSDM) Extreme Programming (XP)

Test Driven Development

Lean Software Development Crystal

Feature-driven development (FDD)

etc

Lots of Agile methods & practices

Scrum popular (US) project management method
Dynamic System Development Method (DSDM)
popular (Europe) project management method

Extreme Programming (XP) pair programming, and

more developer best practices + story driven

Test Driven Development design the test framework

before writing all the code

Lean Software Development learnings from

manufacturings lean six sigma

Crystal a set of maturity models

etc

Agile Practice Penetration @Microsoft

Source: Usage and Perceptions of Agile Software Development in an Industrial Context, Begel & Nagappan, Sept 2007,

Lets talk about Scrum

Scrum Framework

Small cross-functional teams 7 people +/- 2 Series of Sprints (iterations), 2-4 weeks in duration Each Sprint produces a working increment of software To start a Sprint the team selects & commits to stories from the Product Backlog in priority order To close of a Sprint, we demo/evaluate progress Between Sprints, the Product Owner can modify & reprioritize the Product backlog

Product backlog
Prioritized list of features represented as stories Can adjust between iterations as needed

Managed by Product Owner

Priorities are driven by business value ROI Some stories may be for technical infrastructure
Title Agile for PMP FAQ User Story As a PMP new to agile, I need a FAQ to answer my basic questions around agile and how to get started based upon a common agile issue or question (e.g. What PMBOK processes does Agile replace or modify? ) As a PMP, I need introductory material for the Scrum Master new to agile so that I understand this new role, how to best contribute in this role, and what is expected

Priorit y 1

Scrum Master Definition

Sprint Backlog
A prioritized list of stories taken from the top of the Created at the start of an iteration/sprint A story can be de-scoped (move back to product
backlog) product backlog based on the teams estimate of what can be completed during the next iteration

New stories should not be added during the Sprint

Burndown chart
One of many information radiators, ie dashboard pieces

During Scrum, progress on tasks are tracked then

reported publicly

Manage tasks, estimates and burndown charts

Scrum Meetings
Estimation Meeting
Team meets with product Owner to discuss Backlog Items and assign a
relative size value to each.

Planning Meeting
Occurs at the start of each sprint (iteration). Two parts. 1. Product manager and team meet and agree the next product
increment. 2. Team then determines the tasks for each backlog item.

Daily Scrum Meetings aka Daily Standup

Maximum 15 minutes. Team meets to update the task chart and report on
progress and impediments. What did you do yesterday, today, issues?

Review
Team meet with Product Owner at the end of the sprint to demonstrate the
working software from the sprint.

Retrospective
Team meets with Scrum Master to inspect and adapt on their process.
Slide Credit: 2006, Tobias Mayer/Agile Thinking - http://agilethinking.net

Agile Iteration Cadence

Requirements Are Refined Dev Feature Dev Feature Priority 1 Priority 4 Auto. Tests Auto. Tests Feature 1 Feature 4 Dev Feature Dev Feature Priority 5 Priority 2 Auto. Tests Auto. Tests Feature 2 Feature 5 Dev Feature Priority 3 Accept Auto. Tests Feature 3 Iteration N-1 Iteration N Accept Accept

Accept

Detailed Iteration Planning & Design

Demo & Retro

Initial Elaboration Requirements With Tests

Accept

Iteration N+1

Slide Credit:

Scrum on One Page

Done Done Done

Coded it works on the developers box Verified Unit tested and they work on
Integration box

Validated accepted by ProductOwner as being

what was needed

http://danube.com/blog/dan_rawsthorne/done_done_done_done

Technical Debt
By not enforcing high quality standards in the
definition

of Done. Cutting corners to achieve a higher velocity and

meet

impossible timelines leads to build up of low quality, unmaintainable code. Death spiral: As the maximum velocity of system
goes

down, even more corners are cut to compensate

* Ref: http://danube.com/blog/kanemar/technical_debt_and_the_death_of_design_part_1.html

until

Scrum Roles
Product Owner or PO team Responsible for managing and prioritizing the Product Backlog, and for accepting the software at the end of each iteration

CONSTANT COLLABORATION AND COMMUNICATION ARE KEY

Scrum Master Responsible for shepherding the team, removing impediments, keeping the process moving, and socializing scrum to the greater organization Chickens Users Stakeholders/Sponsors Managers The Team Responsible for estimating size of backlog items, committing to increments of deliverable software and delivering it. Tracks own progress (with Scrum Master). Is self-organizing but accountable to the product owner for delivering as promised.

Requirements process
Progressive elaboration
Themes Marketing/Customer Requirements
Headlines Epic User Stories

User Stories Product Backlog / Features

Headlines (Epic)
As a user, I want to schedule a service appointment.
Breakdown into user stories:

As a returning user, I want to login to the service

department website

As a user, I want to view recommended service for my

vehicle

As a user, I want to select an appointment date and time

for service

As the system, I want to send the user a confirmation

email once service is scheduled
Slide Credit:

Whats Different about Testing in Agile?

Just-In Time Requirements Elaboration

No Functional Spec waterfall docs to drive test
planning Requirements and Test Cases developed in parallel or test first strategy

More Frequent Iterations, More Frequent

Releases

Testing needs to happen Early and Often Frequent to continuous regression testing High need to automate nearly everything Everyone needs to Test
Slide Credit:

Two Levels of Testing

Iteration Vs. Release testing patterns