agile project management part 1 final

Agile Project Management

Part 1Part 1

Matthew Hodgson & Maria Horrigan Murphy

Senior Consultants

SMS Management and Technology

1May 2009

An Agile Agenda

1. Managing projects

2. What is Agile?

3. Why Agile

4. Break 10 minutes

Questions as

we go

4. Break 10 minutes

5. Agile as a philosophy

6. Case studies

7. Learnings

8. Conclusions

2

Take-aways

Quick Reference Guide

Evaluation survey

Slides available on DNET

3

Managing projects

From PM to Agile

4

Traditional PM Methodologies

Prince2

Projects IN Controlled

Environments (PRINCE)

Tends to prescribe how

projects should be

PMBOK

Project Management Body

of Knowledge

Generally describes project

processes and activities

VSVSVSVS

projects should be

controlled

processes and activities

5

Prince2

Developed by:

UKs Office of Government Commerce

Structured approach, provides a method for managing projects within a clearly defined framework

Describes:

Control and organisation of projects -- deliberately not restricted to Control and organisation of projects -- deliberately not restricted to IT projects.

Procedures to coordinate people and activities in a project

How to design and supervise the project

What to do if the project has to be adjusted if it doesnt develop as planned

Specifies:

Process with its key inputs and outputs

Goals and activities gives automatic control over scope deviations

Prince2 Processes

7

Even though Prince2s popularity makes it a de facto standard for project

management , it is criticized for being too prescriptive, too big and not easily customisable.

Its more about

how to

manage, but

not what

activities to do

PMBOK

Developed by:

US-based Project Management Institute (PMI).

Internationally recognised standard providing the fundamentals of project management, not limited to IT-projects.

Five process groups:

Initiating, Planning, Executing, Controlling and Monitoring, and Closing. Initiating, Planning, Executing, Controlling and Monitoring, and Closing.

Nine knowledge areas:

Project Integration Management, Project Scope Management, Project Time Management, Project Cost Management, Project Quality

Management, Project Human Resource Management, Project

Communications Management, Project Risk Management, and Project

Procurement Management.

More project

processes?!

9

Process success measures?

Through management of a project:

On time

On budget

Mitigated risks Mitigated risks

Met users expectations

Met business objectives

10

Process success measures (cont)

Are these the only measure of a successful project?

Can a project be considered successful if NOT delivered on time, on budget, meeting NOT delivered on time, on budget, meeting

specifications?

11

What if a project ...

Budget:

Est $425M

Actual $2,435M

Timeframe:

Est 1965 due date

Actual 1973 first finished

12

Almost a

decade late!

Sydney Opera House project successes

Delivered :

Iconic identity to Sydney & Australia

Culture to Sydney Culture to Sydney

Computer modelling engineering firsts

Revolutionary pre-fabrication methods

- 13

Sydney Opera House an Agile project

Iterative:

Design team went through twelve iterations before a

workable solution was completed.

Passed on lessons learned to engineering community:

New use of computer structural analysis to

understand the complex forces to which the shells

would be subjected

14

So what is Agile?

We can't know what the future's going to look like. We have to be agile enough to be

able to respond to that uncertainty.

- Linton Wells II

15

When people talk about Agile

16

Iterative 60%

Test Driven 20%

No Documentation 10%

Collaboration & social engineering 10%


early stakeholder involvement

no documentation

test driven development

feature-driven

continued integrationseliminate waste

flexible

light-weightfast moving

nimble

collaboration

adding-value

17

rapid iterations

working software

the name

the team sets their own priority

adapt to change

people before process

small iterationsaccepting changes

coping with change

communication

adaptable

About people

user-focus


early stakeholder involvement

no documentation

test driven development

feature-driven

continued integrationseliminate waste

flexible

light-weightfast moving

nimble

collaboration

adding-value

18

rapid iterations

working software

the name

the team sets their own priority

adapt to change

people before process

small iterationsaccepting changes

coping with change

communication

adaptable

About people

user-focus

AgileIS

About people, teamwork, and collaboration

About delivering real business value and outcomes

Producing light-weight documentation to get the job done

Managed iterations

ISNT

A Silver Bullet solution

Just for IT projects

An excuse for poor requirement

definition

An excuse for poor design Managed iterations

Responding to business changes

Managing change

Simple, fast and efficient

Based on industry best practice

Disciplined and structured

Built-in validation of solutions

Contingent workforce and activities

An excuse for poor design

An excuse for reducing quality

About failure to control the scope

of a project, its about managed

change

Doing more with fewer people

Doing more with less resources or

budget

Complex

Chaotic and unstructured

19

Ultimately, Agile is a lot like life

