Transitioning to Agile Project Management

Transcription

1 Transitioning to Agile Project Management The Waterfall Trap Web Seminar hosted by ASPE Richard J Perrin PMP CSM SSBB QFDGB Principal, Evolutionten corp. rperrin@evolutionten.com 2009 Richard J Perrin All rights reserved

2 Your Presenter Richard Perrin - PMP SSBB QFDGB CSM Over 20 years in technology as a systems architect, Project Manager, Sr. Project Manager, Sr. Program Manager, Director of Development, Director of Quality Focus on delivering solutions in cross-disciplinary environments integrating corporate strategy, sales operations and technology to produce effective solutions. Project experience in aerospace, telecommunications, finance, healthcare, publishing, energy and retail. Author of Real World Project Management Beyond Conventional Wisdom, Best Practices and Methodologies released on January 18, 2008 by John Wiley & Sons, Inc., now available on Amazon.com Principal in Evolutionten and richard j perrin project engineering, inc

3 The Case Against Waterfall in Software Development Planning, budget, scope and timeline all frontloaded Requirements disconnect Change Averse Scope Creep is rampant and requires expensive overhead processes Quality inspected in Command and Control approach One shot, big bang approach: one chance to get it right

4 Planning: Waterfall to WaterFlawed Winston Royce described the model to the right in a 1970 presentation to the IEEE. He thought the process would work only if iterative feedback loops were built into the process** ** I believe in this concept, but the implementation described above is risky and invites failure. The problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable.* * Proceedings, IEEE WESCON, August 1970, pages 1-9.Copyright 1970 Institute of Electrical and Electronics Engineers

5 Management s Planning Disconnect PMI was founded based on the construction industry model: Linear in nature Activities are a series of Finish-to-Start relationships Software engineering is not linear Managers that come from manufacturing apply construction industry concepts to software engineering with limited result Standish Group stats on Fortune 1000 project success rates: Success 34% 35% Failure 15% 19% Challenged 51% 46%

6 Planning: Progressive Elaboration PMI states: Progressive elaboration means developing in steps, and continuing by increments. For example, the project scope will be broadly described early in the project and made more explicit and detailed as the project team develops a better and more complete understanding of the objectives and deliverables. Progressive elaboration should not be confused with scope creep. * * A Guide to the Project Management Body of Knowledge (PMBOK Guide) Third Edition, 2004 Project Management Institute 6

7 Requirements: Incomplete and Otherwise According to the Standish Group, the #1 reason for project failure What makes it so difficult for the customer/end users to generate effective and complete business requirements up front in the process?

8 The Requirements Disconnect Waterfall planning assumes: The customer can describe exactly what they want The customer knows exactly what they want The customer can give you a complete list of every feature needed for the project The customer can provide this level of detail without ever having seen the end product

9 The Requirements Reality Every requirement is a #1 priority (How is this possible? ) Users have difficulty describing what they need the usual response is IKIWISI >> ( I ll know it when I see it ) JAD sessions only describe 40-50% of the business needs how do you know how the customer actually uses the product? Quality as defined by ISO 8402: the totality of characteristics of an entity that bear on its ability to satisfy stated and implied needs Stated needs: what the customer tells you Implied needs? >> Go to GEMBA

10 Quality Defined Quality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing to pay for Customers pay only for what is of use to them and gives them value. Nothing else constitutes quality. * Who defines Quality? >>> The Customer Our job is to capture the Voice of the Customer (VOC) * Innovation and Entrepreneurship, Peter Drucker, 1985

11 Waterfall Requirements: Institutionalized Scope Creep The Standish Group determined that 45% of all user requirements are never used by the customer in the delivered product** (Why are you building it?) Actual Use of Software Features 7% Always 13% Often 45% Sometimes 16% Rarely Never 19% The result to the left describes typical waterfall implementations How can we make scope changes lean? ** J. Johnson, Keynote Speech, XP 2002

12 Change and Scope Creep Defining a legitimate Change Request(CR) What is the definition of Scope Creep? Massive Change Management Systems are created to control and eliminate Scope Creep A typical CR/CM process: Determine actual need for change (murder board) Perform impact assessment (dollars, resources, time) Submit to customer for approval Submit to CCB (Change Control Board) for final approval Implement and potentially rebaseline the PM plan

13 Change Management Change is always tied to risk Organizations typically do a poor job of risk management on software projects: If risk is managed badly change will be managed badly

14 Command and Control Key elements of the C&C Model Monolithic upfront planning, analysis, requirements and design Upfront plan is assumed correct, complete and is baselined. Signoff on the complete scope by the customer is required before actual work is started (coding) The PM assigns work to the IT team and tracks the schedule by Gantt chart decisions rest with the PM or Sr. Management

15 Command and Control cont d Key elements of the C&C Model Corrective actions are implemented to address variances and are tracked regularly Adherence to a project Methodology that outlines every step in the process: required documentation, roles, signoffs, decision gates, deliverables, milestones Failure, even temporary, is a significant negative

16 Issues with C & C Assumes project execution is linear Mandates that processes must be centrally controlled - permission is only granted via an ordered hierarchy Assumes that order within the system is imposed from outside the system (!) Failures are considered mistakes that must be corrected ( Give me a name )

17 The Hidden Cost of C & C The key C&C issue: the business does not trust the people they hired to function in the best interests of the organization This leads to high turnover at tremendous cost to the business or at worst degenerates into RIP The cost of a bad hire is estimated at between 1-5 times the hire s annual salary* *Right Management, Feb 2008

18 Big-Bang Quality Issue In the waterfall context, when do we find out if all the components, architecture, and network elements really work? Project completion delay potential is highest here if there are integration and rework issues The most expensive Rework occurs here

19 Issues with Big Bang One chance to get it right Two options if the end result is wrong/defective: Scrap - the work investment is lost Rework - the most expensive point to fix problems (unless the defect is missed in final test and gets shipped to the customer. How expensive is this?) Quality is inspected in to the product Highly change averse The customer does not experience the product until UAT

20 Thank You! Q& A Wrap-up