Agile Software De­vel­op­ment

Agile software de­vel­op­ment has been around for a long time now and agile methods have also long been es­tab­lished 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 tra­di­tion­al work that is mis­takenly upgraded with a buzzword?

As early as the 1990s, teams of software de­velopers began to work with methods that can now be con­sidered agile software de­vel­op­ment. Until the end of the 20th century, various software de­velopers and teams did a lot to make pro­gram­ming more light­weight, and so the method became known mainly under the keyword "light­weight." During this time, the Scrum method and Kanban were developed, which could not be sum­mar­ised at that time under the term "agile product de­vel­op­ment," because this ex­pres­sion did not yet exist.

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 de­velopers created the Agile Manifesto. Bringing together their re­spect­ive ex­per­i­ences in software de­vel­op­ment and teamwork, they found solutions, es­tab­lished prin­ciples, and sum­mar­ised everything under the term that today is syn­onym­ous with a modern way of working: agile software de­vel­op­ment.

When they first started to question the methods of software de­vel­op­ment 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, cre­at­ively, and pro­duct­ively. Instead of following a thor­oughly planned, linear, and bur­eau­crat­ic process, as with tra­di­tion­al methods – e.g. the waterfall model – the project is started. For this, agile software de­vel­op­ment assigns much more re­spons­ib­il­ity to the team of pro­gram­mers.

In addition, one more or less says goodbye to huge projects: Instead of spending months or even years man­u­fac­tur­ing 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 prin­ciples and four values have been agreed upon in the Agile Manifesto.

The values of agile software de­vel­op­ment set the focus that teams should always keep in mind during de­vel­op­ment work. They are noted as pairs of opposites; both aspects are important, but one is over­rid­den by the other in agile de­vel­op­ment:

• In­di­vidu­als and in­ter­ac­tions over processes and tools: The people involved and their co­oper­a­tion with each other are more important than the question of a specific process or tool.
• Working software over com­pre­hens­ive doc­u­ment­a­tion: The focus is on a func­tion­ing end product. The doc­u­ment­a­tion of the work, however, is of secondary im­port­ance.
• Customer col­lab­or­a­tion over contract ne­go­ti­ation: Agile product de­vel­op­ment is more concerned with meeting the customer and his re­quire­ments than with con­duct­ing contract ne­go­ti­ations.
• Re­spond­ing to change over following a plan: It is assumed that software de­vel­op­ment must respond to constant changes. It may be necessary to overturn a pre­vi­ously defined plan.

These values are like a mantra to be in­ter­preted. They don't provide precise guidance, but are there to remind de­velopers of the key important aspects of pro­duc­tion: 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 in­struc­tions are the twelve prin­ciples of the Agile Manifesto. These provide ad­di­tion­al in­form­a­tion and expand on the values. But even here it is not an actual in­struc­tion – in­struc­tions are not what the Manifesto wants to provide. The prin­ciples are broad and serve to dis­tin­guish agile from non-agile methods.

Customer sat­is­fac­tion: By early and con­tinu­ous pub­lic­a­tion – in the sense of con­tinu­ous delivery – the customer should be satisfied at any time.

• Flex­ib­il­ity: Agile teams always evaluate changes as something positive, even if they appear late in the de­vel­op­ment process. If one follows the Agile Manifesto, ad­apt­a­tions to changed re­quire­ments give the customer a com­pet­it­ive advantage.
• Delivery: Func­tion­al software is delivered directly within a timeframe of a few weeks or months. A shorter timeframe is always welcome.
• Col­lab­or­a­tion: De­velopers and sales col­leagues need to work closely together. The Agile Manifesto re­com­mends daily meetings.
• Support: For motivated in­di­vidu­als and creative teams to work well, the en­vir­on­ment must also be right for them. They need the support of others and, above all, the trust of their superiors.
• Con­ver­sa­tion­al culture: Direct com­mu­nic­a­tion is best suited to trans­fer­ring in­form­a­tion as ef­fect­ively as possible and without mis­un­der­stand­ings. Talking face to face with each other enables questions to be asked and avoids wrong con­clu­sions.
• Success: The success of a team can be measured above all by the pub­lic­a­tion of func­tion­al software.
• Sus­tain­ab­il­ity: It makes sense for de­vel­op­ment to continue evenly. All par­ti­cipants and not just the de­velopers should continue to work on releases.
• Quality: De­velopers should always ensure that their products meet the highest technical and design standards.
• Sim­pli­city: 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.
• Or­gan­isa­tion: Only if you enable teams to organise them­selves can you expect ex­traordin­ary results.
• Ret­ro­spect­ive: An important aspect of agile software de­vel­op­ment is to question oneself at all times. In order to con­stantly improve the team's work, it is important that the members regularly exchange in­form­a­tion about the way they work and adapt their approach ac­cord­ingly.

In the en­vir­on­ment of agile software de­vel­op­ment, some practices have es­tab­lished them­selves with which one can implement the agile approach in their team or company – “agile de­vel­op­ment” is only the umbrella term for it. Many of these tech­niques can be found in the forms of agile software de­vel­op­ment, e.g. Scrum, Kanban, Extreme Pro­gram­ming, Feature Driven De­vel­op­ment, Behaviour Driven De­vel­op­ment, or Chrystal.

• 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 char­ac­ter­ist­ic 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 back­ground. The team can select the next task from this pool.
• Ret­ro­spect­ives: These meetings are not only present as an abstract principle in the agile methods, but are also partly con­cretely demanded. Es­pe­cially Scrum is known for having a fixed plan for various meetings. Only if the team regularly addresses chal­lenges 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 de­scrip­tion on a so-called story card and arranges all maps to a story map.
• Agile testing: In agile software de­vel­op­ment, testing is seen as an integral part of the de­vel­op­ment process. Typically, the product is tested in a team at the end of an iteration – the short work phase – before it is con­sidered “finished” and delivered to the customer. Only then does the next iteration begin with a new task.
• Pair pro­gram­ming: Four eyes are better than two is also true in pair pro­gram­ming. Two de­velopers share a work­sta­tion, and while one of the two writes the code, the other checks the input. This costs more time (the reviewer could write code them­selves), but should reduce the number of errors in the code.
• Time boxing: Some forms of agile de­vel­op­ment 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 ap­pro­pri­ately.

There are many more tech­niques that can be en­countered 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.

Is agile software de­vel­op­ment the right solution for all? Depending on the situation of your company, the dis­ad­vant­ages can outweigh the ad­vant­ages – on the other hand, a lot of people swear by it.