Transcript Slide 1

Lord of the Flies
A Suggestion of the Rewards
and Risks Inherent in Agile
Project Management
Presented by Jeff Nuding, PMP
For PMI-UNY Chapter Meeting
April 15, 2009
Lord of the Flies
•
•
•
•
•
•
•
Novel by William Golding
English Schoolboys, marooned
Life in the Absence of Authority
Less Nobility, More Savage
“Piggy” and Dematuration
Parable on Modern Society
Socialize, or Die!
Agenda
•
•
•
•
•
•
Background and Introduction
Agile Project Management
Agile Versus PMBOK
Some Agile Proponents Say…
What They Don’t Say
Evolution or Devolution?
A Little Background
• CASE, Methodology/SDLC Analysis,
Development, Implementation, Training
• 10 Years Teaching Classic PM
• PMP Certified Since 2001
• Projects: Infrastructure, Business
Transformation, Systems Integration,
Application Development, Network, Y2K
• No hands on experience with Agile
• Curious, but concerned
Tonight’s Objective
• Good Natured Rebuttal to Davidson
Frame, PMI UNY Presentation 1/16/08
• Cursory review of Agile and literature
• Address contention that Agile PM
makes PMBOK, CMM, other structured
process PM approaches obsolete
• Address Other Myths and Prejudices
• Agile Opportunities and Limitations
Agile in Nutshell
• Agile describes some very well
established iterative software
development practices within distinctly
IT related industries, and more narrowly,
Commercial Software companies.
• Earlier precursors Spiral, RAD, Time
Box, etc.).
Agile Manifesto
• We are uncovering better ways of developing
software by doing it and helping others to do it.
• 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 to the
right, we value the items on the left more.
© ASK Process Inc., as delivered by Alan Koch, Pittsburgh PMI, Jan. 8, 2004
Agile Proposition: PM Evolution
• 1900-1950 The Transformation View
• Taylor “time-in-motion,” simple I/O transformations
• 1950-1980 The Value View
• Drucker “customer value,” Porter “value chains”
• 1980-2004 The Constraints/Lean View
• Manage to improve productivity, overcome obstacles
• Present: Production Science Analysis
• “All of these ideas (Transformation, Value Chain and the
Theory of Constraints) are in play and each approach can
bring better insights into understanding the production process
and the best places to invest effort to improve performance.”
• “Agile methods are examples of more modern
management science”
© Mike Griffiths, 2004 PMI Global Congress Proceedings
Agile: Software Development Evolution
• Adaptive Software Development (ASD)
• Dynamic System Development Method
(DSDM)
• Extreme Programming (XP)
• Feature-Driven Development (FDD)
• Lean Software Development (LD)
• SCRUM
© ASK Process Inc., as delivered by Alan Koch, Pittsburgh PMI, Jan. 8, 2004
Agile: PMBOK Versus Agile
• Agile methods should be used along side the
appropriate traditional project management
techniques (Griffiths):
• Initiating: Use PMBOK
• Planning: Combine PMBOK with Agile
•
•
•
•
•
Iterative, guided by feedback on project performance
Progressive elaboration & rolling wave planning
Rigorous refactoring to keep pace with true project work
Feature-based plans versus developer task-based
Affords better visibility into value of delivered functionality
• Executing: Use Agile
• Develop iteratively and incrementally
• Use meaningful metrics, simple and relevant
• Empower the team, don’t micromanage
Agile: PMBOK Versus Agile
• Agile with traditional project management
(Griffiths):
• Controlling: Use Agile
• Scientific experimentation and root cause analysis vs.
“thermostat” (variance from plan) model of control
• Review of progress, requirements, risks and process
effectiveness at end of each iteration
• Prioritize change requests, defects and risk mitigation in
terms of net value of benefit or cost of risk avoidance
• Control flow, identify and eliminate obstacles
• Closing: Use PMBOK
Agile: PMBOK Versus Agile
• Agile methodologies, if followed with
discipline and rigor, are compliant with CMMI
& PMBOK best practices (Sliger)
• Highsmith relabeled Phases:
•
•
•
•
Initiating -> Envisioning
Planning -> Speculating
Executing -> Exploring
Controlling -> Adapting
• Integration Management:
• Continuous iterative planning vs. up-front planning
• Release plans with date and features to be deployed
• Product change managed by ranked backlog of features
Agile: PMBOK Versus Agile
• Agile compliant with CMMI & PMBOK (Sliger)
• Scope Management:
• Fix cost and schedule, then deliver highest value features
• Eliminate impediments, rather than focus on critical path
• Work of highest priority features to produce potentially
shippable software at end of each iteration
• Agile and PMBOK both recognize the triple
constraint: cost, schedule, scope
Agile: PMBOK Versus Agile
• Nothing in the Agile methods is incompatible
with PMBOK (Koch):
• Augmenting Agile methods with some PMBOK
processes may be advisable
• Initiating: Agile may overlook important steps
• Planning: Use PMBOK to augment for detailed
activity planning, budgeting, risk planning,
procurement, and documentation
• Executing: Agile all the way
• Controlling: Welcome change when appropriate,
control change when needed
• Closing: Use PMBOK for archiving administrative
and technical data
Neutral: PMBOK Versus Agile
• Agile as a set of lightweight activities vs.
“high ceremony” methods (Alleman)
• The introduction of Agile process should
only be undertaken by organizations that
are risk aware if not risk adverse.
• Organizations who need answers and
concepts that are fully developed that
result in a solution that can be
implemented with little risk should stay
clear of Agile processes.”
Neutral: PMBOK Versus Agile
• Agile vs. “high ceremony” (Alleman)
• Q: If a project management method were properly
applied, in the proper domain, to the proper set of
problems, with properly training participants,
would it be considered overweight and produce
undesirable consequences?
• A: No, of course not.
• “Making a process lightweight by removing
activities or artifacts is most likely inappropriate
and a possible source for project failure without
careful consideration of the consequences.”
Neutral: PMBOK Versus Agile
• Agile vs. “high ceremony” (Alleman)
• Assume simplicity
• Embrace change
• Enabling the next
effort is also a goal
• Incremental change
• Maximize
shareholder value
• Manage with a
purpose
• Multiple project views
• Rapid feedback
• Working software is
the primary goal
• Travel light
PMI Attention to Agile
• Highlighted at PMI Congress (2008)
•
•
•
•
Scrum/PMI Networking Reception
TRN12 Agile Project Management
TRN21 Agile Project Management
IND05 How One Agile Software Team Uses
PMBOK® Guide
• TRN14 Hybrid Agile Project Management
• PMI Agile Networking Reception
PMI: Agile Versus PMBOK
• PMBOK supports a wide variety of industries
• PMBOK does not prescribe Waterfall
• Agile and software "factory" approaches do
not address project management intensive
processes at either end of the life cycle:
• Procurement (especially buy/build)
• Platform and environment builds
• Application and Component Deployments
• Government and Regulatory difficulties
PMBOK Version 4 on Agile
• Slim Pickings…
• Description of an iterative relationship (of project
phases), page 22
• Progressive Elaboration, pp. 7, 109, 351
• Rolling Wave Planning, pp. 46, 120, 135
• Prototypes supporting progressive elaboration, p. 109
• Decomposition not always possible for future work,
necessitating rolling wave planning, p. 120
• Rolling Wave Planning mentioned as a form of
Progressive Elaboration, in the context of Project
Time Management, p. 135
Experience with Agile Hybrids
• NYPD’s Hybrid Agile Project (TRN14)
• Created SCRUMs for each new release
• Used Microsoft Solution Framework (MSF) v. 4
• Quick-hit, stand-alone application for special unit
• NYS DCJS web application development
• Rational Unified Process (RUP), related SDLC
and software development tools
• Multiple iteration-phased web development
projects
NYPD Hybrid Agile Project
• Procurement, deployment, infrastructure not
accounted for in Agile methods.
• Application deployed without integration with
any existing platforms or systems
• Project Sponsor deferred or avoided
decisions on requirements, iteration planning,
or product acceptance
• Team more self-contained and self-approving
of resulting products, “free and unfettered”
NYPD Lessons Learned (TRN14)
• Customer awareness and buy-in critical
• Could avoid start-up issues by better setting
customer expectations and enhanced training
• Better Project team preparation:
• leading and coaching vs. managing
• Concept of team assigning work to itself
• Flexibility in anticipating frequent role shifts
• Need access to key decision-makers
• Customer end users needed more time to
assimilate new functionality with each release
DCJS Experiences with RUP
PRO
• More methods standardization
• Increased computer-aided
software engineering
• Iteration-phased projects
generate code quicker
• Segmentation makes for
easier PM and status
reporting
• More division of effort,
resource portability, and
compartmentalization
• More business and user
involvement throughout
project life cycle
• Plenty of Buzz
CON
• Problems with version control of
shared elements
• Less control over which and
how requirements get
implemented
• Unarticulated implied or
unexplored requirements can
become essential
• Biased towards existing
infrastructure, not well suited to
develop infrastructure
• Minimizes importance of
procurement & deployment
• Resources separated from
project, harder to track burn rate
Some Agile Proponents Say…
• “Organizations need regular dematuration.”
• “Do we really want repeatable processes?”
• “Iterative and agile approaches to PM reflect
a step towards dematuration.”
• “Standards generally reflect current practice.
In a sense, by doing so, they look backward.
As practices evolve, standards need to adjust
to the changes – otherwise, they become a
barrier to progress.”
What They Don’t Say
• Commercial software development bias
• Stand-alone vs. existing infrastructure
• “Backlog” vs. Requirements Definition
• Ex., evolution of Microsoft products
• “Let us tell you what you want.”
• Some things – and some systems – don’t
benefit from iterative development
• Space Shuttle and other “life or death”
• Major infrastructure projects (even IT)
• Do users know what they don’t know?
National Software Quality Experiment
(As found in Alleman’s “Agile Project Management Methods for IT Projects”)
Common Problem
Consequences
Software product source code
components are not traced to
requirements
Software product is not under the control
and the verification procedures are
imprecise. Changes cannot be managed in
a controlled manner.
Software engineering practices are Defect rates are unacceptable.
not applied in a systematic manner
Product designs and source are
managed in an ad hoc manner
The understandability, maintainability, and
adaptability of the product is negatively
impacted.
The construction processes for the Common patterns of the processes are not
product are not clearly defined
exploited
Rapidly changing code base has
become the norm
The code base services only the short term
benefits and mortgages the future where
traceable baseline requirements,
specifications, and design artifacts are the
foundation of success.
Software Systems Taxonomy
(As found in Alleman’s “Agile Project Management Methods for IT Projects”)
Software Type
Attributes
Management
Information Systems
Software that an enterprise uses to support business
and administrative operations.
Outsourced Systems
Software projects built for client organizations.
Systems Software
Software that controls a physical device such as a
computer or a telephone switch.
Commercial Software
Software applications that are marketed to hundreds or
even millions of clients.
Military Software
Software produced for the uniformed services.
End User Software
Small applications written for personal use.
Web Application and
e- Projects
Small, medium, and large scale projects with legacy
system integration, transaction processing, multimedia
delivery, and web browser based user interfaces.
Evolution or Devolution?
• Agile not comprehensively applicable across software
development life cycle.
• Agile approach offers many advantages over a
"traditional waterfall" development approach,
especially for commercial software development
• Agile poses problems for Government IT shops, for
which Procurement, Project and Requirements
Definition necessarily take on greater formality.
• Disconnect between application developers and
infrastructure staff who build the actual physical
platforms upon which the applications will run.
Agile Literature and Resources
•
•
•
•
•
•
•
Jim Highsmith, Agile Project Management. Boston: Pearson Education, 2004.
Michele Sliger, PMP, Agile Coach for Rally Software Development
Corporation, Column at www.stickyminds.com
www.agilemanifesto.org
www.agilealliance.com
Robert Greenleaf, The Power of Servant Leadership. San Francisco: BerrettKoehler Publishers, 1998.
Ken Schwaber, Agile Project Management with Scrum. Redmond, WA:
Microsoft Press, 2004.
Alan Koch
•
•
•
•
Evaluating Agile Methods for Your Organization, Artech House Books, 2004.
President, ASK Process Inc.
Glen Alleman, “Agile Project Management Methods for IT Projects,” in The
Story of Managing Projects, edited by Dr. E. G. Carayannis and Dr. Y.H.
Kwak. Greenwood Press, 2002
Nikravan, Bijan, PhD., PMP and Melanson, Douglas, MS, PMP, “Application
of Hybrid Agile Project Management Methods to a Mission-Critical Law
Enforcement Agency Program,” PMI Congress North America Proceedings,
2008.
Questions?
Contact Information
• Jeff Nuding, PMP, Keane
• (518) 432-3209, 0 for Assistance
• [email protected]