Things change

We adapt

We learn from our mistakes (hopefully)

When one thing doesn't work we then try When one thing doesn't work we then try something else (mostly)

20

Life and processes

Its not about the process,

otherwise wed all be millionaires!

21

Where did Agile come from?

Originally developed as a software engineering methodology

Agile methods were originally called lightweight methodslightweight methods

Adapted from to project management

Evolved in the mid 1990s as a reaction against heavyweight methods, ie: heavily regulated, regimented, micro-managed use of waterfall project processes

22

Agile: a reaction against Waterfall

Idea that we have to complete it end-to-end

Know everything up front in order to cost and

understand the what the solution will look like

23

The Waterfall Process

Sequential

One iteration

Linear process

little flexibility

limited ability to cope limited ability to cope

with change

Long timeframes

Doesnt cater well for

changing business

environment

24

Must know all requirements and risks before proceeding

Can we really know all the

requirements up front?

Hmmm

thats not

what I want

I definitely

know what I

want!

25

The usual reaction

Its too

expensive to go

back now

Maybe we'll try and

train people how to

use 'it' this way

26

The result

More expen$e:

Training still costs time and money

More change management required:

Broken expectations about solution/delivery Broken expectations about solution/delivery

Contingencies have to suddenly be developed

Only partial delivery of the solution well do it in phase 2!

Strained business relationships

No one wants to be involved with a failed project

27

Waterfall the reality

You could be

trying to

understand your

requirements

for months or Youre only going

Thats 40-50%

wasted analysis

time!

28

for months or

yearsYou typically only

implement

50-60% of all

requirements

Youre only going

to find out if your

solution works

at the end

Waterfall its expen$ive to change

Its too expensive

to incorporate

Maybe we should

be looking at

adapting and

change here?

29

changes toward

the end of the

projectCost of change

Trying a different approach:

early Agile adoptionCase 0:

Daimler Chrysler

Comprehensive

Compensation System

(C3) payroll project

30

History of Agile

Today

2001: Agile

Software

Development with

SCRUM published

2002: A Practical

Guide to Feature-

Driven Development

published

2002: Agile

Manifesto

released

2003: McBreen

publishes

Questioning

Extreme

31

1995:

DaimlerChrysler

uses Agile

1999: Extreme

Programming

Explained

published

Extreme

Programming

2006: Waterfall in

use only 55%

projects *

2008: Waterfall

drops to 28%

Agile used in 60%

of projects *

Lessons

learned

Business drivers for change

toward Agile

A need to maximise:

Business value Lean processes

Reduce:

Waste/cost Waste/cost

Improved:

Responsiveness to business

Service levels to business

Quality

Minimise risk profile

32

Less risk

Easier to apply what you learn as you go

Encouraged to take things one step at a time

Build a skinny solution to work out the basics of what you needbasics of what you need

Base decisions on core requirements the projects DNA

Easier to change direction of scope as required when uncovering new issues

33

Less waste

Encourages re-use

90-95% of requirements built rather than 50-60%*

Focus on documentation only when required

Means you could

save up to 50% of

project costs on

things you don't need,

don't want, or don't

work properly!

Focus on documentation only when required

Less costly as a result

34

Promotes learning & innovation

Not locked into one way of doing things

Take learnings from previous iterations and previous projects and apply directly, instantly,

rather than having to wait until the next rather than having to wait until the next

project

Cross-functional teams different perspectives an opportunity for learning

35

Disadvantages of Agile

It's relatively new (people aren't as familiar with Agile as they are with Waterfall)

People are afraid of what they don't know

People tend to want to know what they're getting up front before they commit budgetup front before they commit budget

Tends toward fragmentation of solution

Without a baseline, different incompatible solutions may arise out of each iteration

Without communication, different people may produce divergent solutions

36

Issues with Agile?

Misconception that agile = no documentation and no rigour or discipline

37

Storyboards with process maps, use-cases and

requirements

storyboards

user experience

use case reference

Agile documentation

user experience

requirements lists

user-profiles

(actors)

business process

system objects

Formal Agile processes: Scrum, FDD, XP

Agile

Project ManagementProject Management EngineeringEngineering

FDDFDD

XPScrum

39

Extreme Programming (XP)

Pitched as: Addressing the specific needs of

software development conducted by small teams

in the face of vague or changing requirements

Invented by: Kent Beck who preferred being a

Technical Lead to being a Project Manager.

Year first used: 1995

First used on: C3 project Chrysler

XP is a set of best practices of which some are

taken to an "extreme" level

In the selection of its practices XP leans towards

the daily software engineering activities of

developers

40

