You don’t need agile to avoid the seven deadly sins of pm

 Mike Cohn’s presentation at: http://www.mountaingoatsoftware.com/system/presen tation/file/123/Cohn-Agile-and-Deadly-Sins-of-Project- Management.pdf Mike raises some interesting questions about applying “agile” to development projects. His approach, however of replacing bad project management with agile is not new, but it’s also not correct. Fix the broken process, before replacing it with another. 2/27

 Agile has very useful software development practices.  But the notion that Agile is the answer to bad project management is a common starting point for some agilest.  The problems (the sins) mentioned in Mike’s presentation are just “bad” project management.Don’t Do Stupid Things on Purpose 4/27

 “Good” project management is always the first (and many times best) antidote to “Bad” project management.  Failure to apply “Good” project management usually leads to “Bad” projects.  This choice is sometimes made intentionally followed by complaints that the PM method didn’t work.Don’t Do Stupid Things on Purpose 5/27

No matter what project, what project method, what business domain, or whatcontext inside that business domain – there are 5 Immutable Principles of PM 6/27

 As Project Managers and Developers, Do we …  Know Where Are We Going?  How Are We Going To Get There?  Have Enough Time, Resources, And Money To Get There?  Know What Impediments Will We Encounter Along The Way?  Know If We Are Making Progress? If not, we’re doing “bad” Project Management. 7/27

1. Where Are We Going? Eliciting Requirements Is Domain DependentImplement the 8 stories for our new “Design and integrate 18 major weapon systems and platformswarehouse inventory package tracking simultaneously within strict size and weight limitations, whilesystem using the existing web site synchronizing the development, demonstration, and production of asplatform as a starting point. many as 157 complementary systems with the Future Combat System content and schedule.” (This is an actual requirement) 8/27

2. How Do We Get There?Some problems respondto lightweight This approach worksapproaches, like well when we don’tScrum, DSDM, Crystal, know what “done” looksand XP as product like with enough claritydevelopment methods.Others require morecomplex approaches, likea System of Systems(SoS) spiral developmentprocesses. SoIn all cases a disciplined Doesapproach increases the This!probability of success – nomatter the complexity ofthe problem or thesolution. 9/27

3. Do We Have Enough Time, Money, And Resources To Get To DONE? A Common Problem A Simple Solution  Using the Integrated Master Plan and Integrated master Schedule, construct a network of Work We have undue optimism of our Packages describing the flow of work. capacity for work  Use documented procedures – no matter the method – for estimating and planning using historical data.  Understand and prioritize risks for each critical We attempt to avoid risk and component empowers management and staff. uncertainty  Use this knowledge to control your optimism.  Simple statistical models are more often correct We rely too much on intuitive than the human judgment. judgment  Have this number to back up your intuition.The Rational Planning of (Software) Projects, Mark C. Paulk, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213–3890 10/27

4. What Impediments Will We Encounter Along The Way To DONE? Risk Management Is How Adults Manage Projects ‒ Tim Lister 11/27

5. How Do We Know If We Are Making Progress As Planned? The only measure of progress is the Physical PercentA Complete for the planned deliverables. Physical Percent Complete means tangible evidence of theB outcomes that were planned – measured at the time they were planned to be delivered. This is the basis for full Earned Value Management with physical percent complete.C This is also a natural a fit with the agile approaches to software development. All successful methods measure the evidentiary outcomes inD units meaningful to the stakeholders. These units are usually “money” and “time.” 12/27

Sins Virtue Lust ChastityGluttony Temperance Greed Charity Sloth Diligence Anger Patience Envy Kindness Pride Humility 13/27

Sins Virtue Gluttony Temperance Lust Chastity Sloth DiligenceOpaqueness Visibility Pride FeedbackWastefulness Conservation Myopia Foresight 14/27

Mike’s Agile Counter Example Virtue of Deliverables Based Planning®Fixing all dimensions – scope,  Measures of Effectiveness (MoE) and Measures ofschedule, and quality. Performance (MoP) defined the parameters of Technical Performance Measures (TPM).Impossible schedules.  Probabilistic cost and schedule margins (DID 81650 in the defense business).Death marches.  Pace the work into Work Package and Planning Packages within “rolling waves.”  Always have a defined outcome within the period of performance that has a “sensible” horizon.Trying to do too much for the  Resource management plans tied to measures ofresources available. Physical Percent CompleteCutting quality to meet other  Quality is a Technical Performance Measure.goals.  Make compliance with TPM’s visible to senior management 15/27

Mike’s Agile Counter Example Virtue of Deliverables Based Planning®  Defined capabilities, traceable to requirements, traceable to deliverables produced by WorkIntense or unrestrained craving Packages in the Integrated Master Schedule.for features.  Trace requirements to needed capabilities.  Answer every request with a mandatory trade- space assessment. Why do we need this?Trying to put too many features  Monetizing each deliverable against the Budgetedinto a product during the time Cost for Work Scheduled (BCWS)allowed.  Paired Comparison or Borda Ranking of features.Treating all features as  Analysis of Alternative (AoA).“critical.”  “Trade Space” analysis of each feature.  Understanding the “capacity for work.”Overtime, reduced quality,  Managed resource plans based on this capacitysurprises. and the feedback from measurable performance 16/27

Mike’s Agile Counter Example Virtue of Deliverables Based Planning®  Measures of Effectiveness and PerformanceFailing to do high quality work connected to Technical Performance Measuresat all times. defined as part of the “narrative” of the work.  Technical Performance Measures for each major deliverable.  Measure compliance with these.Testing quality at the end.  Adjust forecast of future performance based on past performance.  Use only tangible evidentiary materials to measure performance.  Use what ever method you need to confirmInstability during working product on a daily, weekly, or no more thatdevelopment. every other week basis.Big delays.  Provide cost, schedule, and technical margins.Unpredictable schedules.  Execute according to plan. 17/27

