CMMI Technology Conference Denver, CO November 19, 2003 Using CMMI to Balance Agile and Plan-driven Methods Richard Turner The George Washington University.

Slides:



Advertisements
Similar presentations
©2004 by Richard D. StutzkeAgile Methods and Process Maturity.ppt 1 Science Applications International Corporation An Employee-Owned Company ® Richard.
Advertisements

Unified process(UP) UP is an OO system development methodology offered by Rational(Rational Rose) s/w, now a part of IBM Developed by Booach,Rambaugh,Jacobson--
AGILE DEVELOPMENT Outlines : Quick Look of agile development Agility
Software Development Life-Cycle Models
Chapter 2 Modeling the Process and Life Cycle Shari L. Pfleeger
CS3773 Software Engineering Lecture 01 Introduction.
Alternate Software Development Methodologies
Agile Process Models. Prescriptive models don’t work It is unrealistic to not have changes. Why? The Agile Manifesto: Individuals and interactions over.
Software Life Cycles ECE 417/617: Elements of Software Engineering
Agile Software Development. Traditional Software Development 1.Initiation (RFP) 2.Feasibility study Technical – can we build it? Economic – should we.
Computer Engineering 203 R Smith Agile Development 1/ Agile Methods What are Agile Methods? – Extreme Programming is the best known example – SCRUM.
CMMI Overview Quality Frameworks.
University of Southern California Center for Software Engineering C S E USC Agile and Plan-Driven Methods Barry Boehm, USC USC-CSE Affiliates’ Workshop.
SERA 2003 Keynote Address Research Review San Francisco, CA June 25, 2003 A forthcoming Addison Wesley Book ©USC-CSE6/25/03 1.
Software Engineering Introduction. Why are you here? …alternatively, why do we think you need to be here? Why a course on software engineering? How is.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Barry Boehm University of Southern California Richard Turner OUSD(AT&L)/DS/SE (George Washington University) Balancing Agility and Discipline: Evaluating.
Chapter : Software Process
Tsvetelina Kovacheva, Quality Manager Musala Soft June 19, 2007 Implementing Models and Standards for Software Development Benefits and Risks.
Software Development Process
CMMI Course Summary CMMI course Module 9..
CPTE 209 Software Engineering Summary and Review.
Chapter 3 – Agile Software Development 1Chapter 3 Agile software development.
Chapter 3 – Agile Software Development Lecture 1 1Chapter 3 Agile software development.
Chapter 5 Software Process Models. Problems with “Traditional” Processes 1.Focused on and oriented towards “large projects” and lengthy development time.
Do the right project the right way Agile Project Management for Oracle Implementations Applying eXtreme Techniques In a Plan-Driven Environment January.
Agile Software Development Chapter 3 – Lecture 1 Adrián Susinos.
Balancing Agility and Discipline A Guide for the Perplexed By: Barry Boehm and Richard Turner EECS 811: Software Project Management Presented By: Gabe.
~ pertemuan 2 ~ Oleh: Ir. Abdul Hayat, MTI 06-Mar-2009 [Abdul Hayat, The Project Management and IT Context, Semester Genap 2008/2009] 1 THE PROJECT MANAGEMENT.
Chapter 1 Object-Oriented Analysis and Design. Disclaimer Slides come from a variety of sources: –Craig Larman-developed slides; author of this classic.
USC-CSE Annual Research Review Los Angeles, CA March 17, 2004.
Balancing Agility and Discipline Chapter 2 : Contrasts and Home Grounds Presented By: Shawn Mulkey.
1 Software Process Models-ii Presented By; Mehwish Shafiq.
Software Engineering Principles Principles form the basis of methods, techniques, methodologies and tools Principles form the basis of methods, techniques,
Extreme Programming (XP). Agile Software Development Paradigm Values individuals and interactions over processes and tools. Values working software over.
Balancing Agility and Discipline Chapter 4 Sharon Beall EECS 811 April 22, 2004.
Application of the CMMI SM to Plan and Control Life Cycle Costs Dr. Mary Anne Herndon Science Applications International Corporation (SAIC) November, 2003.
1 © Mahindra Satyam 2009 Mahindra Satyam Confidential Welcome To CMMI Introduction.
IS Methodologies. Systems Development Life Cycle - SDLC Planning Planning define the system to be developed define the system to be developed Set the.
Chapter 3 Agile Software Development (1/2) Yonsei University 2 nd Semester, 2015 Sanghyun Park.
Software Engineering - I
CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Chapter 4 Agile Development Discussion of Agile Development and Agile Process.
Agile Working Group Agile Method Critical Success Factors.
AP-1 4. Agile Processes. AP-2 Agile Processes Focus on creating a working system Different attitude on measuring progress XP Scrum.
Lecture 4 – XP and Agile 17/9/15. Plan-driven and agile development Plan-driven development A plan-driven approach to software engineering is based around.
1 Discipline vs. Agility. 2 Topics What is discipline? What is agility? What are the misconceptions? Contrasts and home grounds Five critical factors.
Requirements Engineering Requirements Engineering in Agile Methods Lecture-28.
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall Appendix B Agile Methodologies B.1.
Chapter 2 : The Project Management and Information Technology Context Information Technology Project Management, Fourth Edition.
Agile. Processes Waterfall Traditional With prototyping Sprial Agile Dynamic Systems Development Method (DSDM) Scrum Crystal eXtreme Programming (XP)
Modelling the Process and Life Cycle. The Meaning of Process A process: a series of steps involving activities, constrains, and resources that produce.
Barry Boehm University of Southern California Richard Turner OUSD(AT&L)/DS/SE (George Washington University) Balancing Agility and Discipline: Evaluating.
Software Engineering (CSI 321) Software Process: A Generic View 1.
CS223: Software Engineering Lecture 16: The Agile Methodology.
Agile Development Chapter 10 - part 2. Agile Philosophy  A guiding philosophy and set of guidelines for : developing information systems in an unknown,
Capability Maturity Model. CS460 - Senior Design Project I (AY2004)2 Immature Organisations Software processes are often rigorously followed. Organisation.
1 Requirements Engineering for Agile Methods Lecture # 41.
Copyright 2015, Robert W. Hasker. Classic Model Gathering Requirements Specification Scenarios Sequences Design Architecture Class, state models Implementation.
Agile Gintarė Bernotaitytė © 2013.
Chapter 3 Agile software development 1 Chapter 3 – Agile Software Development.
Agile Project Management Athanasios Podaras
Agile Methods Agile Alliance
Chapter 2: The Project Management and Information Technology Context
Waterfall and Agile Quality Techniques
Agile Process: Overview
Chapt 2 Iterative Evolutionary Agile.
Agenda Start with Why What Are Best Practice Frameworks, and Why Do We Need Them? Best Practices Defined Lean, Agile, DevOps and ITSM/ITIL 4 The Increasing.
Chapter 5: New and Emerging Process Methodologies
Presentation transcript:

