agile life cycle cmmi clues - entinex, inc.entinex.com/agilelifecyclecmmiclues.pdf · practices...

Agile Lifecycle CMMI® Clues

410.814.7513 410.387.7579 www.entinex.com - 1 – ©Entinex, Inc. PROPRIETARY & CONFIDENTIAL. All formatting and content subject to non-disclosure agreement.

No use or reproduction permitted without permission of Entinex, Inc.

Introduction

Entinex has been at the forefront of blending Agile and CMMI since the creation of the Agile Manifesto. In fact, it is widely acknowledged that Entinex’s founder, Hillel Glazer, is largely responsible for creating the field in which Agile practices and CMM/CMMI can work together.

Even with—or perhaps as a result of—the depth and breadth of successful experience working with CMM and CMMI in agile contexts, as a matter of corporate policy, Entinex has stayed away from providing explicit mappings among agile and CMMI practices. The non-successful attempts to have agile and CMMI work together have played a large role in this policy.

A persistent failure mode among the unsuccessful instances manifests regularly. This failure mode is common in any environment (agile or otherwise) when practices (of any kind, CMMI or agile) are force-fit into a situation without regard for the context. This is almost indistinguishable from taking a very literal, narrow, or strict interpretation of the practices in question. Interpretation problems arise when the values and principles behind the practices are poorly understood (or outright ignored). Thus, an authoritative document equating particular agile practices with particular CMMI practices is not what is contain herein.

Practices are highly context-specific. They are transitory instantiations of a broader, more important value that’s being sought to achieve. As examples, daily stand-ups and configuration audits in and of themselves are not as explicitly important as the benefits realized when performing daily stand-ups and configuration audits. The value lies in why such constructs were created not in the particular practices themselves. Not to be overlooked, the first value statement in the Agile Manifesto: Individuals and interactions over processes and tools is rather clear about what’s more important. Yet agile proponents are just as guilty as CMMI users about sticking to and defending their processes in the face of diminishing returns.

Every musician and athlete practices their talent because they understand the value of practicing. It’s not the specific practices that an individual performs that’s important as much as it’s the act of finding practices that work and then executing the practices they’ve identified. The specific practices each individual identifies are their own and may not work for someone else. Each musician and athlete identifies their own personal “most effective” practices and ways of practicing. That different athletes and different musicians practice differently is to be expected. That athletes from different sports and musicians of different instruments would have very different practices does not weaken the underlying value of practices.

Oddly, when it comes to improving the performance of organizations—especially in the software market—it appears that everyone attempts to copy someone-else’s practices. Perhaps worse, many organizations assume that practices, as defined by the all-powerful all-knowing “they”, are meant to be followed verbatim without the same context-specific application that athletes and musicians perform effortlessly.

Rather than a mapping among agile and CMMI practices, which experience has taught would merely proliferate the failure mode and would undermine true improvement, the Agile Lifecycle Performance Clues is intended to provide agile practitioners and CMMI users with a way to have a conversation about the relationships among the respective practices. The nature of this conversation is hoped to help increase the performance benefits of agile practices while also demonstrating the discipline they’re capable of achieving. At the same time, we hope this conversation sheds light on ways in which agile practices can or do implement CMMI practices with or without, as appropriate, any changes to the underlying agile practices.




An important consideration for all readers is that the connections among agile and CMMI practices are only valid when both sides of the conversation are genuinely using the respective practices to achieve their underlying value and not solely for appearances of doing so.

This release of Agile Lifecycle Performance Clues focuses on the most common agile practices. To meet certain market demands and user base requests, there is a deliberate bias towards Scrum practices. As such, this release does not claim to be comprehensive to all forms of agile practices. This “mapping” of clues between agile activities and CMMI does not imply that CMMI only works when teams use all of these activities, such as Pairing or TDD for example.

It’s important to note that performing the agile activities listed in any lifecycle stage does not confer or imply that the CMMI practices listed with them are by association alone being performed. It is entirely possible that an agile activity can be carried-out with so little structure, discipline or consistency that CMMI practices are entirely unsupported or the improvement implied by performing the practices realized. Furthermore, CMMI goals are comprised of several specific practices each. In some cases, a CMMI goal is very broad. Listing a CMMI goal by an agile activity is not meant to imply that all the practices in the indicated goal are covered, or that the connection is unequivocally strong to any practice. For the sake of completeness, please note that CMMI Process Areas are comprised of Specific Goals and Generic Goals. All “goals” listed in this document are Specific Goals.

