Agile Principles: Project Management Methodology

 

Agile is based on the premise that the project is implemented by a highly professionally motivated self-organizing team that adopts and understands all the principles of agile development. Otherwise, the focus won't work.

All the basic principles of agile development are outlined in one document, the Manifesto. I've mentioned the specific principles behind Agile's unifying methodologies several times.

The basic Agile Principles are:

1. People and interaction are more important than processes and tools

   The emphasis on people and the relationships between them as the main factor in the success of the project. People manage and apply the processes and tools they need, rather than operating under a pre-accepted regulation. That's why agile techniques involve the selection of motivated professionals with universal skills. Then there is no need to introduce sophisticated methods of rewards and fines, people will be able to substitute each other, participate in the discussion about the product consciously and effectively. Interaction between team members can be built with any handy tools, but no documents, regulations, and instructions.

2. A working product is more important than exhaustive documentation

   To change, adapt, adjust more easily what already exists and works, rather than what is detailed and exhaustively described in the papers. First, you need to do something simple and working, so that then, evaluating and testing done, make adjustments or refuse implemented in favor of another version of execution. But in the end, either the product is and works (although it requires adjustments, additions and refinement), or there is a proven hypothesis, which should be abandoned. Otherwise, in most cases, a project that exactly corresponds to the description on paper, but does not correspond to the market, production, and most importantly the real needs of the client will be implemented.

3. Collaboration with the customer is more important than agreeing the terms of the contract

   In the current reality the customer - and they may be the appropriate unit within the company - can not always clearly articulate the requirements for the product, often he has only the profile of the customer and the problem he faces. The customer can evaluate the product in terms of meeting its expectations, but not formalize them. It is easier to spend time and money on versions of the product than on a comprehensive and exhaustive description, and this description can be more expensive, time-consuming and time consuming than flexible development. The method of optimization in this case will be cooperation with the customer, involving him in the work of the project team.

4. The willingness to change is more important than following the original plan

   This is probably the most controversial postulate. On the one hand, it is easier and easier to change everything in the course of implementation, on the other - the process of such development can be delayed for uncontrolled time and lead to unexpected results.

Key Agile Principles Are:

1. Customer satisfaction through the early and uninterrupted delivery of valuable software.

   This principle applies not only to software. According to this principle, the product should be divided so that at the end of each cycle (sprint the client receives a working version of the product. On the example of a calculator to analyze the project:
   • At the end of the first sprint, NPV is calculated in Microsoft Excel - all the major formulas work, there are no errors, only the final figure - calculated NPV;
   • At the end of the second sprint, NPV is calculated as the first sprint, but functionality is added - a comment on the value received, an IRR calculation and other criteria - for a fuller picture;
   • At the end of the third sprint, based on the logic and formulas developed in the first two sprints, the texts, checked and agreed with the customers, are prepared by a desktop version of the product;
   • At the end of the fourth sprint, a mobile version of the product is being prepared and... Voila! The product is ready for use for customer tasks.

2. Changes in requirements are welcome.

   Product development is underway in a fast-changing competitive environment, where the market may already change at the end of the development cycle, such as an analogue. Then, in order not to throw in the trash implemented project, it is refined, by the way, you can use the experience of a competitor who has already entered the market. Therefore, in a flexible approach, changing product requirements, even at the end of development, is acceptable and welcome.

3. Frequent delivery of a working software product.

   The importance of this principle is all the same - the world changes rapidly and the shorter the delivery cycle, the more accurate the final product will meet expectations.

4. Immersing the customer in the work on the project throughout its implementation.

   The customer in this case is the only member of the team, the carrier of knowledge, "as it should be", respectively, his conclusion about the product's compliance with expectations and its satisfaction from the result - a key criterion. The more often the customer's expectations are compared with the work of the project team, the more, of course, the higher the compliance with expectations and results.

5. The project is carried out by motivated individuals who are provided with appropriate working conditions, support and trust.

   This principle of motivation problems are taken beyond the work on the project. It is assumed that at the stage of team formation, it is necessary to select only motivated professionals, self-sufficient personalities, who do not need to be customized, persuaded, etc.

6. The recommended method of communication is face-to-face.

   This is a controversial principle in the digital age, when many companies develop network interaction and implement remote work into their processes. At the same time, personal interaction has a number of advantages that other types of communication do not have: for example, the speed of solving issues, non-verbal signals (emotions, gestures), motivation (you can praise, highlight, put "in place"). In any case, the manifesto emphasizes this and declares it as one of the key principles.

7. Running software is the best measure of progress.

   Transferring this principle to a more general system of coordinates, the working version of the product is the best criterion for the success and progress of the project. In a large number of cases, this principle is implemented and understandable, and where Agile does not apply.

8. Developers, as well as their curator and customer should be ready to maintain a set pace in development for a certain (read - unlimited) time.

   It should be understood that in such a paradigm the deadline for the development of the final version of the product is not known, moreover, the final version may not be, which we see on the example of constantly polished and refined versions of desktop software and mobile applications.

9. The cornerstone of Agile development is the commitment to technical excellence and quality of sprint planning.

   This principle is designed to balance the possible negative effect on the quality of development from other principles, such as the frequent delivery of a working product. You can use different methods to make frequent deliveries in the absence or lack of product specifications, for example, to use ready-made but substandard code developed by "Indian programmers" and neglect testing. Personal qualities, professionalism of developers and collective responsibility - laid down in principle "aspirations for technical perfection" require a higher level of responsibility.

10. Simplicity and minimizing unnecessary work.

    This principle should be applied in all projects, but as a key principle it is laid down only in Agile methods. Priority is given to what is done quickly with minimal cost. We refuse unnecessary work both in the processes and in relation to the product, for example, a consulting company usually prepares a multi-page presentation on the completed works and expected steps, but if the client is integrated into the team, then he does not need formal paper, he is more important what is already going into the work - the same two or three slides that are already ready for the final presentation. In terms of product - you can strive to implement all the ideas regarding functionality immediately before the first release, but no one does so, in each iteration the product improves in accordance with the requirements of the market, which can mean both the addition of new functionality, and the removal of some features, not "accepted" by customers.

11. The best requirements, architectural and technical solutions are born to self-organizing teams.

    This is not about anarchy, but about high internal discipline in the team, a clear distribution of roles and a high level of professionalism of each participant. If you can't organize your self- don't work in the Agile concept.

12. The team should systematically analyze possible ways to improve efficiency and adjust the way it works accordingly.

    This principle emphasizes that the full responsibility for the project and its product lies with all members of the team, no one from the outside makes adjustments and does not analyze the effectiveness - all members do within their team in the interests of the project and the result.