What exactly is Agile? How did it all start? What are the features of this method of operation? How is it different from traditional methods? How to efficiently (agile) run a project? We provide a set of information that everyone related to technology should know. We hope you find them valuable and worth recommending.
Everyone has heard about Agile and its project management methods. But do you all know the story behind the principles behind it? Probably not, which is why we will describe it all briefly for you.
Behind the creation of the idea of “agile” in 2001 is a group of programmers that met at a ski resort in the mountains of Utah. In addition to entertainment and time well spent, their goal was to discuss how to change the approach to the software development process.
This demand was determined by the fact that the company found it difficult to get along with specialists writing code; Application development time was getting longer, technological changes were taking place very quickly, frustration increased and projects often failed.
As a result, solutions were provided that were already outdated compared to competitors’ products. In this situation, it was necessary to find a way to create software with many variables to be able to bring applications to market faster.
The problem turned out to be a wrong approach to the project itself, so the changes had to be started “from scratch”, that is already at the stage of work planning. So far, software development has been written; A work schedule was established in advance, which divided the project into successive stages. Without the implementation of one – it was impossible to move on to the next.
At this stage, all costs were estimated and a specific budget allocated to be used. The customer was obliged to communicate all requirements.
This approach (called Waterfall) simply did not work for projects with many unpredictable variables.
In February 2001. the way development teams work was changed. Stormy talks of 17 programmers led to an agreement. As a result, a list of 12 principles and the general idea of an agile approach to running programming projects was created, called Manifesto for Agile Software Development.
20 years have passed and during this time the idea has been successfully implemented in many companies, facilitating the implementation of all projects.
New vs Old
The new approach differed from the “traditional” approach, mainly in that it allows working in a distributed operation model. Planning and implementation of requirements are carried out by small, relatively independent teams – thanks to this, there is a possibility of faster commissioning of part of the application, which is systematically tested and improved. It can also be expanded with other fragments.
Due to all this, the time from collecting the requirements to launching the product on the market has been significantly shortened, although it does not mean the end of the project.
All activities are carried out non-linearly, which gives more freedom to development teams. They work in accordance with cycles (sprints) focused on delivering the next part of the application.
An important change from the cascade approach is that the owner can decide the direction of development during the course of the work, based on observing progress and in accordance with factors that come / change over time.
Planned activities are prioritized so that the team knows which of them are the most important and the first to be carried out.
12 principles of the Agile methodology
As we have already mentioned, the authors of this methodology distinguished 12 main principles that are intended to define the basic assumptions of this way of working.
1. The most important thing is customer satisfaction, who receives the quick implementation of systematically improved software – an agile approach goes hand in hand with providing high-quality services while meeting customer requirements. The change was aimed at better communication with the client, efficient cooperation and clearer communication, and above all, a faster opportunity to show the effects of work.
2. Be open to change, even late in the project – the technology industry is changing dynamically, so it is essential to be up-to-date with market requirements. Another issue is the fact that the client is able to clarify expectations only after seeing the first effects, which is why the agile methodology was created in opposition to the rigid framework of the waterfall approach.
3. Systematically deliver subsequent parts of the system; the more you do it, the better – thanks to this, the client can quickly provide comments that will be used to improve the application and streamline work on the project.
4. Business and development teams need to work together – it is not about occasional contact, but about regular, close cooperation. Thanks to this, each party is involved in the project and knows about current activities. Divisions between teams should be abolished, as they block the creative cooperation of specialists from various fields.
5. Create projects around motivated individuals. Support them, trust them and provide what they need to accomplish the project – a long-lasting and labor-intensive project needs a committed manager, so if someone does not “feel” the project, they may be able to run it correctly, but they will not fully use the capabilities and potential of the team.
6. The best way to communicate information is face-to-face – it is difficult to disagree with this principle. E-mails and other messaging services are probably a great convenience, but personal contact always leaves the best impression and is the most fruitful.
7. Working software is the basic measure of work progres – not the process itself, but the results always determine the results. The agile methodology is distinguished by a flexible approach, but also puts a lot of emphasis on the implementation of tasks.
8. Agile processes support balanced, sustainable development. Sponsors, developers and users should build up a steady pace – this principle determines the involvement of the teams in the project. It is not recommended to change the responsibilities of individuals or sub-teams, as it disorganizes and slows down progress.
9. The constant focus on technical excellence and good design enhances agility – agile methodology puts a strong emphasis on the development of the team working on the project. It requires commitment, searching for new methods of solving problems and improving the software.
10. Simplicity is the art of minimizing the work required – solutions should not be complicated or combined where it is not necessary. The functionality is supposed to work – the easier it is to implement it, the better, faster and more efficiently.
11. The best solutions come from self-organizing teams – this principle emphasizes the way of communication with the teams responsible for the individual elements. Teams are to be involved in their tasks and look for solutions on their own. The project manager watches over the whole, but does not impose on the teams how to work.
12. Thanks to regular work, the team is constantly developing, becoming more effective, and adapting to changing requirements; draws conclusions accordingly changes its approach – development, development, development! 😊
Advantages of running agile projects
One of the biggest changes forced by agile methodologies is blurring the divisions between business and IT teams. Divisions into Business, IT, etc. They lose their relevance. Instead, self-organizing teams are formed that focus on the development of a given product.
This approach facilitates project development planning, enables greater specialization in the context of the product being developed, and facilitates communication.
Agile methodologies focus on “communication over documentation”. This does not mean abandoning product documentation, but the emphasis is on understanding the needs and requirements.
This allows problems to be identified faster before becoming difficult to fix. In addition, the frequency of sprints, after which the delivered solution is presented and discussed, allows the team to receive feedback faster. This further reduces the risk of critical problems.
The limited number of meetings, additionally with imposed time constraints, means that specialists do not waste time on meetings, from which they will get nothing and “should be by e-mail”. The repetition of meetings allows the team members to plan their time better.
The advantages already mentioned include commitment, flexibility and continuous development.
Disadvantages of the agile methodology
Agile advocates may disagree, but SCRUM is not always a good choice. There are several factors that determine the mismatch between the methodology and the project.
- Projects with rigidly defined requirements and a completion date. In such a situation, we can lose the main advantage which is flexibility and the possibility of change. Secondly, we need to define the resources required to complete the project – and this requires planning from scratch.
- Developing a product that has many dependencies on ‘not agile’ products or parts of the organization.
The disadvantages include the variability of teams. To maintain the effectiveness of the team’s work, its relative invariability is important. This is due to the fact that team members who have been in the team for a long time remember the problems the team struggled with and what actions were taken to solve them. Each change in the team also affects its ‘speed’, which makes planning difficult.
Just as increased accountability and commitment was listed as one of the advantages – for some types it will be a disadvantage. For a team to work effectively, all team members must be involved. It is possible that finding such people will turn out to be difficult, as this is not an easily verifiable feature, but it is worth taking the time to find people devoted to the project, because mismatched team members slow down and reduce work efficiency.
Looking at the above description, it can be concluded that Agile has more advantages than disadvantages. However, it should be remembered that you always need to look at the wider context, limitations and dependencies that occur in the organization.