Agility – or War of Attrition

As implied by its name, agile information system (IS) development is characterized by its flexibility, continuous feedback collection, and iterative re-planning of objectives and solutions. This methodology has largely supplanted the traditional waterfall IS development model, which was originally derived from the project management practices such as those used in large shipyards and construction industries. In the waterfall model, all specification and planning activities are completed prior to the commencement of actual implementation. Consequently, user feedback is typically obtained only during the testing or deployment phases, posing the risk that errors originating from the specification phase may only be identified at these later stages.

In agile IS development, the initial stages involve significantly less detailed specification and planning. The basic idea of agile development is that the information system is developed in small parts, and after each ‘sprint’, a development cycle of a few weeks, user feedback and evaluations of the latest development steps are sought. Based on the feedback, the development direction is corrected if necessary, and the next steps are planned and prioritized. The developed information system is built piece by piece in sprints, and continuous feedback ensures that little unnecessary work is done and that the developed software meets real usage needs. At least in theory.

Theory does not always align with practice

Since a significant portion of agilely developed information systems fail (The Standish Group International 2015), it seems that practice does not fully match the theory. There can be many reasons for failures: agile development usually does not have a precise deadline, thus, development is decided to end before all essential functionalities are implemented (time, money, or management patience runs out). Or perhaps the wrong users/experts were asked, and some key user/stakeholder was completely overlooked. Or user/experts did not have time to really think about the matter and gave feedback quickly off the cuff (cf. Kahneman’s system 1 thoughts, Kahneman 2012). Or it may be that users/experts view the system only from their limited perspective, focusing on details, i.e., ‘nitpicking’, and the product owner does not dare/cannot see the whole picture from important and less important details. For example, the user interface polishing never ends, but the underlying system integrations are left completely unimplemented.

Yet, what happens if there is enough money and time, the experts are chosen correctly, the whole is well understood, but success is hindered by sheer exhaustion? When considering obstacles to the success of digital transformation in organizations, Fitzgerald et al. (2014) highlighted one typical factor as people’s fatigue with new innovations (e.g., constantly changing information systems) (see e.g., Chung, Choi & Du 2017; Fitzgerald et al. 2014; Khaw et al. 2023).

Innovation fatigue and exhaustion

Innovation fatigue is easily thought to arise from large, successive development steps, but fatigue can occur on a smaller scale: it is influenced not only by the burden of previous innovations but also by perceived helplessness (inability to influence the success of the innovation) (Chung et al. 2017).

For example, the party coding the system may not understand the customer’s feedback and makes solutions from one development cycle to another that almost, but not quite, meet the customer’s needs. One result may be that when development has continued sufficiently, small non-functionalities become normalised, and there is a desire to move forward. Instead of fixing non-functionalities, it is easier to find various workarounds and modify the business process and tasks to meet the system’s requirements, even though the intention was the opposite. The built information system works, but the achieved benefits are small (a kind of system-level manifestation of Solow’s productivity paradox, see e.g., Acemoglu et al. 2014).

A slightly worse situation occurs if there is total exhaustion with stagnant development. If from one development cycle to another it seems that developers, despite trying, just cannot achieve the desired functionality, then at some point there is a temptation to accept that practically non-functional solution to move forward in development and sometimes even get rid of the entire project. This is a kind of version of the principal-agent problem (Eisenhardt 1989), where information asymmetry has unintentionally become a permanent state. In this case, participatory development turns into a war of attrition, from which experts commenting on the information system alongside their work try to discard by all means, even accepting questionably functioning solutions.

Agility is also needed in method selection

It can be concluded that all information systems (IS) development methods present their own challenges. Rather than awaiting the advent of a new paradigm for IS development (see Lagstedt 2024), it is crucial to openly assess development situations both prior to and during the development process. This involves determining the most suitable development method to initiate the project (Lagstedt et al. 2022) and continuously evaluating the effectiveness of the chosen method throughout the development. If stagnation in development or participant fatigue is observed, it is essential to allocate additional time to reconsider the development approach. This may involve deciding whether to persist with the current method, alter the team composition, or implement other measures. If the end-users involved in the development process become fatigued, the issue will not resolve itself: proactive measures must be taken. As Albert Einstein famously stated, ‘Insanity is doing the same thing over and over again and expecting different results’.

Kuva: Shutterstock