Out of the box, agile practices are generally weak on planning the activities ahead of doing the activities. “Planning” for activities such as TDD, product integration and refactoring frequently take the form of a reliance on training, tools, coaching and professionalism. This reliance tends to omit detailed thinking about the process to be used or the outcomes to expect prior to beginning work. As a result, it can be difficult to identify why efforts don’t meet expectations. And except in the rough sense of whether or not work was completed in the expected period of time, the lack of planning around processes inhibits insight into forewarning that effort will not meet expectations.

Several CMMI process areas begin with goals whose intent are to plan the process activities of that process area. For example, Verification, Validation, and Risk Management are process areas for which the purpose of “Goal 1” are about the planning for the activities of conducting verification, validation, and risk management efforts, respectively. In agile contexts, planning for these activities are often handled via group norms or policies. However, in some cases, agile teams rely entirely on ad hoc planning that takes place verbally immediately before the effort. When this is commonplace, it is nearly impossible to identify the failure mode or mechanism for either when defects are later found or for when the productivity of the effort falls short.

CMMI also emphasizes post-action analysis. The analysis relies on the initial planning. It is not uncommon, therefore, that in settings where planning is weak, the analysis is weak as well. When this happens in agile settings, retrospectives lose their value and become focused on immediate issues rather than systemic, persistent or intrinsic issues. This mirrors what’s expected in agile practices. Demos and retrospectives are intended to compare to iteration or release planning. When planning is weak the learning that can be expected from retrospectives or demos is minimized.

Practices that occur throughout a lifecycle include, at a minimum, DAR, CM, PPQA

Practices that occur between the steps of a lifecycle, at a minimum, PPQA, MA

Practices that occur outside of the lifecycle, at a minimum, OT, SAM, OPD




This context diagram provides a sense of the relationship among three sets of concepts: The foundation that includes, Lean, TQM (Total Quality Management) and Continuous Learning, CMMI Practices, and Agile Activities. Depicted here is the idea that both CMMI Practices and Agile Activities are each manifestations of a desire to bring about the benefits of Lean, TQM and Continuous Learning. Also depicted is the content of this document: the clues to help better connect the relationship between CMMI Practices and Agile Activities. To avoid confusion, as noted earlier, the remainder of this document does not delve into the CMMI Practices themselves but rather remains at the CMMI Goal level. CMM, CMMI, and SCAMPI are ® registered in the U.S. Patent and Trademark Office by Carnegie Mellon University




Agile Lifecycle Event or Phase

Agile Activity Supports or Supported By CMMI Goals

What is the relationship between the Agile Activity and the CMMI Goals?

Crafting User Stories

Writing Stories REQM

The act of writing stories, starts the path towards understanding requirements. Writing stories also often results in splitting or combining stories which can convey a level of commitment as well as changes to the stories and changes to other aspects of a project resulting from changes to stories.

RD Goal 1 Stories are the most likely artifact of capturing requirements.

Validating Stories

RD Goal 3 Working with the customer or product owner to validate requirements invokes much of the thinking behind RD Goal 3.

VAL Goal 2 Validation activities are not limited to functional product or testing. While still in the story “state”, requirements can be validated. The trick being to have considered what one validates against in the first place.

Writing Acceptance Criteria

RD all Goals

Writing Acceptance Criteria involves much of the thinking necessary to develop requirements. In some agile settings product owners, users, or customers may be writing the acceptance criteria and later reviewed by or with the development team members. Either way, providing a checklist mirroring RD can help improve the quality of the acceptance criteria.

VER Goal 1

Thinking about and defining what will be verified is an integral part of Writing Acceptance Criteria. When performed with some deliberate framing, writing acceptance criteria can be powerfully leveraged for the eventual peer review, refactoring, demo, or retrospectives activities.

VAL Goal 1

Thinking about and defining what will be validated is an integral part of Writing Acceptance Criteria. When performed with some deliberate framing, writing acceptance criteria can be powerfully leveraged for the eventual demo and UAT.







Planning

Chartering

IPM both Goals OPD has a localized “standard” for and IPM carries out how teams will deal with teaming—whether internally or with other agile (or non-agile) teams. The agile act of chartering the project (team) often accomplishes much of what’s desirable in these CMMI areas. OPD

Backlog Grooming

REQM

