1 / 32

Lord of the Flies

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

jacqui
Download Presentation

Lord of the Flies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

  2. 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!

  3. Agenda • Background and Introduction • Agile Project Management • Agile Versus PMBOK • Some Agile Proponents Say… • What They Don’t Say • Evolution or Devolution?

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

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

  6. 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.).

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

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

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

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

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

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

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

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

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

  16. 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.”

  17. 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 Neutral: PMBOK Versus Agile • Agile vs. “high ceremony” (Alleman)

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

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

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

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

  22. 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”

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

  24. 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 DCJS Experiences with RUP

  25. 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.”

  26. 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?

  27. National Software Quality Experiment (As found in Alleman’s “Agile Project Management Methods for IT Projects”)

  28. Software Systems Taxonomy Software Systems Taxonomy (As found in Alleman’s “Agile Project Management Methods for IT Projects”)

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

  30. 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: Berrett-Koehler 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.

  31. Questions?

  32. Contact Information • Jeff Nuding, PMP, Keane • (518) 432-3209, 0 for Assistance • Jeffrey_c_nuding@keane.com

More Related