What is agile? Scrum, FDD, XP process

1. Agile Project Management
Part 1
Matthew Hodgson & Maria Horrigan Murphy
Senior Consultants
SMS Management and Technology
1
May 2009

2. An Agile Agenda
1. Managing projects
2. What is Agile? Questions as
3. Why Agile we go
4. Break – 10 minutes
5. Agile as a philosophy
6. Case studies
7. Learnings
8. Conclusions
2

3. Take-aways
• Quick Reference Guide
• Evaluation survey
• Slides available on DNET
3

4. Managing projects
From PM to Agile
4

5. Traditional PM Methodologies
Prince2 VS PMBOK
• Projects IN Controlled • Project Management Body
Environments (PRINCE) of Knowledge
• Tends to prescribe how • Generally describes project
projects should be processes and activities
controlled
5

6. Prince2
Developed by:
• UK’s 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
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 doesn’t develop as
planned
Specifies:
• Process with its key inputs and outputs
• Goals and activities – gives automatic control over scope deviations

7. Prince2 Processes
It’s more about
how to
manage, but
not what
activities to do
Even though Prince2’s popularity makes it a de facto standard for project
management , it is criticized for being too prescriptive, too big and not
easily customisable.
7

8. 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.
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.

9. More project
processes?!
9

10. Process success measures?
Through management of a project:
• On time
• On budget
• Mitigated risks
• Met users’ expectations
• Met business objectives
10

11. 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
specifications?
11

12. What if a project ...
Budget:
• Est $425M
• Actual $2,435M
Almost a
decade late!
Timeframe:
• Est 1965 due date
• Actual 1973 first finished
12

13. Sydney Opera House project successes
Delivered :
• Iconic identity to Sydney
& Australia
• Culture to Sydney
• Computer modelling
engineering firsts
• Revolutionary pre-fabrication methods
- 13

14. 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

15. 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

16. When people talk about ‘Agile’
Iterative – 60%
Test Driven – 20%
No Documentation – 10%
Collaboration & social engineering – 10%
16

17. feature-driven
early stakeholder involvement
fast moving light-weight
adding-value
continued integrations
eliminate waste no documentation
collaboration
nimble
flexible test driven development
When people talk about ‘Agile’
the team sets their own priority communication
small iterations
accepting changes
adapt to change adaptable
the name
coping with change
About people working software
people before process
user-focus rapid iterations
17

18. feature-driven
early stakeholder involvement
fast moving light-weight
adding-value
continued integrations
eliminate waste no documentation
collaboration
nimble
flexible test driven development
When people talk about ‘Agile’
the team sets their own priority communication
small iterations
accepting changes
adapt to change adaptable
the name
coping with change
About people working software
people before process
user-focus rapid iterations
18

19. Agile
IS ISN’T
• About people, teamwork, and • A “Silver Bullet” solution
collaboration
• About delivering real business • Just for IT projects
value and outcomes • An excuse for poor requirement
• Producing light-weight definition
documentation to get the job done • An excuse for poor design
• Managed iterations
• Responding to business changes • An excuse for reducing quality
• Managing change • About failure to control the scope
• Simple, fast and efficient of a project, its about managed
• Based on industry best practice change
• Disciplined and structured • Doing more with fewer people
• Built-in validation of solutions • Doing more with less resources or
• Contingent workforce and budget
activities
• Complex
• Chaotic and unstructured
19

20. 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
something else (mostly)
20

21. Life and processes
It’s not about the process,
otherwise we’d all be millionaires!
21

22. Where did Agile come from?
• Originally developed as a software
engineering methodology
• Agile methods were originally called
“lightweight” 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

23. 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

24. The Waterfall Process
• Sequential
• One iteration
• Linear process
– little flexibility
– limited ability to cope
with change
• Long timeframes
• Doesn’t cater well for
changing business
environment
• Must know all requirements and risks before proceeding
24

25. Can we really know all the
requirements up front?
I definitely Hmmm …
know what I …that’s not
want! what I want
25

26. The usual reaction
It’s too Maybe we'll try and
expensive to go train people how to
back now use 'it' this way
26

27. The result
More expen$e:
• Training still costs time and money
More change management required:
• Broken expectations about solution/delivery
• Contingencies have to suddenly be developed
• Only partial delivery of the solution – “we’ll do it in
phase 2!”
• Strained business relationships
• No one wants to be involved with a ‘failed’ project
27

