How much agility makes sense?

Luk Van Wassenhove's experience is that many companies apply or "impose" the agile concept on their own structure, paying too little attention to the impact this change will have on the teams. Agile is good, but there is also too much of a good thing. Certain boundaries and norms must be adhered to, otherwise problems from one sprint will drag into the next and slowly accumulate. As a leader, you need to avoid this kind of vicious circle at all costs. Your job is to recognise when the pressure becomes too much and when the pressure leads to mistakes and poor quality. Luk Van Wassenhove has worked on research projects on software project management with Kim van Oorschot from the Norwegian Business School and with Kishore Sengupta from Cambridge Judge Business School. The three have published a paper entitled "under pressure". In it, they jointly show that the 20-day agile work cycle is not optimal for quality of outcome, costs and project duration.

Luk Van Wassenhove's team thought about how agile methods can best be balanced with technical aspects of software development and the human factor. Learning, experience and work rhythm played a role. They used real-life work data for their considerations, namely a project that five people had worked on for 260 days. The effects of longer and shorter sprints, of sprints under pressure, the behaviour of team members and performance were examined. The result of the study was that people performed best and most efficiently in software development when their sprints were between 43 and 65 days long, i.e. between two and three months. Costs were also best deployed in this scenario.  The number of undetected errors at this speed was almost 40% lower than the error rate of faster projects. Costs were reduced by over a quarter. Team members still worked some overtime at this moderate speed, but not to the extent of exhaustion or risk of burnout. At the same time, the reduction in speed meant that no shortcuts were chosen and thus fewer mistakes were made. At the end of the paper, the three authors emphasise that the ideal length and speed of a project always depends on the project and its specific peculiarities, not least because clients have different tolerances when it comes to mistakes. Of course, the question of whether the product absolutely has to be on the market quickly or whether it is more important to launch an error-free and optimally running product also plays a role. The latter can be the case, for example, with military applications, software for banks or other payment systems, or projects in which data protection plays an important role. On the other hand, there are customers who have a maximum of one month to publish an app.

Most companies record data such as the number of errors and the deviation from costs and deadlines. That's great, but it just doesn't show the whole picture. Somehow it should also be possible to capture the human factor when it comes to evaluating how well or badly a project went. True, it is not easy to measure how much more exhausted the staff were on this project compared to the last, because these values are always subjective. But the experience of the team members should also be taken into account in the evaluation. Dissatisfied and burnt-out staff may look for another job and it costs cash to find and train new staff. Not to mention the fact that a lot of knowledge and experience is lost with good employees.

Companies as well as people usually look for the easiest way. This fact is probably the reason why few companies actually spend much time evaluating completed projects. After all, the next project is always just around the corner. However, the insights gained through evaluation and follow-up are essential for the success of future projects. If you don't learn from your mistakes, you will make them again and again, especially if you don't know they are mistakes. The opportunity to gain and record experience directly from a completed project is invaluable and often simply not used. Luk Van Wassenhove therefore advocates post-project review, especially with regard to the workload, stress and possible overload of employees. Speed is not always the be-all and end-all. Agile does not always mean that everything has to go much faster, but is at best a new way of working together, a human and flexible way of leading projects to success and keeping teams efficient.