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).
Contents
The Framework vs others
Similarities
Dissimilarities
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.
- 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.
- From the second week to the penultimate week, they facilitate the project work in accordance with the What Coords do section.
- 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:
- D for "discover the need".
- R for "research the background".
- E for "envision the deliverable".
- P for "plan the production".
- 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 results
- Project results or results of the projects may be classified in four levels:
- 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.
- 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.
- 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.
- 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.
Work products
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.
States of work products
- Main wikipage: Work-product state
