Agile methodologies or Agile Management in Project Management come from frameworks of work used in the development and management of software products. However, the agile management can be extrapolated to other contexts. The agile methodologies approach in Project Management allows solving problems and contributes to the generation of a satisfactory solution for the client. This agile management is based on a fast and fluid development process, also known as adaptive life cycle.
Origin of the Agile Theory
The sector in which Agile theories begin to develop is that of software development. At the beginning of the 21st century, this industry is considering the possibility of starting to work with its own methods, which adapt to the innovative character of its business model.
In the year 1999 Kent Beck publishes a book that will change the methods of organization at work forever. It is about “Extreme programming explained, accepting the change”. In this book Beck establishes the bases of what will be the Agility with concepts such as delivery of continuous value, permanent adaptation or Agile working methods.
Two years later, in 2001, Beck himself summons another 16 analysts in Snowbird, Utah. The aim was to improve software processes and refute the principles of formal methods, unable to provide solutions to the software sector.
The result was the principles of the Agile Manifesto, which would give rise to the formal concept of Agility and the multiple methodologies that are based on the precepts of Beck.
Principles of the agile manifesto for Project Management
The following are the 12 principles of the Agile Manifesto:
1. The main priority is to satisfy the customer through the early and continuous delivery of valuable software.
The objective is to achieve a satisfied customer, which will contribute to our having more clients in the future. But how? Providing customers with the solution they really want, although we already know that this is not possible without being adaptive, and without early and continuous deliveries of software running. This necessary flexibility, although possible in predictive life cycles, is too expensive
2. We accept that the requirements change, even in late stages of development.
The change provides a competitive advantage to the client. Employing an adaptive life cycle we are open to change since there is no initial design that we should stick to each time we want to make a change. In addition, any change request will make us happy, because it will be another step that will allow us to get closer to what the client really wants.
3. We deliver functional software frequently in the shortest possible time period.
The client will have a better understanding of what he wants when he sees the software running. We will receive information (feedback) that we can use to adapt it. There are different Agile frames that use different iterations. For example, iterations of more than one month are not allowed in Scrum, while other Agile frames accept longer iterations. As long as they are enough to create a significant increase (software running) we prefer shorter iterations.
4. The people in charge of the business and the developers work together on a daily basis.
In a predictive environment the participation of the company / client is generally limited to specifying the requirements at the beginning, and again in the end to approve the final solution. However, in an adaptable environment we need the company / client to work daily with the developers, since their inputs are the source of adaptability.
5. Projects are developed by motivated individuals in an appropriate environment.
An agile environment is based on a multifunctional and self-organized team that self-manages and finds its way instead of receiving orders. This is a big responsibility for developers, and not everyone is able to work this way.
When we have the right team members, we must trust them, motivate them and give them the possibility to allow agility.
6. The most effective method of communicating information is face-to-face conversation.
In a traditional environment team members focus on their specialist activities, they may even be located in different places, usually in their respective departments within the organization.
Sometimes we cannot even call them “equipment”; They are just a series of people working on the same project. On the contrary, in an Agile environment we need a real team, in which the members must be co-located in order to be able to communicate continuously. Nothing can replace a face-to-face conversation.
Although it is certainly a great advantage to have co-located equipment, this does not mean that we cannot have an Agile project with a “distributed” team. In these cases, however, we will need to take full advantage of the technology to minimize the lack of face-to-face communication, and assume a lower level of productivity at the end of the day.
7. The software in operation is the main measure of progress.
A 99% finished product is a product that is 0% “complete” or “made”!
But then, how to know the progress of our work without going into technical details? Remember that we are interested in keeping the client involved in the project, and for this we must try to avoid technical details, and maintain a simple language, given that in many cases it will be a “non-technical” client.
The solution is to differentiate the items in the Product Backlog only in two categories: “complete” and “not complete”. This simple distinction is sufficient since the elements of the Backlog are small enough to show our progress simply by differentiating between complete / not complete.
8. Agile processes promote sustained development, a constant rhythm must be maintained indefinitely.
Work is not the goal; reaching the product is the goal.
It might seem that working overtime can speed things up, but it actually reduces outputs by decreasing productivity and increasing defects. It is preferable to maintain a sustained rhythm over time.
9. Continuous attention to technical excellence and good design improves Agility.
Not having an initial design does not mean that we do not have to be worried about the design.
Agile projects have design, what happens is that this is done in each iteration for each element of the Product Backlog.
We must pay attention to technical excellence and good design to avoid problems; without forgetting that the objective is to find a solution “good enough” rather than the perfect solution.
10. Simplicity is essential.
An Agile project is managed and delivered in a simple way.
For example, scope management is done simply by detailing the essential information on a card or sticky note (card); sophisticated instruments are not necessary to manage the product. In addition, doing it in a simple way favors the collaboration of the client.
11. Self-organized teams generate better architectures, requirements and designs.
Usually people work better when they feel respected and are authorized to decide how to function.
In addition, it is best that all team members be responsible for the entire project. For example, if the designers do not work in isolation, then they will be constantly in contact with the programmers, and they can use the information generated to improve the designs and make them more practical.
12. The team has to reflect on how to be more effective in adjusting their behavior and work.
There is always room for improvement, no matter how well the work is done.
Therefore, we need time to investigate the previous iteration and find ways to implement improvements, however small they may be. The goal is to improve a little each iteration.
The values of the Agile manifesto
In addition to these twelve principles, fundamental to implement any Agility process, 4 values were also developed that should govern any Agile process.
- It will be necessary to value people and their interactions more than tools and processes.
- It brings more value to the software in operation than the exhaustive documentation
- One of the main values will be the relationship with the client, which will be more important than any clause reflected in the contract
- It is necessary to adapt to different circumstances rather than follow a rigid plan.
If you know and work based on these principles and values you will be developing the full potential of Agility.