Agile Project Management Part 1 Final
-
date post
14-Sep-2014 -
Category
Business
-
view
3.663 -
download
1
description
Transcript of 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%
-
When people talk about Agile
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
-
When people talk about Agile
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.
Year first used: 1994
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
Year first used: 1997
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