Grooming the backlog is often how changes to requirements, commitments, resources and other planning attributes are worked into the project. “Grooming” can be thought of as a synonym for “managing”. In fact, “managing requirements” is a fancy way to say “control scope creep”. Wherever an agile team puts creep control mechanisms in place there’s a good chance requirements management is happening.

PP Goals 1 & 2

While Backlog Grooming isn’t the ideal place for an agile team to be dealing directly with breaking-down a project’s planning, it’s not entirely unrealistic for some planning to be going on by the groomers themselves. Given that it’s likely to be happening anyway, containing the possible impact of such behavior with some productive thinking in favor of the team would be so bad.

Release Planning

PP Goals 1 & 2

Unlike Backlog Grooming, what it takes to produce a release does actually contain much of the thinking consistent with planning a project. The term “project” in CMMI is a bit loaded and misleading. For these and other reasons CMMI for Services switched to using the term “work”. Nowhere in CMMI does it claim to state that the entire project be planned up front. However, when doing planning activities (such as when doing Release Planning), the goals in PP improve the chances of a successful release by ensuring some of the oft-overlooked details and the relationships among them are accounted for.

IPM Goal 1 The processes to be used in a release together with the other work going on within the team and the team’s partners are best discussed and agreed-upon during release planning.







Release Planning (cont’d)

RSKM Goals 2 & 3

Agile activities are largely silent on formal advance consideration for how to deal with risks before they present themselves. However, once identified, agile practices include among the more resilient approaches to dealing with the risks. The key to improving risk management on agile projects lies in the preparation for dealing with risks (RSKM Goal 1--not addressed with typical Release Planning) and then the follow-through as is common in the discussions that go on in Release Planning are grounded in a robust framework.

Sprint/Iteration Planning

PP Goals 1 & 2 The project details not elicited in Release Planning would more naturally take place with each Iteration Planning activity.

IPM both Goals

Any details about the working-out of who does what not brought-up during Release Planning would come up in Iteration Planning. It’s also in Iteration Planning that when and how partners and stakeholders beyond the team will be involved.

RSKM Goal 2 & 3 See Release Planning.

MA both Goals

Effective, disciplined Iteration Planning includes quantitative and qualitative considerations based on previously collected measures. Velocity, story points, task hours, bug fix reserve, refactoring time, etc. Are all based on measures. While measures are not limited to planning activities, the response to the intelligence provided by measures would typically show up when planning upcoming activities.

VER Goal 1 While planning activities often focus on the immediate work of product development, it is during these planning activities that thought is most likely being put into (or ought to be) what needs to be verified and validated, as well as how and using what resources.

VAL Goal 1

Story Point Estimating

PP Goal 1

Story Point Estimation is a highly simplified version of the Delphi Method of estimation. The fact that it’s simplified does not imply that many of the details and benefits of the Method are eliminated or unavailable. The rationales behind the converged story point values as well as meta-







information about the stories and the process of converging are all useful information with which to plan and account for effort and time on the release.

Story Point Estimating (cont’d)

RSKM all Goals

With slight changes to the formality of doing story point estimation, an approach to this activity that includes capturing the rationale behind the range of inputs as well as the final point number provides greater depth and confidence in the story and resulting point value. The definition of such an approach can then improve the overall risk profile of a project and for each release, and iteration. Collaterally, RSKM Goal 1 would be embedded into such an approach. Also, the agile planning concept of a spike is, in and of itself, a mitigation effort of the sort found in RSKM Goal 3. Meanwhile, however, how a team decides to spike a story is something that would appear in RSKM Goals 1 & 2.

MA Goal 2

Goal 2 of Measurement and Analysis is merely the set of practices to ensure and improve collection, analysis, use, communication and storage of measures. Story Point Estimating is merely one agile activity that produces measures. Furthermore, the measures produced in Story Point Estimating are not limited to the story points themselves, but actually encompass a rich source of many other measures for teams who pay close enough attention to what’s really going on.

Tasking PP all Goals

Breaking stories down into tasks both relies upon and feeds into planning the work. Especially in a time-boxed iteration, it is recommended that all work that takes time be accounted-for. It is even more imperative that time-boxes with little or no acknowledged slack account for all tasks that consume available iteration time and resources. Identification of tasks is where “the rubber hits the road” for the people doing the work. Therefore, all conflicts, commitments, risks, etc. need to be brought up during the Tasking activities or the project risks being surprised by unplanned work and disruptions.







