AGILE DEVELOPMENT — The Agile Alliance

The Agile Alliance

Motivated by the software teams of many companies that were stuck in the growing process, a group of industry experts, self-styled Aliança Agile, met in early 2001 to outline the values and principles that would allow software teams to develop quickly and respond to change. In the following months, this group worked to create a statement of values. The result was the Agile Alliance Manifest.

Manifest for Agile Software Development

📌 Individuals and interactions more than processes and tools
📌 Working software more than comprehensive documentation
📌 Customer collaboration more than contract negotiation
📌 Responding to change rather than following a plan

🧑‍🤝‍🧑Individuals and interactions more than processes and tools

The right tools can be very important for success. Compilers, (IDEs) etc. — all are essential for the correct functioning of a team of developers. However, tools can be overvalued. The excess of huge, difficult-to-handle tools is just as bad as the lack of tools.

Remember that building the team is more important than building the environment.
Many teams and managers make the mistake of building the environment first and expecting
the team automatically understands itself well. Instead, work to create the team and then let it set up the environment as needed.

🚧 Working software more than comprehensive documentation

Undocumented software is a disaster. The code is not the ideal way to communicate the structure of a system. Instead, the team needs to produce easy-to-read documents that describe the system and the logical thinking of the project.

The two best documents for transferring information to new members are the code and the team. The code doesn’t lie about what it does. It can be difficult to extract the rationale and purpose of the code, but it is the only source of clear information. The team has in its members’ minds the ever-changing map of the system.

Many teams have been concerned with seeking documentation instead of software.

Martin’s First Documentation Law
Do not produce any documents, unless your need is immediate and meaningful

🧠 Customer collaboration

Successful projects involve regular and frequent customer feedback.
Instead of relying on a contract or a service breakdown, the customer
software works closely with the development team, giving frequent feedback on their efforts.

Work close to the client deliver a version every week ask for validation … Be close and this way it will be easier to deliver a project

📑 Responding to change rather than following a plan

The ability to respond to change often determines the success or failure of a software project. When creating plans, we need to ensure that they are flexible and ready to adapt to changing business and technology.
The development of a software project cannot be planned far in advance. First, the business environment is likely to change, causing requirements to change. Second, when customers see the system start up, it is likely that
also change the requirements. Finally, even if we know what the requirements are and are sure they will not change, we are not very good at estimating how long it will take to develop them.

A planning strategy is to make detailed plans for the following week, approximate plans for the next three months, and extremely rudimentary plans beyond that.