Mike’s Agile Counter Example Virtue of Deliverables Based Planning®  Measures of physical percent complete based on planned physical percent complete establish theObscuring progress, quality, or “credibility” of progress.other attributes of a project.  Measuring actuals against plan on fine grained boundaries keeps every one honest  The true state of the project is comparison of actuals with the plan for cost, schedule, andNot knowing the true state of technical performancethe project.  Cost, Schedule, and Technical performance measures on fine grained boundaries.  Ask “How Long Are You Willing To Wait BeforeYouSurprises Find Out You’re Late?  Measure at least at ½ that duration.  Start making decisions on actionable informationPoor decisions from the performance measures. 18/27

Mike’s Agile Counter Example Virtue of Deliverables Based Planning®  No one knows everything - period. Stop trying.Believing that we know  This is why there are rolling waves, spirals, drops ineverything to build the large complex programs.product.  Realistic development is part of all “good” project management.  This is a “business management” issue.A lack of stakeholder and user  Why would you spend someone elses money andinvolvement. not have them involved in that process?  Feedback comes at least monthly on large government programs.  Feedback is always measured in units meaningfulFailure to solicit feedback. to the participants.  To do otherwise is not allowed in DoD, DOE, NHS – why do IT projects continue to put up with this?  Learned orgs survive, others don’t – find betterFailure to learn. projects to work on. 19/27

Mike’s Agile Counter Example Virtue of Deliverables Based Planning®  Failure to manage resources violates at least 4 Chapters and dozens of sections of PMBOK.Misuse of critical resources  Why is this allowed – it’s “bad” project management.  Management is a verb.Losses of creativity, motivation,  Do good management.and time  Stop doing stupid things on purpose.  The role of management is to lead.Project malaise  Start leading.  The Marines can figure this out, why can’t you?  Plan the work – work the plan.Delays  Late starts = Late Finishes.  Be a manager, stop being stupid.Doing it the same way (again)  Come on folks “nut up or shut up”. 20/27

Mike’s Agile Counter Example Virtue of Deliverables Based Planning®Not seeing beyond your own  Integrated Master PlanworkTeams who don’t see the big  Integrated Master Schedulepicture  Integrated Master Schedule, with “giver/receiver”Individuals who work only links, traceable vertical and horizontal paths to thewithin their roles. deliverables  Design to, Build to, Test to specification.  Use “Test as you Fly” paradigm. This means fullUnsuccessful products. fidelity test environment.  100% evaluation of all deliverables.  There is a fundamental law of physics for projects –Delays. Late Starts = Late Finishes. 21/27

Developing software based products is not the same as managing the development ofsoftware based products.A good example of why is found in the CMMI DEV 1.2 table. 25/27

Why is Software Development not the Same as Project Management? Process Management Acronym Level 2 Level 3 Level 4 Level 5 Organization Process Focus OPF  CMMI-DEV 1.2 Organization Process Definition OPD  Organization Training OT  Separates Organization Process Performance OPPOrganizational Innovation and Deployment OID   “Engineering” Project Management Level 2 Level 3 Level 4 Level 5 from the Project Planning PP  Project Monitoring and Control PMC  management Supplier Agreement Management SAM  Integrated Project Management IPM  of Engineering Risk Management RSKM  Quantitative Project Management QPM  for a simple Engineering Level 2 Level 3 Level 4 Level 5 reason … Requirements Management RM  Requirements Development RD  Technical Solution TS  Product Integration PI  “Doing, is not Verification VER  Validation VAL  the same as Support Configuration Management CM Level 2  Level 3 Level 4 Level 5 management Process and Product Quality Assurance PPQA  of the Doing” Measurement and Analysis MA  Decision Analysis and Resolution DAR  Causal Analysis and Resolution CAR  26/27

Process Management Acronym Level 2 Level 3 Level 4 Level 5 Organization Process Focus OPF   Agile methods Organization Process Definition OPD  Organization Training OT  include a few Organization Process Performance OPP  process areasOrganizational Innovation and Deployment OID  Project Management Level 2 Level 3 Level 4 Level 5 outside Project Planning PP  “Engineering.” Project Monitoring and Control PMC  Supplier Agreement Management SAM   But there remains Integrated Project Management IPM  many other PA’s Risk Management RSKM  Quantitative Project Management QPM  not included in Engineering Level 2 Level 3 Level 4 Level 5 Agile, that are Requirements Management RM  Requirements Development RD  part of developing Technical Solution TS  software based Product Integration PI  Verification VER  products. Validation VAL  Support Level 2 Level 3 Level 4 Level 5 Configuration Management CM  Process and Product Quality Assurance PPQA  Measurement and Analysis MA  Decision Analysis and Resolution DAR  Causal Analysis and Resolution CAR  27/27

http://herdingcats.typepad.com	468
http://thinkery.me	20
http://translate.googleusercontent.com	2
http://www.typepad.com	2
http://www.zimbio.com	2
http://feeds.feedburner.com	1
https://teampage.tractionsoftware.com	1
http://dashboard.bloglines.com	1
http://static.slidesharecdn.com	1
http://www.google.com	1

You don’t need agile to avoid the seven deadly sins of pm

by Glen Alleman on Dec 10, 2010

Accessibility

Upload Details

Usage Rights

10 Embeds 499

Statistics

You don’t need agile to avoid the seven deadly sins of pm — Presentation Transcript