Tasking (cont’d)

IPM Goal 2

As described in the above activity, breaking stories into tasks is where the details and the true nature of the work are often hidden. The extent to which collaboration and coordination among stakeholders will be needed to perform the work will show up here if it hasn’t already shown up.

Team Commitments

PP Goal 3

When teams choose their tasks, they are making commitments. When tasks are unclear or in conflict with other tasks or other characteristics of the work the tasks or stories are expected to be returned to the backlog or referred to other resources for disposition. If enough of the project’s effort is already known prior to creating it, sometimes, the agile team’s charter can capture the benefits of PP Goal 3.

IPM Goal 2 When teams collaborate with other teams and stakeholders, they are usually operating in the realm of the practices within this goal. This is often included in teaming charters, when used.

REQM It is the team’s responsibility to accept or reject user stories and acceptance criteria as a reflection of the quality of these items. Low-quality user stories or acceptance criteria are a common source of scope creep.

Design/Engineering

Pairing

TS all Goals

Pairing is often where engineering design and solution-finding takes place in agile teams. There is nothing inherent in Pairing that accomplishes engineering design and solution-finding, but when a pair of developers set-off to figure something out, this is often a common means of accomplishing this.

PI Goals 2 & 3

Pairing is often where interface analysis takes and product assembly place in agile teams. There is nothing inherent in Pairing that accomplishes interface analysis takes and product assembly, but when a pair of developers set-off to analyze the interaction among components or to create a build or a connection among components, this is often a common means of accomplishing this.

Whiteboarding RD all Goals An acknowledged challenge in agile contexts is the means by which and the extent to which the details of conversations and whiteboard sessions are







captured. Nonetheless, it is important to note that CMMI is intended to improve the performance of an operation via the improvement of its processes. When there are issues with an operation’s engineering quality or performance and those activities are not laid-out in the first place or captured while under way, the ability to detect, find, analyze and address problem areas is minimal. With this in mind, agile engineering teams are well-advised to establish norms, standards and expected artifacts for performing engineering activities and to devise lightweight means of capturing salient aspects of this work such that effective analysis and knowledge sharing can be performed. To be clear, CMMI does not require that evidence and artifacts be created or preserved. However, the formal CMMI appraisal method, SCAMPI™, does. Therefore, a means to capture the whiteboarded content will be needed for that purpose only.

Whiteboarding (cont’d)

TS Goals 1 & 2 See Whiteboarding RD, above, and Pairing TS farther above.

Deliberate Refactoring

VER all Goals

Deliberate Refactoring done well includes a means by which expectations are established (e.g., coding standards) and then the product is modified to meet those standards. When done in this way Deliberate Refactoring is a highly effective means of conducting verification. Deliberate Refactoring may or may not be an attribute of peer reviews, but when peer reviews also accomplish refactoring, everyone wins.

RD Goals 2 & 3

Deliberate efforts to refine the product, improve its efficiency, its maintainability, or other attributes as accomplished through refactoring are opportunities to improve the team’s understanding of the product, the customer’s expectations, product performance, and how the product’s operation affects other components and products. This is an example where the agile activity is an opportunity to improve the performance, but where the activity can also be done without ever realizing the benefits of improvement. On the other hand, agile teams often have a propensity to exhibit a strong product orientation that focuses all practices on the creation







of potentially shippable product. This is an unfortunate behavior. Activities such a refactoring (and pairing, for example) can be conducted on—to great benefit—on aspects of the work that are not potentially shippable or even part of the immediate client value stream, but would have a wider organizational benefit.

Deliberate Refactoring (cont’d)

TS all Goals

Deliberate Refactoring is one of the signs of an agile team’s true engineering maturity. Whether it’s viewed as refactoring or not, the act of going back over otherwise “finished” work with the intent to take another look at it or improve something about it is the hallmark of true engineering. This microcosm of “iterative” and “incremental” work is part and parcel of narrowing towards an effective solution from among the wide variety of alternatives, make|by|reuse options, and architectural or infrastructure choices and all of the related rationale and supporting materials.

PI Goal 3 Parts of PI Goal 3 include a number of reviews and evaluations which are excellently accomplished by Deliberate Refactoring as the approach.

Dev/Programming

TDD

VER Goals 1 & 3

