How much agility makes sense?
Agile methods have become established and are constantly being further developed. Parallel to the practical application and development in project management, the various aspects of agility are also constantly re-evaluated and discussed in the media and in the professional world on blogs. Among the endless articles about agile management, one article by Luk Van Wassenhove stands out, which appeared on Knowledge.insead.edu and deals with the question of what happens when agile techniques do not work. Luk Van Wassenhove says: Don't blame the team - at least not immediately. For many, the fast rhythm and constant short-lived deadlines in agile management seem very hectic at the beginning. Everything is always urgent and the team seems to be under constant pressure. Although this pressure ensures high productivity, team leaders always have to find the middle ground between destructive overload and laissez-faire. Sprints that are too short are not conducive to team performance. Put your focus on data collection in software development projects instead of giving in to the illusion of control! Below we summarise Van Wasserhove's theses.
Agile, but not too agile
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.
Finding the right balance
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.
Better overall view
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.
The easy way?
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.
Author: IAPM internal
Key words: Agile Project management, Analysis, Human Management