CNM Agile

CNM Agile (hereinafter, the Framework) is a product development framework that represents an adaption of the Agile methodology to the learning and testing needs of the CNM Cyber Team (hereinafter, the Team).

Comparisons with other frameworks

In comparison with Agile Scrum, the Framework emphasizes weekly, not daily meetings and allows for virtual, not only physical co-working. In comparison with The Manifesto for Agile Software Development, the Framework values comprehensive documentation over working products.

Projects

Generally speaking, a project is a development Endeavor or a set of enterprise efforts undertaken to produce a unique deliverable, functional features of which are identified or can be identified before the efforts start. Those deliverables are those new and modified products that are produced during those developments. Indeed, the aim of Cyber's developments is to produce new or modify existing CNM Cyber products. At the Cyber, former and current projects are listed in the "CNM Cyber endeavors" category.

Cycles of cycles

To coordinate endeavors, the Coords shall accomplish cycles of efforts that consists of several steps. Similar procedures are normally needed to produce project scraps and by-products. That means that the Coords are expected to follow the same cycle to create What Coords produce.

Furthermore, the most of projects may be viewed as sets of smaller developments. Among the Coords' outputs, Meetings, Documents, and Communications usually belong to project scraps. Indeed, Project results and results of the Coords' work are different phenomena.

Project deliverables normally utilize outputs from other projects as its scrap. A CNM app development, for example, requires documents that describe its requirements, and drawing up those requirements requires meeting events. If we consider the Coords' work as micro-projects, we can say that outputs of micro-projects tend to become scraps for small projects and, furthermore, outputs of small projects tend to become scraps for macro-projects.

Deliverables vs by-products

Those project outputs that are not Project deliverables may be called project by-products. Their range is huge; there are some imaginary scenarios:

• A contractor submitted more products than the contract had required. If they are further deployed, those additional products would be by-products of this project.
• Contractor's performance demonstrated advanced competencies in something unrelated to the project. The updated records are by-products of this project.
• While organizing a meeting, the Coord encountered the problem of the policy's incompleteness. CNM Cyber Customer agreed to fund the policy's updates. The updated policy is a by-product of the project

Durations

The Coords work on one project, usually up to three and, in exceptional cases, up to five weeks.

1. In the first week, they shall get familiarized with the project. At the end of the familiarization, the Coord should be able to explain what is described on the relevant wikipages and be ready to discuss its Sprint Zero with CNM Cyber Customer.
2. From the second week to the penultimate week, they facilitate the project work in accordance with the What Coords do section.
3. In the final week, they close the project or project part, documenting their work and the data that was uncovered during that work.

Projects can overlap. For example, the last week of work on one project may be the first week of work on another project. For senior Coords, there are no restrictions.

Patterns

Although no single straightforward pattern of project advancement exists, some patterns can be found in various developments. As an example, letters in the DREPD pattern represent five phrases:

1. D for "discover the need".
2. R for "research the background".
3. E for "envision the deliverable".
4. P for "plan the production".
5. D for "do what is planned and discover what hasn't been expected". This discovery is supposed to start a new cycle; new data shall emerge while doing and/or after getting something done.

This pattern can be found in the whole development, in every group of processes, every process and every part of processes where ever anything new is or is going to be developed.

Project deliverables

Projects are undertaken to create project deliverables. CNM Cyber Customer funds projects in order to get something in return. Normally, customers fund projects because of its expected deliverables. Any project is expected to deliver some outputs. In other words, project deliverables are those products for which development the project exists.

For instance, when a contractor is hired to produce a particular thing, that very thing should be the deliverable of that project. Literally, the contractor is expected to deliver the deliverable to complete the project.

At the Cyber, former, current, and expected deliverables are listed in the "CNM Cyber products" category. Project deliverables exist in various Product states and belong to various Product areas. In addition, one project rarely produces one single deliverable. For instance, the HAProxy for CNM Farms project is expected to deliver high-availability capabilities for CNM Campus Farm and Campus Farm Lab, as well as related presentations on various media resources, updates to the CNM Cyber Orientation course, and a bundle of exercises for the learners.

Finally, project deliverables and Coords' deliverables are not the same things. Any development can be represented as Cycles of cycles. Just few Coords' deliverables, for instance, records, become a part of project deliverables. Normally, the Coords deliver to the project something like Meetings, Documents, Records, and Communications to be consumed in the project activities as project scraps.

Project results

Project results or results of the projects may be classified in four levels:

1. Project scraps, which are intermediate products that either become parts of the CNM Cyber products or have been decommissioned before the end of the project. Nevertheless, the outputs cannot be produced without those scraps. As they say, sausage making is messy, but no sausage can be produced without that mess.
2. Project outputs are the things that are produced during the project and kept after its end. Besides the Project deliverables, the outputs may include other-than-the-project Records such as publications and Documents such as blueprints that have been developed and commissioned in order to produce the Project deliverables.
3. Project outcomes. On the Coord's side, the outcomes are those KSAs that the Coord has obtained during the project coordination. On the other stakeholders' side, the outcomes are something for which the Project deliverables have been produced.
4. Project impacts, which are consequences of the project, its outputs and outcomes on a society. Beyond the Coord's work, some projects, for instance, may initiate further meetings, documents, actions, and changes.