By itself, TDD does not perform the improvement practices in VER. However, with a bit of forethought into and standards around how TDD is to be done, developers can prepare for verification as part of sprint planning and tasking and then conduct the verification activities. Once done, developers can compare the results against the preparations.

VAL Goal 2

TDD doesn’t typically get into the analysis of the end-product in the user environment. However in VAL Goal 2 the validation is performed and analyzed against preparations. Tests in TDD can be crafted to also account for some operational environment consideration.

PI Goal 3 PI Goal 3 is similar to VAL Goal 2. To connect TDD to parts of PI Goal 3, developers would need to include tests that address interface compatibility and that builds are not failing or breaking other work.







TDD (cont’d)

TS Goal 2 & 3

Although TDD allows developers to chip-away at the product until a “design emerges”, the actual emergence is of the form of the product, not the design. The design comes first in some capacity. User story acceptance criteria often contain the bulk of the design parameters, limits and constraints. Relying on TDD alone as “design” is highly error-prone and inefficient. It is assumed, here, that users of TDD are fleshing out the details of the acceptance criteria prior to beginning to code the tests or the payloads. Also, allowing a design to emerge is useful when there’s strong emphasis on research that leads into immediate development. Not all development is the immediate outcome of research such that an explicit design phase is reasonable and justified prior to development. This is especially true of more complicated systems.

Pairing

RD Goal 3 When pairs work to translate stories and tasks into product, they frequently reiterate analyses of the requirements.

TS Goal 3 Although Pairing, in and of itself, is not limited to coding, it is most evident when Pairing produces the product.

PI all Goals

It is assumed, here, that Pairing would address a number of conversations that would be had pertaining to bringing the product together. However, it is also strongly recommended that an explicit checklist or set of user stories be created to ensure these topics are covered.

Unit Testing

VER Goals 1 & 3

VER is meant to improve quality of requirements, designs, and tests by removing defects in “thinking” prior to committing to a course of action. Setting-up the unit tests--especially when using automation--can support or be improved with VER Goal 1 with regards to code coverage and scope rationale. VER Goal 3 manifests when looking at the analysis resulting from the tests.

PI all Goals

Since Unit Testing is not limited to any aspect of the product, aspects of integrating the product will take place during development where Unit Testing is going on. The connection here is admittedly weak, but it is possible to exploit unit testing to expose integration issues.







Integration

Tool Set-Up

PI Goal 1 The thinking behind the selection of the release or integration tool and how it’s configured are precisely the sort of thinking that goes into the initial stages of improving how an organization carries out product integration.

VAL Goal 1

Many aspects of improving the effort of performing validation lie in knowing what will be validated and how it will be validated. These considerations rely on the environment in which validation will take place. While not always used in this way, integration tools or release tools can be configured to perform validation. When done so, selection and set-up the respective tools can account for the preparations necessary to improve the validation exercises.

Continuous Integration or Builds

PI Goal 3 Goal 3 of PI is where the product is built and delivered after all “connections” are checked out. In many agile settings, the automation of the integration and builds performs these tasks and reports on the results.

VAL Goal 2

As noted in Tool Set-Up, when used to perform validation activities, the continuous integration or build activities can also provide insight into whether or not the product will work in its intended environment. The key, here, being that included in the continuous integration process performed by the organization are checks as to whether the product will work in the end-users’ environment(s).

CM Goal 3

With a little tool reporting-fu or programming-fu finesse, builds can seamlessly report on whether the as-built version of the product retains the integrity of the baseline. That is, whether the as-built version has everything in it it’s supposed to have and nothing in it it’s not supposed to have. One highly mature team used a “checksum” in their code to perform an automatic audit of their builds. (NOTE: a common misconception around configuration audits is that testing is the functional equivalent of configuration audits. This is a false juxtaposition. Testing typically checks for known functionality and known conditions. Configuration audits check for undesirable insertions or deletions of the product resulting from unwanted existing content or overlooked expected content. I.e., passing all the tests doesn’t mean the product doesn’t also do things you don’t want it to do. )







Regression Tests

CM Goal 3 See Continuous Integration or Builds CM Goal 3.

VAL Goal 2 See Continuous Integration or Builds VAL Goal 2.

Release Management or Staging

PI Goals 1 & 3

Agile teams employing a Release Management Or Staging approach typically have separate environments, systems, or emulations to represent the “production” environment. When looking across the build cycle and architecture at the components of the product and how it all comes together with an eye for how the product will work in the end-users’ environment(s), the CMMI goals listed here are easily covered. When the end-user environment is not accounted for, the VAL goals are scrubbed. VAL both Goals