CMMI Technology Conference Denver, CO November 19, 2003 Using CMMI to Balance Agile and Plan-driven Methods Richard Turner The George Washington University OUSD(AT&L)/DS/SE

2 Background Success in any endeavor requires both agility and discipline Two approaches to software development – Plan-driven (SW-CMM, document-based, strong process) – Agile (XP, tacit knowledge, light process) Agile and plan-driven proponents are believers Both have strengths and weaknesses – balance is needed WARNING! Generalizations Ahead…

3 Some Observations on Balancing Neither agile nor plan-driven methods provide a silver bullet Agile and plan-driven methods have home grounds where each clearly dominates Future developments will need both agility and discipline Some balanced methods are emerging It is better to build your method up than to tailor it down Methods are important, but potential silver bullets are more likely to be found in areas dealing with – People – Values – Communications – Expectations management

4 1. No Silver Bullet Brooks’ werewolf concerns – Complexity, conformity, changeability, invisibility Agile methods – On target for changeability and invisibility – Miss on complexity and conformity Plan-driven methods – On target for conformity and invisibility – Miss on complexity and changeability Bullets can lose their efficacy as “wolves” evolve

5 2. Home Grounds Exist Agile and plan-driven methods have definite home grounds – Environment where they are most likely to succeed – Extremes are rarely populated Five dimensions can help illustrate a project’s or organization’s home ground relationship – Size, Criticality, Dynamism, Personnel, Culture

6 3. Future Applications Need Both Historically – Many small, non-critical, well- skilled, agile culture, rapidly evolving projects – Many large, critical, mixed-skill, ordered culture, stable projects In the future – Large projects are no longer stable – Maintenance of extensive process and product plans will become too expensive – Complexity and conformity werewolves are waiting for agile projects – Attributes of both approaches will be needed

7 4. Balanced Methods are Emerging Agile methods – Crystal Orange – DSDM – FDD – Lean Development Plan-Driven methods – Rational Unified Process – CMMI Hybrid – Boehm-Turner Risk-based – Manzo (AgileTek) Code Science/Agile Plus

8 5. Build up – Don’t Tailor Down Plan-driven methods traditionally Plan-driven methods traditionally – Have over defined processes – Advocate (or require) tailoring – Are rarely tailored well Agilists traditionally Agilists traditionally – Begin with the minimum – Add as needed (and justified by cost- benefit) – Have multiple core sets

