Alpha state and artifacts/work products ​

States of alphas can be identified not by themselves, "theoretically", but by looking at the state of related artifacts/work products. Alphas involve thinking, while work is done on changing work products (including documentation, as well as the realization of the system directly, and also with the support technologies of various practices). Of course, some method of description/viewpoint should be used to describe the state of the alpha for the purpose of coordination of different concerns, that is, a set of different models. The domain meta-model of the project (not our meta-meta-model from the course, it only helps you find these alphas in the project, and the domain meta-model "from the domain textbook" or "domain-meta model" as understood in a specific project situation) and the principles of model creation, methodological instructions for modeling the concern should be used for describing the state of the alpha. Remember that the concern is reflected in its method of description, and the description itself is documented so that the attention of the collective is stably maintained on it regardless of the level of abstraction of the individuals in the collective - this is collective focus. Therefore, in a real situation, the discussion is led not only on alphas but also on the evidence of the states of work products/artifacts (including documents). To discuss the state of a "hammer," you also need to discuss the state and the objects playing its role - the hammer, microscope, stone.

Documentation (primarily computer-based, in the form of some databases, including the use of different modelers) of models/descriptions has advantages over purely oral work "from voice":

• advantages: the possibility of collective and independent verification of models, the ability to remember details long after discussions, modeling only the essentials, etc.
• disadvantages: unnecessary work requiring time - in simple cases and with a small number of project participants, sometimes oral discussions with informal notes are enough, especially if not about major issues (as for checklists), but about various minor details that are immediately taken into account - and they can be forgotten.

Of course, "lightweight methodologies" are preferable, but a lightweight methodology in terms of documentation development should not be reduced to a lack of documentation, to "development by talking."

Each team chooses its level of documenting what is happening in the project, which is also a matter of agreement within the team. Here is an example of the description of the criteria for achieving the state of "acknowledged" alphas of "external project roles" (they can also be called "sub-states"). Indication of description methods for work products allows moving from purely "oral" work to documentation (on paper or computer - it does not matter), which means "defined," "there is an agreement" become documented, the state of the alpha is evidenced in the document, and documentation is carried out in suitable modelers (you should be able to use different modelers for this, understand the principles of modeling, and not get used to one modeler from a specific software vendor. Software here is like a writer's pen: some write better, some worse, but whether what has been written will claim the Nobel Prize in Literature depends not on the pen. The same goes for modeling alphas - the quality of modeling depends least on the modeler):

"External project roles acknowledged"

State achievement criteria (sub-states) Example of work products (documentation views) Example of practices/description methods (viewpoints) All external project roles that are currently or will be affected by the development and operation of the engineering system are defined. "Long list" of external project roles Table in coda.io (less favorable: Excel/Word) with roles and role descriptions (or role descriptions are given somewhere in a separate document, and only the list is compiled).
There is an agreement on the performers of external project roles to be represented. At a minimum, the representatives of the external project roles that finance, use, support, and maintain the system must be taken into account. Team-endorsed "shortlist" of roles to be explicitly represented by some performers of these roles Mark in the "long list" for roles about representation and reference to the existence of an agreement (endorsed protocol, signed order, etc.). It can be in a CRM system, a table of external project roles in notion.so or coda.io, etc. Responsibilities of project role representatives have been defined. Record of responsibilities Typical content of a responsibility record (what decisions the representative of the group of performers of an external project role is authorized to make, how quickly to react, obligations to attend meetings, coordinate documents, etc.), presented in some universal modeler.

Of course, for each project, both the achievement criteria and the forms of documenting their passage are adapted by the team. Methods used in the project for creating and developing the system often determine the methods of describing important objects (practices specify the alphas to be monitored in the course of practice work and explain by what method these alphas are best described).

In project discussions, alphas, functional objects mainly participate, the thinking goes with them. But in projects, we work with constructive objects that reflect/evidence the states of alphas, i.e. with documents and other artifacts/work products. It is easy to discuss the readiness of a document: the beauty of the font, the number of pages or screens, whether there was literary editing, or not. Discussing an alpha requires reviewing the document - whether the document itself is ready or not is not important; what is discussed is what is described in the document: the alpha.

The level of bureaucracy (standardized solutions executed using a standardized set of work products) can and should be chosen depending on the project risk profile. Work products evidencing alpha states (including sub-alphas) of the project can be made simpler or more complex: the methodology should be lightweight, but it should be sufficient to reduce the risk of losing focus on the important in the project, once again read the book "Checklist manifesto" by Atul Gawande.

*Fundamental disciplines, including methodology and the use of a systemic approach, imply written work, thinking is not all in biological heads, it extends "from the head" to the outside world (extended cognition, active/embodied inference)! Moreover, in projects, the thinking of the organization/team/collective/enterprise is important, it requires organization of collective memory, which is done today by computerized modelers, and more and more by versatile spreadsheet modelers!