Agile flexible development manifesto from the customer’s point of view

DOI: 10.31673/2412-9070.2024.020308

Abstract

Manifesto for Agile Software Development is written from the developer’s point of view. In this article it is offered to consider the manifesto from the point of view of the customer. Having elaborated the main ideas and principles of the Agile Manifesto, conclusions are made to each idea and to each principle, they are generalized and presented.
Important on the customer’s side are:
In the field of training: to train specialists in the field of customer service, software development, testing and measurement of progress, technical excellence and product design analysis, teamwork, quality of product documentation, quality cooperation, preparation of contractual obligations and negotiations on them, testing of the prototype.
In the field of interaction: to improve the quality of interaction by creating and promoting the improvement of the interaction environment, to promote the creation of comfortable working conditions, including in the form of personal conversations (face to face), the adoption of elements of documentation, product acceptance; give preference to individuals and their interaction with the developer’s personalities than to development processes and development tools;
In the field of resource allocation: it is necessary to allocate appropriate resources (time, human, financial and others); have the appropriate resources to adapt to changing circumstances, to respond to changes, to accept elements of documentation, to pilot operation and risks.
In the field of product development: generate and discuss product comments and proposals at all stages of product development, even at the end of development. Be prepared for the fact that the concept of the product being developed may change; creation of a system for processing the reports of its representatives and timely response to the appearance of relevant information; create a clear feedback tracking and response system in which the main scale for measuring progress is the working product; clearly understand and possibly record in documents that are a working product; monitor the product development process and influence the maintenance of a constant pace with a clear understanding of what is created, what is planned to be created, whether there are enough resources to maintain a constant pace of work; identify gaps in their work that can lead to delays and deviations from the work schedule (volume of work performed); make requirements that improve the technical perfection of the product, the convenience of product design and the changes in the product that need to be made; to promote a modular approach to the creation of architecture, with the reuse of modules later in the project, which in turn will increase the speed of product creation and promote the concentration of resources and efforts in other important areas; rank the requirements in such a way as to quickly obtain from the developer simple solutions that would bring some benefits and that could be the basis for further work; have the appropriate resources and documents to carry out the process of determining whether the working software meets the relevant requirements; prefer working software to the adoption of complete documentation; have contractual obligations, but with limited resources and minor damage to the customer as a result of poor performance by the developer of its contractual obligations, to prefer cooperation with the developer than to discuss contractual obligations; have a plan and follow the plan. Be prepared that the plan may not be implemented on time due to proposals and their implementation; make informed decisions and try to prioritize change over adherence to plans;
In the field of experimental operation: determine in advance the requirements for the product by rating (what is needed first, second, etc.); be prepared to receive an early, unprocessed product or part of the product and install it for trial operation. Not all tools should be used to work with the prototype, but only the part that will be sufficient to test the sample and make suggestions. Consider the possibility of implementing a pilot project at one of the sites; think about questions about actions (possibly temporary withdrawal from the use of the product) in case of problems in the unfinished sample; be prepared to assess both the positive and negative effects of experimental operation; have a clear system of measurements; make changes to the customer’s business rules to avoid malfunctions when receiving a new version of the working product. Given that new functionality can be added with each new version, this can lead to more and more employees involved in trial operation. Restrictions on obtaining new versions of the product may lead to delays in project implementation; make changes to the business rules to cover the entire test product as quickly as possible and provide product feedback.
In the field of motivation of specialists: understand the importance of appropriate payment for the activities of the developer and to promote the motivation of the customer’s personalities involved in the project; at the end of the project to be ready for the transfer of the most qualified representatives of the customer to other customers, or to developers to participate as business analysts in future projects;
In the field of risk processing: be interested to some extent in the internal problems of the developer and contribute to their solution so that it does not interfere with the success of the project; get acquainted with the process of self-organization of the development team; help your team and the development team understand what it takes to become more effective and adjust their behavior.

Keywords: manifesto of flexible agile development; software development; the customer of software product development; software product developer; testing; experimental operation.