BTW: German version here/Deutsche Version hier.
The world of software development changed strongly
As long as it was (and often still is) costly to change a screen or list layout, these specifications had to be fixed as early as possible in the project. If, on the other hand, it is easy to insert even new fields into the database even in late project phases, less effort has to be made with these specifications. The user no longer has to create detailed specifications and then sign them, so that he can only make change requests under penalty of considerable additional costs. This still happens, but it is more of an obedience test than a real necessity.
But if things are a bit more relaxed on these points, so to speak, where else can you do without hard work and commitment in early project phases? Do we still need an architecture concept, a data model, use cases, etc.? Let’s just work again according to the motto BID (brain into device), as it was common in the early days of IT. Back then software development was done by developers for developers and no one was there to make demands on the result without understanding and mastering the technology? The only thing that disturbs is the user, that’s probably how many developers silently think.
Spontaneous or structured?
In view of the new development tools and platforms, can the user perhaps make himself comfortable at all, be content with information about his requirements in free prose as well as critical comments on the prototypes presented to him, wait for the software developers to deliver the information system he has dreamed of sooner or later?
Or, conversely, do the software developers just have to give the user a tool, explain it to him, let him work with it for some time, and finally assemble the delivered parts into a user-friendly, technically optimal, and cost-effective information system?
Of course we all know that both extremes are not feasible and of course there is no one who seriously advocates such a scenario. But still, some things are in flux and there is uncertainty among all parties involved.
I think that even in agile projects some obligations remain, these affect all participants. Being flexible is not the same as being superficial, erratic and non-committal.
The duties of the users in agile projects are considerable
The users (meaning both the management and the users in the narrower sense) must develop a clear idea of what contributions an IT system should make to the success of the company as a whole and to the improvement of the addressed business processes in particular. An iterative approach favors the development of creative solutions, since strategic, organizational and technical imagination can interact better than within the framework of a classic, strictly phase-oriented approach based on the waterfall model. But there comes a time when you have to commit yourself, and that always means giving up something, at least for the time being.
It is one of the standing rules of IT strategy that the organizational issues must first be clarified before the IT application makes sense. And it is just as true that in practice, attempts are regularly made to get a grip on organizational problems via IT. If a rule is so often ignored, there is a suspicion that it is either wrong or at least unworkable in practice; according to a pragmatic notion of correctness, however, it is thus also wrong in the second case.
Organization and IT systems can of course be optimized separately and one after the other. However, there is no doubt in my mind that only a suboptimum is regularly achieved: If the user knew what possibilities IT could offer him, he would perhaps organize himself differently. If the software developer knew which requirements the user had not named because he did not consider them feasible or could not imagine them, he would solve some things differently.
Everything is possible, nothing is fixed?
If you basically wanted to optimize both subsystems at the same time, you would quickly exceed the limits of manageable complexity, the agility of the organization and the patience of the users. This is precisely where the possibility provided by modern development platforms to stimulate the user’s imagination in early phases with rapidly developable prototypes is extremely useful. However, only the user can make the final decision as to which type of IT support is worthwhile for which tasks and with which degree of convenience.
Particularly if one deviates from a strictly phase-oriented process model, there is a danger that the precision of project planning will be reduced and project management will become lax. However, it is one of the paradoxes we have learned from participatory organizational design projects that not only with the increasing number of participants but also with the increasing degree of participation, the tighter the project management has to be. The more creative leeway you give the participants, the more often changes occur that have repercussions in other areas. Interface, communication and stakeholder management must therefore be performed with the utmost professionalism in agile projects, significantly more so than in projects based on a more or less strict waterfall model. Milestone dates must be coordinated and the regular, proactive exchange of information must be ensured.
Written project assignments that are understood and recognized by all participants, a clearly defined project organization, and in particular project managers with sufficient decision-making authority and resources are some of the other elements that have always characterized good project management and are even more important under the more complex conditions of the agile approach.
It is the non-delegable duty of the user, especially the management, to take overall responsibility for the success and thus the overall project management.
Change is important and possible – but what kind of change?
Agile process models allow IT systems to change in the course of their development. Watzlawick et al. distinguish between two forms of change: „one takes place within a particular system, which itself remains unchanged, while the occurrence of the other changes the system itself“ (p. 29). They speak of first-order change and second-order change, respectively.
If we consider an IT application as a system of functions and data that are combined into applications and implemented on specific hardware and operating system platforms, agile process models facilitate first-order change. However, if it is necessary to change the character of the system as a whole, agile process models only marginally facilitate this. Agility therefore does not spare us the elaboration of a well thought-out IT architecture, but they do decisively facilitate first-order change, namely system optimization within the framework of a given architecture.
Good architecture does not come from occasional architects!
Software development without programmers? Software development by the users? Maybe, but it also depends on whom you call programmers and whom you call users. And it certainly also depends on how complex a software system is. If we agree that someone who writes macros in Excel, for example, or performs similar tasks in other systems is not a programmer, we cannot agree with the promises quoted above. If we make an analogy to construction, we see that in the age of prefabricated houses, very many builders no longer need an architect. However, prefabricated houses have been designed by architects and the more or less high quality of the design is recognized by anyone who wants to adapt a prefabricated house to his individual needs. If we go one step further to urban planning, we can clearly see the limits of self-planning in the urban planning stains of some communities. So if we want to avoid a „shake-up“ of the IT landscape (i.e., a collection of isolated solutions with complex interfaces), we cannot avoid having professionals supervise and sometimes guide the users, even in the age of Scrum and XP.
Not to forget: There are also duties of IT in agile projects.
So the duties of the user end where the overall architecture and the optimal technical design of the IT system are concerned, but they apply all the more when it comes to clarifying the strategic, economic and organizational prerequisites and framework conditions of the IT deployment. But this is where the success of the IT deployment is largely decided, regardless of whether we work agile or not.
The successful interaction of many stakeholders does not work without stable structures and disciplined collaboration. Flexibility requires a lot of work, and not just when it comes to yoga.