Your SlideShare is downloading. ×

Agile Evidence For CMMI SCAMPI


Published on

Presentation by Hillel Glazer & Judah Mogilensky at SEPG North America 2010 in Savannah, GA USA.

Presentation by Hillel Glazer & Judah Mogilensky at SEPG North America 2010 in Savannah, GA USA.

Published in: Business
1 Comment
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. SEPG‐NA‐2010 Judah Mogilensky, Process Enhancement Partners, Inc. Hillel Glazer, Entinex, Inc.
  • 2. Your Hosts: High Maturity Lead Appraisers B&C Team Leaders Instructors DEV, SVC, P‐CMM Previously also worked with ISO 9000 + you name it. Degreed engineers Combined 50+ years in process improvement Profoundly NOT box‐checkers!
  • 3. Today’s Discussion Agile view of CMMI CMMI view of Agile Proof Reconciling CMMI and Agile Theory vs. Practice Interpreting CMMI for Specific Contexts (such as  Agile) Examples from Engineering PAs Take‐Home
  • 4. Agile  view of  CMMI 24‐Mar‐10 Image Credit: prohibited. Bureaucracy Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  4
  • 5. Agile view of CMMI 24‐Mar‐10 Photo Credit: prohibited. Paper‐centric Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  5
  • 6. CMMI  view of  Agile 24‐Mar‐10 Photo Credit: prohibited. Juvenile Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  6
  • 7. CMMI  view of  Agile 24‐Mar‐10 Photo Credit: prohibited. Wild West Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  7
  • 8. Proof: 24‐Mar‐10 Photo Credit: Feet and Feet of binders! Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  prohibited. 8
  • 9. Proof: 24‐Mar‐10 Photo Credit: Interview or interrogation? Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  prohibited. 9
  • 10. Proof: 24‐Mar‐10 Photo Credit: Web Apps ≠ Flight Software Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  prohibited. 10
  • 11. Proof: Photo Credit: No policy, no plan, no discipline! 24‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  prohibited. 11
  • 12. Progress 24‐Mar‐10 More to come in v1.3 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  prohibited. 12
  • 13. Reconciling CMMI and Agile Communication: Understanding how words are used. Understanding how work is done. Understanding what represents work done. Practices, Models, Representations There are many ways to represent reality. Models require context. In context, artifacts will vary greatly.
  • 14. It’s one thing  in theory… Models need to be made concrete. 24‐Mar‐10 Photo Credit: Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  prohibited. 14
  • 15. It’s one thing  in theory… Many ways to look at the same thing. 24‐Mar‐10 Photo Credit: Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  prohibited. 15
  • 16. How to interpret CMMI for specific  contexts? What is the point or purpose of the practice?   What risks or problems is the practice trying to avoid?   What is the organization or project doing to achieve the purpose  or avoid the problem?  Ask the question(s) backwards: What are you doing that addresses the practices and goals? How do you avoid the risks the practices (and goals) expect you to  be avoiding? In which of your outputs do what you do  to address the practices  and goals "show up"? If your efforts accomplish what CMMI expects you to  accomplish, your interpretation is acceptable. What does the CMMI expect you to accomplish? Read the informative material!
  • 17. Just because we say these  things can be evidence  does not automatically  mean that what any one  organization is doing is appropriate evidence.
  • 18. Requirements Development SP 1.2 Develop Customer Requirements:  Usually, appraisal teams expect to see a requirements  document prepared by the developer that reflects the  requirements that have been elicited from the customer  and other stakeholders.  In Agile projects, the customer may provide a documented  set of requirements, but often the requirements are elicited  through a series of meetings and discussions, and are  captured in a spreadsheet or requirements data base. The  spreadsheet or data base itself serves as evidence for this  practice, even if no "requirements document" is ever  produced.
  • 19. Backlog 24‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  19 prohibited.
  • 20. Requirements Development SP 2.1 Establish Product and Product Component  Requirements:  Usually, appraisal teams expect to see a System or Software  Requirements Specification (SRS), detailing the technical  requirements to be implemented.  In Agile projects, it is more common to capture technical  requirements to be implemented in the form of Stories.  The compilation of Stories, which may again be in a  spreadsheet or data base, or may simply be a digital photo  of sticky notes posted on a wall, would serve as evidence for  this practice.
  • 21. A User Story 24‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  21 prohibited.
  • 22. User Stories on a wall 24‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  22 Photo Credit: prohibited. Corey Ladas
  • 23. Requirements Development SP 3.1 Establish Operational Concepts and Scenarios:  Usually, appraisal teams expect to see an Operational  Concept Document (OCD) or something similar.  In Agile projects, the team generally produces a set of  Use Cases or epic stories, which are typically  reviewed with, and often approved by, the customer.  The set of Use Cases would serve as evidence for this  practice
  • 24. An Epic (mega‐story) 24‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  24 prohibited.
  • 25. Technical Solution SP 2.1 Design the Product or Product Components: Usually, appraisal teams expect to see a Systems or Software  Design Document (SSDD or SDD), or something similar.  In Agile projects, practitioners will often assert that "we  don't do designs." But, when asked "How do programmers  know what to implement?", they will often explain that  detailed Unit Tests are prepared for components or tasks,  before they are implemented, containing all the details of  the required behavior of the item. These Unit Tests would  serve as evidence for this practice.
  • 26. Test‐Driven Development 24‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  26 Diagram Credit: prohibited.
  • 27. Many ways to "document" 24‐Mar‐10 Data flow Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  prohibited. 27
  • 28. Many ways to "document" 24‐Mar‐10 Architecture Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  prohibited. 28
  • 29. Many ways to "document" 24‐Mar‐10 Design Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  prohibited. 29
  • 30. Many ways to "document" 24‐Mar‐10 Sketch Credit: prohibited. User Functionality Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  30 Scott Ambler
  • 31. Technical Solution SP 3.1 Implement the Design:  Usually, appraisal teams expect to see, for software  development projects, actual source code and/or  Version Description Documents (VDDs).  In Agile projects, also, source code would serve as  evidence for this practice. 
  • 32. Source  Code 24‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  32 Photo Credit: prohibited.
  • 33. Verification SP 2.1 and SP 2.2 Prepare for Peer Reviews,  Conduct Peer Reviews:  In many Agile projects, pair programming is practiced,  where two developers work together at the same time to  develop code, constantly commenting on each other's  work.  It is, therefore, tempting to treat pair programming  as "peer review" for purposes of these practices.  However, the nature of the activity is that little if any of the  pair interaction is actually recorded anywhere, and Agile  developers have objected that it would be very  burdensome, with no value added, to attempt to document  these interactions. 
  • 34. Pair Programming Is not an  automatic  “FI.” 24‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  34 Photo Credit: prohibited.
  • 35. Refactoring After Before 24‐Mar‐10 Photo Credit: prohibited. A lot closer. Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  35
  • 36. Requirements Development SP 3.5 Validate Requirements, and the Validation Process Area:  Usually, appraisal teams expect to see pre‐development simulations or  prototyping for the validation of requirements, and testing of the  system using operational scenarios in real or simulated operational  environments for the Validation. PA.  In Agile projects, development consists of a series of increments,  typically produced at two‐week intervals, each with successively more  complete functionality.  Every increment will undergo some level of  testing based on use cases.  There is no clear, well defined break  between "early prototyping" and "final system development", since  both are done using essentially the same process. Therefore, the plans  and results of use case testing for very early increments can serve as  evidence for validation of requirements, while the same type of plans  and results for use case testing for the late increments can serve as  evidence for the Validation PA
  • 37. Demo  Day 24‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  37 Photo Credit: prohibited.
  • 38. Take‐Home Do not look at the names of documents or to insist on  certain pre‐defined types of evidence.  Understand what is the underlying purpose and  objective of the CMMI practices, and what is the project  doing to accomplish that purpose, even if what they are  doing may seem unconventional at first
  • 39. Take‐Home Some Lead Appraisers and Team Members (who have  only worked in an environment of large systems  developments for defense customers), may need  something of a mindset shift to see how Agile artifacts  fit into CMMI practices. This isn’t only true when dealing with Agile projects!
  • 40. Take‐Home – Another angle Some projects may not have even the types of artifacts  noted above.  Perhaps they are only doing configuration of off‐the‐shelf  products, or designing screens and reports using menu and  checklist‐based tools.  In such cases, it may be important to ask, "Is the project  actually doing engineering development, in any meaningful  sense?"  It may be that some projects are more like "paint‐by‐ numbers" than actual engineering developments, in which  case even attempting a CMMI‐DEV‐based appraisal may be  inappropriate.
  • 41. CAUTION: You may not be doing engineering. Session by Hillel on . . .  @ . . .  In . . . .
  • 42. Don’t be strangers! 24‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution  42 prohibited.