Status reports

While working on the deliverable, the Coords are expected to report their project status. In CNM Agile framework, these statuses are reported at the product line wikipage, CNM Cloud Usable, using the following readiness levels for each Product state and Device of certainty:

• Not started. Project work on the corresponding Product state and Device of certainty hasn't started yet.
• In progress. Project work on the corresponding Product state and Device of certainty has been started, but the state/device has not yet been submitted for the approval.
• Cancel. Project work on the corresponding Product state and Device of certainty has been cancelled.
• Submitted. Project work on the corresponding Product state and Device of certainty has been submitted for the approval.
• Done. Project work on the corresponding Product state and Device of certainty has been approved. With exceptions of the state of certainty, CNM Cyber Customer approves the status. With regard to the state of certainty, its approval also requires the developer's consent.

Product states

For the purposes of this very wikipage, product states refer to sets of conditions that Cyber products acquire during their development and service. The Coords work to bring the products into one or more of their states.

State definitions

1. State of acknowledgment. In this state, the future deliverable exists in the form of a noticed and documented idea.
2. State of certainty. In this state, the future deliverable exists as a validated product specification.
3. State of capability. In this state, the functional deliverable has already been produced in accordance with all the requirements that have been approved for it.
4. State of applicability. In this state, the deliverable is not only functional, but can also be used for the purpose for which it was produced in ways that are described by a validated standing operational procedure (SOP).
5. State of manageability. In this state, the deliverable is not only used for the purpose for which it was produced, but also controlled, that is, the product undergoes periodic revisions and is either improved and its characteristics are improved, or withdrawn from service.

Hierarchy

In practice, product states do not always represent a hierarchy of five levels, in which the higher level includes the states of the lower levels. However, the Coords should strive for this ideal, for example, it is impossible to fully talk about applicability without capacity, manageability without certainty, and so on.

Thresholds

Product state	Threshold
State of acknowledgment	A record is added to the idea management system.
State of certainty	A product specification is approved.
State of capability	Acceptance criteria are met.
State of applicability	A standing operational procedure (SOP) is approved.
State of manageability	Periodic reviews find that standing operational procedures (SOPs) are both sound and followed.

Devices of certainty

For the purposes of this very wikipage, a device of certainty refers to an instrument or tool that ensures:

• Product certainty, which their development shall deliver. When CNM Cyber Customer agrees, products shall not necessarily possess their state of certainty for the beginning of their development, but this state shall be achieved during that development.
• Project certainty, which suggests the scope of product development. Project certainty cannot be reached unless product certainty is reached. Clearly, no one can know what to do unless they know what needs to be done. The scope of work depends on the scope of work product. Moreover, the overwhelming majority of Cyber projects cannot be fully predicted and, therefore, achieve their complete certainty only with their closure.

General certainty

For the purposes of this very wikipage, a general certainty refers to those devices that may combine product and project certainties.

1. Business requirements. Description of the needs for which the development of the deliverable is undertaken.
2. Demands of Team funded by Customer. Description of what CNM Cyber Team needs and, possibly, when and how it needs expressed when CNM Cyber Customer has funded satisfaction of those needs. Those demands are expressed in either acceptance criteria or standing operating procedure (SOP).
3. Stakeholder requirements. Description of the future deliverable made on behalf of various types of its stakeholders.

Product only certainty

A few devices ensure certainty of product deliverables:

1. Product depictions. Representation in images, layouts, mockup models, outlines, prototypes, sketches, wireframes, and/or words of a deliverable to be created. Prototypes (from the Greek "prōtos" meaning "first", "original" and "typos" meaning "imprint", "pattern"). Instances, samples or models, following the example of which others are made or finalized. Prototypes of the deliverable are often built to test a perception, concept, or process. Prototypes can either be selected from existing products or produced during a project.
2. Product specifications. Set of tasks for developers of a deliverable regarding its required characteristics.

Business requirements, stakeholder requirements, and acceptance criteria clarify product scopes, but may also clarify scopes of their production, delivery, and/or other elements of project scopes.

Project only certainty

Project scopes depend on their product scopes, so any project document can get some glimpse into its product certainty. A few devices ensure certainty of project processes and product delivery:

1. Project scope baseline. The combination of project work requirements that CNM Cyber Customer has approved and that are used as the base to compare with actual results. For complex projects, the baseline normally includes a project scope statement, work breakdown structure (WBS), and WBS dictionary.
   • Project scope statement. General description of the project work and its desired results, as well as assumptions, constraints and other project requirements.
   • Work breakdown structure (WBS). Hierarchical decomposition of the complete project work.
   • WBS dictionary. Detailed deliverable, activity, and scheduling data for each component in the work breakdown structure (WBS).
2. Project schedule baseline. The combination of project schedule requirements that CNM Cyber Customer has approved and that are used as the base to compare with actual results.
3. Project cost baseline. The combination of project cost requirements that CNM Cyber Customer has approved and that are used as the base to compare with actual results.

Business requirements, stakeholder requirements, and acceptance criteria may or may not clarify project scopes in addition to clarifications of product scopes.

See also

Related lectures

• What CNM Agile Is.