9 6. Methods aren’t always the answer Agile movement has echoed a long line of warning calls Success of agile may be due as much to people factors as to technology Valuing people over processes is the most important factor in the agile manifesto I know I saw something about that in the process somewhere…

10 People Development is “of the people, by the people, for the people” Separation of concerns is increasingly harmful

11 Values Reconciling values is a critical people-oriented task Stakeholders value different things Software engineering is usually value-neutral Process improvement and plan-driven methods are inwardly-focused – Aimed at productivity improvement – Not higher value to customer Agilists attention to prioritization and negotiation are promising

12 Communications Face it, most engineers can’t talk, much less write IKIWISI and management- by-rock reign Rapid change increases need for solid communication Few sources of guidance – Alistair Cockburn’s Agile Software Development is a good starting place

13 Expectations Management Differences between successful and troubled projects is often expectations management SW developers have problems with EM – Strong desire to please – Avoid confrontation – Little confidence in prediction – Over confidence in abilities Most significant common factor in successful plan-driven/agile teams EM means not setting up unrealistic expectations – Process mastery – Preparation – Courage Developers seem to like Sisyphean tasks…

14 So… How does CMMI help balance? Flexibility Broader engineering and management scope Addresses people aspects High maturity

15 Flexibility Goals and practices are more flexible in CMMI – Need to span differences led to more general language – Alternative practices provide an entry point for innovative approaches Continuous representation provides more flexibility in deciding what PI should address

16 Broader Engineering and Management Scope Supports agile technical/management approaches – Product Integration PA can support continuous integration – Engineering and Support Pas (e.g. VAL, CM) are compatible with test-driven design and automated tools Agile methods are often both iterative and concurrent – Recursion of engineering PAs (e.g. RD, TS) supports iterative development – Broader scope allows multiple disciplines and approaches for different components Agile for emerging or rapidly evolving components Plan-driven for well-understood or regulated components

17 Addresses People Aspects Values Values – Effective SE (e.g. trade studies) cannot be value neutral (DAR) Communication Communication – IPPD, shared vision, and stakeholder concerns make for more effective communications (IPM, PP) Expectation Management Expectation Management – Emphasis on measurement produces good data that enables effective expectation management (MA)

18 High Maturity Innovation at level 5 argues for agile approaches Having both agile and plan-driven standard processes allows marketplace agility Application of Lean and Six Sigma techniques at high maturity levels eliminates non-value added processes and results in more agile tailor-up rather than tailor-down approaches

19 A Risk-based Balancing Process

20 How CMMI Supports the Process PP, RSKM RSKM DAR, TS PMC, PI, TS PP, OPD

21 Conclusions Plan-driven and agile methods both aim to – Satisfy customers – Meet cost and schedule parameters Home grounds exist, but the opportunity for integration is expanding CMMI supports balancing methods – Flexible application of the model allows both plan- driven and agile methods – PA support to risk-based balancing process For more on the risk-based process, see – Boehm/Turner, Balancing Agility and Discipline: A Guide for the Perplexed, Addison Wesley, Boston, 2003.

22 Contact Information Rich Turner x124

23 Back-up

24 Five Critical Dimensions

25 Summary of Home Grounds CharacteristicsAgileDisciplined Application Primary GoalsRapid value; responding to changePredictability, stability, high assurance SizeSmaller teams and projectsLarger teams and projects EnvironmentTurbulent; high change; project-focusedStable; low-change; project/organization focused Management Customer RelationsDedicated on-site customers; focused on prioritized increments As-needed customer interactions; focused on contract provisions Planning/ControlInternalized plans; qualitative controlDocumented plans, quantitative control CommunicationsTacit interpersonal knowledgeExplicit documented knowledge Technical RequirementsPrioritized informal stories and test cases; undergoing unforseeable change Formalized project, capability, interface, quality, forseeable evolution requirements DevelopmentSimple design; short increment; refactoring assumed inexpensive Extensive design; longer increments; refactoring assumed expensive TestExecutable test cases define requirements, testing Documented test plans and procedures Personnel CustomersDedicated, collocated CRACK* performersCRACK* performers, not always collocated DevelopersAt least 30% full-time Cockburn level 2 and 3 experts; no Level 1B or -1 personnel** 50% Cockburn Level 3s early; 10% throughout; 30% Level 0’s workable; no Level -1s** CultureComfort and empowerment via many degrees of freedom (thriving on chaos) Comfort and empowerment via framework of policies and procedures (thriving on order) * Collaborative, Representative, Authorized, Committed, Knowledgeable ** These numbers will particularly vary with the complexity of the application