Stand-ups and other monitoring

Stand-Ups

PMC both Goals

Stand-Ups can clearly cover aspects of PMC. However, the minimalist Scrum style 3-question stand ups tend to cover only a small subset of the scope of the monitoring activities needed to ensure an effort is on track. It is also critical to note that project (work) monitoring takes place in many other ways and not always by people with a broad view of the total effort. CMMI does not imply any limits to where or when PMC activities take place. It is further critical to note that “issues” and “risks” are not synonyms and also that assigning action items and “tracking [them] to closure” are not coincident. Stand-up proponents adhering to a minimalist event will be well-aware of how little resolution is reached during Stand-Ups. Hence, basic Stand-Ups have little room for many of the points needing to be inquired upon in order to ascertain the health of the work.

PPQA both Goals

Basic (minimal) Stand-Ups may not be appropriate events in which to check for whether particular processes, standards, or procedures are working, but with some creativity or minimal additional time some Stand-Ups can be enhanced to also account for inquiring as to the performance of particular processes. One creative approach involves having a “process secretary” observing Stand-Ups with a specific mission to identify process issues arising from the routine reporting process of the Stand-Ups. Also, the paradigm of a Stand-Up can be used to specifically inquire into particular processes,







standards, and procedures—outside of the product-oriented context stand-ups typically take.

Stand-Ups (cont’d)

MA Goal 2

Similar to PPQA, above, collecting or acting on measures during Stand-Ups is not ideal. Nonetheless, in addition to accomplishing more for the work with occasional expanded Stand-Ups there are simple and unobtrusive meta-measures about the Stand-Ups as well as about the work that can be collected by someone attuned to listening for them.

Retrospectives

PMC both Goals

Much of the content Stand-Ups don’t or can’t capture are ideal for being captured in Retrospectives. We are particularly fond of independently facilitated Retrospectives that follow a standardized approach with checklists. When appropriate, we find that having separate Retrospectives specifically to discuss processes works well in settings where the typical Retrospectives are needed exclusively for products. The minimum contents of a retrospective is best when it includes a list of expected outcomes (identified in Release or Iteration Planning) such that in addition to team observations, learning and sharing, the Retrospectives can compare the iteration or release results to the expectations. When combined with milestone “events”, Retrospectives are ideally suited to provide insight into the accomplishments at significant staging points throughout the project.

PPQA both Goals

IPM both Goals

OPF all Goals

Process experiences can be collected and shared during Retrospectives. Process expectations can be distributed during Retrospectives and new ideas promoted emanating from the Retrospectives. An advanced approach for organizations with sufficient need is to have process-focused Retrospectives comprised of internal process representatives who exchange their learning and experience drawing from observations throughout the organization.

MA both Goals Measures can be established as well as collected during Retrospectives.







Demos

Demo Set-Up

VER Goal 1 When preparing for a Demo, establishing exactly what will be demonstrated and the expected outcome is highly suited towards preparing for verification or validation exercises.

When the purpose of the Demo is to ferret-out mistaken assumptions, insufficient analysis or to try out ideas, then VER Goal 1 is typically included. When consideration of the users’ environments is part of the Demo, VAL Goal 1 is also plugged into here.

VAL Goal 1

Demo

RD all Goals When a Demo is to gather information about the client’s needs or to better understand the technical details of the requirements or to test some ideas or assumptions RD goals are typically covered.

VER Goal 3 Assuming that during Demo Set-Up the purpose of the Demo is established to “remove the defects from [our] thinking” then performing the Demo is where this goal is accomplished.

IPM Goal 2

Frequent demos are often the most common (or accessible) means of involving stakeholders. This is only truly useful when the iterations are short and are used to answer questions as much as to actually demonstrate “shippable value”.

PMC both Goals

Depending on the goals and duration of an iteration, demos can be the de-facto event for routine periodic progress reviews. Also, while not using the traditional definition of the term “milestone”, there is nothing in the CMMI practice to explicitly dictate what qualifies as a “milestone”. In that light and depending on what’s accomplished at the demo, there’s nothing to prevent a demo event from also being a milestone review.

agile life cycle cmmi clues - entinex, inc.entinex.com/agilelifecyclecmmiclues.pdf · practices...

Documents