agile evidence for cmmi scampi

SEPG‐NA‐2010Judah Mogilensky, Process Enhancement Partners, Inc.

Hillel Glazer, Entinex, Inc.

Your Hosts:High Maturity Lead AppraisersB&C Team LeadersInstructorsDEV, SVC, P‐CMMPreviously also worked with ISO 9000 + you name it.Degreed engineersCombined 50+ years in process improvementProfoundly NOT box‐checkers!

Today’s DiscussionAgile view of CMMICMMI view of AgileProofReconciling CMMI and AgileTheory vs. PracticeInterpreting CMMI for Specific Contexts (such as Agile)Examples from Engineering PAsTake‐Home

Agile view of CMMI

4BureaucracyImage Credit:http://www.flickr.com/photos/genesgraphics/3795769986/

24‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution prohibited.

http://www.flickr.com/photos/genesgraphics/3795769986/

Agile view of CMMI

5Paper‐centricPhoto Credit:http://www.flickr.com/photos/yusheng/3468324165/


http://www.flickr.com/photos/yusheng/3468324165/

CMMI view of Agile

6JuvenilePhoto Credit:http://www.flickr.com/photos/oybay/242535156/


http://www.flickr.com/photos/oybay/242535156/

CMMI view of Agile

7Wild WestPhoto Credit:http://www.flickr.com/photos/jason_lloyd/2228091536/


http://www.flickr.com/photos/jason_lloyd/2228091536/

Proof:

8Feet and Feet of binders!Photo Credit:http://www.gruntledemployees.com/photos/uncategorized/2007/05/12/hr_file_binders.jpg


http://www.gruntledemployees.com/photos/uncategorized/2007/05/12/hr_file_binders.jpg

Proof:

9Interview or interrogation?Photo Credit:http://www.flickr.com/photos/30529616@N00/3208944772/


http://www.flickr.com/photos/30529616@N00/3208944772/

Proof:

10Web Apps ≠ Flight SoftwarePhoto Credit:http://www.flickr.com/photos/nichola80/3163243854/


http://www.flickr.com/photos/nichola80/3163243854/

Proof:

11No policy, no plan, no discipline!Photo Credit:http://www.flickr.com/photos/tronics/380379732/


http://www.flickr.com/photos/tronics/380379732/

Progress

12More to come in v1.324‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution prohibited.

Reconciling CMMI and AgileCommunication:

Understanding how words are used.Understanding how work is done.Understanding what represents work done.

Practices, Models, RepresentationsThere are many ways to represent reality.Models require context.In context, artifacts will vary greatly.

It’s one thing in theory…

14Models need to be made concrete.Photo Credit:http://www.flickr.com/photos/68888883@N00/2582964078/


http://www.flickr.com/photos/68888883@N00/2582964078/

It’s one thing in theory…

15Many ways to look at the same thing.Photo Credit:http://www.flickr.com/photos/frizztext/1541584634/


http://www.flickr.com/photos/frizztext/1541584634/

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!

Just because we say these things can be evidence does not automatically mean that what any one organization is doing isappropriate evidence.

Requirements Development SP 1.2Develop 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.

Backlog


19

Requirements Development SP 2.1Establish 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.

A User Story


User Stories on a wall


22Photo Credit:Corey Ladas

Requirements Development SP 3.1Establish 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

An Epic (mega‐story)


24

Technical Solution SP 2.1Design 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.

Test‐Driven Development

26Diagram Credit:http://www.flickr.com/photos/brunobord/3987593006/


http://www.flickr.com/photos/brunobord/3987593006/

Many ways to "document"

27Data flow24‐Mar‐10 Copyright PEP‐Inc., and Entinex, Inc. All rights reserved. Unauthorized duplication or distribution prohibited.

Technical Solution SP 3.1Implement 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.

Source Code

32Photo Credit:http://www.flickr.com/photos/schoschie/8821223/


http://www.flickr.com/photos/schoschie/8821223/

Verification SP 2.1 and SP 2.2Prepare 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.

Pair Programming

34

Is not an automatic

“FI.”Photo Credit:http://www.flickr.com/photos/tojosan/152763907/


http://www.flickr.com/photos/tojosan/152763907/

35A lot closer.Photo Credit:http://www.flickr.com/photos/progrium/

Before

After

Refactoring


Requirements Development SP 3.5Validate 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

Demo Day

37Photo Credit:http://www.flickr.com/photos/juanpol/5894688/


http://www.flickr.com/photos/juanpol/5894688/

Take‐HomeDo 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

Take‐HomeSome 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!

Take‐Home – Another angleSome 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.

CAUTION:You may not be doing engineering.

Session by Hillel on . . . @ . . . In . . . .

Don’t be strangers!


agile evidence for cmmi scampi

Business