My Observations from SEPG 2002 March 7, 2002

1. My Observations from SEPG 2002March 7, 2002 Larry Dribin, Ph.D. SOGETI, A CAP GEMINI COMPANY Phone: (847) 807-7390 Email: ldribin@cs.depaul.edu or ldribin@usa.capgemini.com V1.1

2. What Were My Most Important Lesson Learned? • It was a hard choice - 7 concurrent tracks • 2 tracks on Level 2 • 1 tracks on Level 3 • 2 tracks on Special Topics • 1 track on CMMI • Topics I Considered: • “Do’s and Don’ts of Software Process Improvement” • “What the Authors Intended at Levels 4 and 5” • “Aggressively moving from CMM Level 1 to CMM Level 3 in One Year” • “What Would I Do Differently If I Wrote The SEPG Guide Today?” • “Competitive Software Teams” I learned quite a bit in these session, but no “Ah Ha”!

3. I Had An “Ah Ha” After Attending: • Keynote: “Conversations with Watts Humphrey”, by Michael Mah • Keynote: Barry Boehm, “The Fate of Bright Ideas: Why They are Not Always Adopted” • Panel Session: “Capability Maturity Models Are Not Relevant in Modern Development Environments” Ah Ha: Agile Processes & CMM (versus Agile or CMM) • Panel Session: “The Loyal Opposition Versus the CMMI Champions: A Frank Discussion of CMMI Models” Ah Ha: The CMM May Still Live (versus CMM  CMMI) After attending these sessions I felt as though major changes may be underway in software process improvement.

4. First Remember the CMM-SW Vision “ I wanted to get software organizations to adopt Deming’s approach to continuous improvement, but I realized it had to be done in stages.” • Watts Humphrey, creator of the CMM-SW • Eliminate chaos (Level 2) • Establish common processes (Level 3) • Understand process capability and control variation in process performance (Level 4) • Continuously improve capability of critical processes (Level 5)

5. First Remember the CMM-SW Vision, but … “ I wanted to get software organizations to adopt Deming’s approach to continuous improvement, but I realized it had to be done in stages.” • Watts Humphrey, creator of the CMM-SW • Eliminate chaos (Level 2) • Establish common processes (Level 3) • Understand process capability and control variation in process performance (Level 4) • Continuously improve capability of critical processes (Level 5) Source: Pat O’Toole, “The Do’s and Don’ts of Software Process Improvement”

6. Agile Processes & CMM (versus Agile or CMM)Pro CMM: CMMs are Relevant because they work! • Source: Stan Rifkin, • “CMMs are Relevant to Modern Software Development”

7. Agile Processes & CMM (versus Agile or CMM)Con CMM: People oriented “Barely Sufficient Methodology” Source: Jim Highsmith, Cutter Consortium, “Is the CMM: Is It Relevant Today?”

8. Agile Processes & CMM (versus Agile or CMM)Con CMM: CMM Supports Waterfall and not Modern Iterative Development Processes Source: Walker Royce, Rational Software, “Are Capability Maturity Models Relevant in Modern Development Environments?”

9. Agile Processes & CMM (versus Agile or CMM)My Take Away • CMM experts are talking about agile approaches to software development • Too often these experts “demonize” the new agile approaches • Each may have its own home space • Source: Interpretation of Barry Boehm’s keynote • The key is that the dialog has begun • This dialog is healthy and should generate improvements in Software Process Improvement!

10. The CMM May Still Live (versus CMM  CMMI)Background • Source: “The Loyal Opposition Versus the CMMI Champions: A Frank Discussion of CMMI Models” (Panel Discussion, Marilyn Bush Moderator)

11. The CMM May Still Live (versus CMM  CMMI)Pro CMMI • CMMI explicitly links to business objectives vs. implicit in CMM • CMMI Incorporates learning from CMM-SW (CMM v2c was the starting point) • It includes Product Engineering • It Covers Standards and Business Strategies • Applies well to small organizations • Adapts to different improvement approaches • Staged vs. continuous • Expands to incorporate new disciplines Source: Mike Konrad - Software Engineering Institute Tim Kasse - Kasse Initiatives

12. The CMM May Still Live (versus CMM  CMMI)Pro CMM – Pro Choice • The CMM serves the un-served majority (Commercial non-DOD, non-Systems Engineers) • CMMI is TOO BIG • CMMI is TOO EXPENSIVE • CMMI is hard to tailor and forces unnecessary complexity • It buries known vital things • Compromised and confusing representations • CMM is Being Suppressed (a.k.a. Sunsetting of the CMM-SW at the end of 2003 (2005) Source: Judah Mogilensky - Process Enhancement Partners Mark Servello - ChangeBridge

13. The CMM May Still Live (versus CMM  CMMI)Pro CMM Proposal: Free V2 • CMM v2.0c – October 1997 was almost ready to be released • An enhancement to CMM-SW v1.1 • Smaller and “lighter” than the CMMI • Movement started to release CMM version 2 (which was about to be released when the project was shut down in favor of CMMI three years ago) • If SEI will not release it, possible release it as a “freeware” document • Provide training courses in CMM v2.0 • Provide an assessment approach similar to the CBA-IPI for CMM-SW v2.0 • Key issue is funding Let the market decide between CMM-SW and CMMI

14. Summary • We are in exciting times • New ideas – Agile Programming • New Products – CMMI v1.1 (and CMM v2.0?) • Thought provoking. Let’s watch what happens. Renewed energy and new choices which will improve the state of Software Process Improvement.