If you’re a software enthusiast, you’ve probably already come across the term ‘agile’. Anyone who goes through life with their eyes and ears open is sure to have heard the term. To explain this term comprehensively and conclusively would require the writing of entire volumes of books. I’ll try it in a few words.
Agile comes from the English (how could it be otherwise) and translates as “agile”. When we talk about “agile” in software development, we usually mean the development process. Instead of burying itself in the dark room, specifying requirements, accepting them and then developing them, the agile movement tries to “dynamize” this process and make it transparent:
Specify the most important requirements, develop them and see what comes out of it and then specify the next ones and develop them again.
Or using a metaphor: Peter Mustermann walks to work every day. He wants a faster and more convenient way to do this job. He doesn’t know exactly how.
According to agile process methods, we would now first build a scooter and give it to Peter. He is enthusiastic. The scooter is expanded, becomes a bicycle, becomes an e-bike, becomes a motorcycle, becomes a car. If he is already satisfied with the e-bike, he can stop the project there and save the money for developing the car.
This has the following advantages for the customer:
- Progress is visible
- Even after a very short time, a benefit can be generated for the customer (the scooter may not be a Ferrari, but it is definitely more pleasant than nothing at all).
- The customer can influence further development. Instead of having to think everything through in advance, the customer can always rethink and make changes/wishes. This is particularly helpful in the case of software that is only virtual.
That’s the easy part. In the second part, I look at the topic of \”Agile\” from a company perspective.