Project management apps offer a number of functions bundled together into a single platform and have revolutionized the workplace. When used correctly and embraced by the employees, such an app can help organize all kinds of tasks with a very high degree of efficiency. Small and medium-sized teams, as well as large operations, stand to benefit from the right app. These days, there is a large...The best project management apps
Agile software development has been around for a long time now and agile methods have also long been established in other areas of work. For many, however, the term is still not quite clear. When do you start to act according to agile aspects in your company? And what is actually just traditional work that is mistakenly upgraded with a buzzword?
As early as the 1990s, teams of software developers began to work with methods that can now be considered agile software development. Until the end of the 20th century, various software developers and teams did a lot to make programming more lightweight, and so the method became known mainly under the keyword "lightweight." During this time, the Scrum method and Kanban were developed, which could not be summarized at that time under the term "agile product development," because this expression did not exist yet.
Finally in 2001 a clear break took place: In the meeting known today as the Snowbird Meeting (after the name of the ski resort in Utah where the meeting took place), 17 developers created the Agile Manifesto. Bringing together their respective experiences in software development and teamwork, they found solutions, established principles, and summarized everything under the term that today is synonymous with a modern way of working: agile software development.
What is agile software development?
When they first started to question the methods of software development on a small scale and finally tried to establish a new kind of project work with the Agile Manifesto, the group always had the goal of being able to act more flexibly, creatively, and productively. Instead of following a thoroughly planned, linear, and bureaucratic process, as with traditional methods – e.g. the waterfall model – the project is started. For this, agile software development assigns much more responsibility to the team of programmers.
In addition, one more or less says goodbye to huge projects: Instead of spending months or even years manufacturing a product, agile teams spend only a few weeks in a work phase. The result is a finished product, an update, or a program part that can be presented to the customer. For this to succeed, twelve principles and four values have been agreed upon in the Agile Manifesto.
Agile software development is primarily a collective term. It summarizes various agile methods, each of which provides more detailed instructions for the workflow.
The values of agile software development set the focus that teams should always keep in mind during development work. They are noted as pairs of opposites; both aspects are important, but one is overridden by the other in agile development:
- Individuals and interactions over processes and tools: The people involved and their cooperation with each other are more important than the question of a specific process or tool.
- Working software over comprehensive documentation: The focus is on a functioning end product. The documentation of the work, however, is of secondary importance.
- Customer collaboration over contract negotiation: Agile product development is more concerned with meeting the customer and his requirements than with conducting contract negotiations.
- Responding to change over following a plan: It is assumed that software development must respond to constant changes. It may be necessary to overturn a previously defined plan.
These values are like a mantra to be interpreted. They don't provide precise guidance, but are there to remind developers of the key important aspects of production: work in a team; focus on the software; think of the customer; be flexible towards change! All other facets, while they may be equally important, should be part of these points.
More in the direction of concrete instructions are the twelve principles of the Agile Manifesto. These provide additional information and expand on the values. But even here it is not an actual instruction – instructions are not what the Manifesto wants to provide. The principles are broad and serve to distinguish agile from non-agile methods.
Customer satisfaction: By early and continuous publication – in the sense of continuous delivery – the customer should be satisfied at any time.
- Flexibility: Agile teams always evaluate changes as something positive, even if they appear late in the development process. If one follows the Agile Manifesto, adaptations to changed requirements give the customer a competitive advantage.
- Delivery: Functional software is delivered directly within a timeframe of a few weeks or months. A shorter timeframe is always welcome.
- Collaboration: Developers and sales colleagues need to work closely together. The Agile Manifesto recommends daily meetings.
- Support: For motivated individuals and creative teams to work well, the environment must also be right for them. They need the support of others and, above all, the trust of their superiors.
- Conversational culture: Direct communication is best suited to transferring information as effectively as possible and without misunderstandings. Talking face to face with each other enables questions to be asked and avoids wrong conclusions.
- Success: The success of a team can be measured above all by the publication of functional software.
- Sustainability: It makes sense for development to continue evenly. All participants and not just the developers should continue to work on releases.
- Quality: Developers should always ensure that their products meet the highest technical and design standards.
- Simplicity: You should make your work as simple as possible. Omitting everything that can be avoided leads to a leaner process and thus to better results.
- Organization: Only if you enable teams to organize themselves can you expect extraordinary results.
- Retrospective: An important aspect of agile software development is to question oneself at all times. In order to constantly improve the team's work, it is important that the members regularly exchange information about the way they work and adapt their approach accordingly.
The Agile Manifesto refers its values and principles exclusively to software development. This is due to the compilation of the authors. Developers have come together to work out a better way of working in software development. However, the defined points are so broad that they can easily be applied in other areas of work. Agile software development then becomes agile product development, whereby “product” is a vague concept that can also be seen as a service.
In the environment of agile software development, some practices have established themselves with which one can implement the agile approach in their team or company – “agile development” is only the umbrella term for it. Many of these techniques can be found in the forms of agile software development, e.g. Scrum, Kanban, Extreme Programming, Feature Driven Development, Behavior Driven Development, or Crystal.
- Backlog: The idea of a list in which all the tasks that still have to be completed but are not currently being worked on are collected is characteristic of the agile approach. The reason for this is the short work phases. Instead of dealing with several tasks at the same time or assigning a fixed time span to each task in a large plan, you have a flexible pool in the background. The team can select the next task from this pool.
- Retrospectives: These meetings are not only present as an abstract principle in the agile methods, but are also partly concretely demanded. Especially Scrum is known for having a fixed plan for various meetings. Only if the team regularly addresses challenges and problems, as well as successes, can it improve in the long run.
- User story: The demand to focus on the customer or the user can be met with user stories. Simple language is used here to briefly explain what a function must be able to do for the user. One notes this description on a so-called story card and arranges all maps to a story map.
- Agile testing: In agile software development, testing is seen as an integral part of the development process. Typically, the product is tested in a team at the end of an iteration – the short work phase – before it is considered “finished” and delivered to the customer. Only then does the next iteration begin with a new task.
- Pair programming: Four eyes are better than two is also true in pair programming. Two developers share a workstation, and while one of the two writes the code, the other checks the input. This costs more time (the reviewer could write code themself), but should reduce the number of errors in the code.
- Time boxing: Some forms of agile development have strict timelines. Again, Scrum is a good example where sprints have a certain length. In the end, the team has to present a finished product. This requires that you design and select the tasks appropriately.
There are many more techniques that can be encountered in agile methods. What they all have in common is the desire to make the workflow more effective and to increase the quality of the product.
Pros and cons of agile software development
Is agile software development the right solution for all? Depending on the situation of your company, the disadvantages can outweigh the advantages – on the other hand, a lot of people swear by it.
Flexibility in dealing with changing requirements
Inaccurate description of the development method can lead to spongy working practices
Openness invites exploitation and supports unproductive behavior
Continuous improvement of work processes
Deadlines difficult to meet without a long-term plan
Assumes prior knowledge
Close contact between all parties involved – above all with the customer
Additional communication costs more time
Subsequent changes to already completed projects are avoided
Works best when the whole team works in one place