28. Waterfall – the reality
That’s 40-50%
You could be wasted analysis
trying to time!
understand your
requirements You’re only going
for months or You typically only to find out if your
years implement solution works
50-60% of all at the end
requirements
28

29. Waterfall – it’s expen$ive to change
Maybe we should
be looking at
adapting and
change here? It’s too expensive
to incorporate
changes toward
the end of the
Cost of change project
29

30. Trying a different approach:
early Agile adoption
Case 0:
Daimler Chrysler
Comprehensive
Compensation System
(C3) payroll project
30

31. 2002: Agile
Manifesto
History of Agile
released 2002: A Practical
Guide to Feature-
Driven Development
2001: Agile
published
Software
Development with
2003: McBreen
SCRUM published
publishes Today
Questioning
Extreme
1999: Extreme Programming
Programming
Explained
published
2008: Waterfall
Lessons drops to 28%
1995:
learned Agile used in 60%
DaimlerChrysler 2006: Waterfall in of projects *
uses Agile use only 55%
projects *
31

32. Business drivers for change
toward Agile
A need to maximise:
• Business value – Lean processes
Reduce:
• Waste/cost
Improved:
• Responsiveness to business
• Service levels to business
• Quality
Minimise risk profile
32

33. 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 need
• Base decisions on core requirements – the
project’s DNA
• Easier to change direction of scope as
required when uncovering new issues
33

34. Less waste
Means you could
save up to 50% of
• Encourages re-use project costs on
things you don't need,
• 90-95% of requirements built don't want, or don't
rather than 50-60%* work properly!
• Focus on documentation only when required
• Less costly as a result
34

35. 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
project
• Cross-functional teams – different
perspectives an opportunity for learning
35

36. 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 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

37. Issues with Agile?
• Misconception that agile = no documentation
and no rigour or discipline
37

38. Agile documentation and
Storyboards with process maps, use-cases
requirements
storyboards
use case reference
user experience
business process
user-profiles
(actors)
system objects
requirements lists

39. Formal Agile processes: Scrum, FDD, XP
Agile
Project Management Engineering
FDD
Scrum
XP
39

40. 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
Kent Beck
taken to an "extreme" level
• In the selection of its practices XP leans towards
the daily software engineering activities of
developers
40

41. 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:
– Onsite customer (implied singular customer)
– Recognition that customer could be a team of
people
– Recognition of the role of a customer
representative
41

42. XP Lifecycle
42

43. 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 Jeff Sutherland
• 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

44. 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
Product Owner 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
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 Master 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
Team members daily meetings.

45. Communicate
Scrum: Lifecycle
lessons
learned
6. Day
7. Daily Standup
Meeting
5. Sprint
4. Tasks (2-4 weeks)
detailed 8. Product Increment
3. Sprint Backlog by the team (potentially shippable)
1. Vision 2. Product Backlog, with features
(ROI, milestones,
releases)
prioritized by the Product Owner
9. Inspect and Adapt

46. 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
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

47. and there are others . . .
• Crystal Methods
• Dynamic Systems Development Method
(DSDM)
• Lean Development (LD)
• Adaptive Software Development (ASD)
• ... etc ...
47

48. SCRUM, XP, FDD: Commonalities
• Equally applicable principles across any project, regardless of
technology component
• Iterative
• Evolutionary, not revolutionary (big bang)
• 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

49. But XP, SCRUM, etc are still just processes
These won't teach us:
• How to be Agile
They'll only teach us:
• Yet more processes
49

50. 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
for a conversation
• Multidisciplinary approach
• Chooses the best people and the
best approach for the right job Ivar Jacobson
Agile Evangelist
50

51. Fin
Questions?
51

52. Agile Project Management
Maria Horrigan Murphy Matthew Hodgson
Regional-lead for Business Analysis Regional-lead for Web and
Information Management
Blog: www.barocks.com Blog: magia3e.wordpress.com
Twitter: miamurphs Twitter: magia3e
Slideshare: www.slideshare.net/murph Slideshare: www.slideshare.net/magia3e
Email: maria.murphs@gmail.com Email: mhodgson@smsmt.com
Mobile: 0412 821852 Mobile: 0404 006695
52