Kent Beck

Requirements in XP

As with other agile processes, XP regards

ongoing changes to requirements as a natural

and desirable aspect of software development.

XP view of requirements: XP view of requirements:

Onsite customer (implied singular customer)

Recognition that customer could be a team of

people

Recognition of the role of a customer

representative

41

XP Lifecycle

42

Scrum Management and control process that cuts through

complexity"

Invented by: Jeff Sutherland, Ken Schwaber, Mike Beedle. Senior

managers wanting to get product out faster.


First used on: Advanced Development Methods - process

automation software

Scrum is a skeleton that includes a small set of practices and

predefined roles

De facto standard for managing agile software development

projects

Consists of a few common sense practices that can be applied in

many situations

Scrum by itself is never enough, and that development teams

have to shop in other methods (usually XP) for additional

practices

43

Jeff Sutherland

Scrum: Roles Alternative Name: User, Customer

Role Definition: The Product Owner represents the customer/user/sponsor of the project, and is part

of the team which will deliver the product.

Main Activities: Define the vision for the product, manage the Return On Investment (ROI), present

the needed requirements to the team for the product delivery, prioritize requirements, manage

addition/changes to requirements, plan releases, assure the Domain Experts are available to the

team.

Alternative Names: Project Manager/Leader, Coach

Role Definition: The role of Scrum Master, unlike a Project Manager in many practices and

methodologies, differ from the traditional command and control. In Scrum, the Scrum Master works

Product Owner

methodologies, differ from the traditional command and control. In Scrum, the Scrum Master works

with and, more important, for the team.

Main Activities: Allow the team to be self-managed, guide and help the team to correctly follow

Scrum practices, remove any impediment found by the team, protect the team from external

interference, facilitate the daily meetings.

Alternative Names: Developers, Technicians, Testers

Role Definition: A team member is someone committed to do the necessary work to achieve the

Sprint goal.

Main Activities: Define the Sprint goal, be committed to the work and to the high quality, work

towards the product vision and the Sprint goal, estimate items on the Product Backlog, attend the

daily meetings.

Scrum Master

Team members

Scrum: Lifecycle

6. Day

5. Sprint

(2-4 weeks)4. Tasks

7. Daily Standup

Meeting

Communicate

lessons

learned

8. Product Increment(potentially shippable)

(2-4 weeks)4. Tasks

detailed

by the team

1. Vision

(ROI, milestones,

releases)

2. Product Backlog, with features

prioritized by the Product Owner

3. Sprint Backlog

9. Inspect and Adapt

Feature Driven Development (FDD)

A framework of controls and best practice to enable and enforce the repeatable delivery of working software in a timely manner with highly accurate and meaningful information to all key roles inside and outside a project

Invented by: Peter Coad, Jeff De Luca, Steven Palmer


First used on: Hong Kong Banking Corp on a large 200 person Java First used on: Hong Kong Banking Corp on a large 200 person Java project

Blends a number of industry-recognized best practices into a cohesive whole

Practices are all driven from a client-valued functionality (feature) perspective

Main purpose to deliver tangible, working software repeatedly in a timely manner.

46

and there are others . . .

Crystal Methods

Dynamic Systems Development Method (DSDM)

Lean Development (LD) Lean Development (LD)

Adaptive Software Development (ASD)

... etc ...

47

SCRUM, XP, FDD: Commonalities

Equally applicable principles across any project, regardless of

technology component

Iterative

Evolutionary, not revolutionary (big bang)

Continuous learning Continuous learning

Focus on:

User-focus - what will add value to the 'end-user?

Adding value, not 'deliverables' or 'products

Effective communication

Multi-disciplinary teams

Re-use

48

But XP, SCRUM, etc are still just processes

These won't teach us:

How to be Agile

They'll only teach us:They'll only teach us:

Yet more processes

49

Solution: apply Agile as a philosophy

not a process

A set of values & practices

Identifies need and develops

features/solutions to match

Documentation is a placeholder

50

Documentation is a placeholder

for a conversation

Multidisciplinary approach

Chooses the best people and the

best approach for the right job Ivar JacobsonAgile Evangelist

Fin

Questions?

51

Agile Project Management

Matthew HodgsonRegional-lead for Web and

Information Management

Maria Horrigan MurphyRegional-lead for Business Analysis

52

Information Management

Blog: magia3e.wordpress.com

Twitter: magia3e

Slideshare: www.slideshare.net/magia3e

Email: [email protected]

Mobile: 0404 006695

Blog: www.barocks.com

Twitter: miamurphs

Slideshare: www.slideshare.net/murph

Email: [email protected]

Mobile: 0412 821852