Previous sections have dealt with agile development and sensemaking in some detail. This section will proceed to point out certain important similarities between the two in terms of the actual application of agile development in real-world use cases. Focus is placed specifi- cally on the structural and principle elements enabling an analysis of agile development as sensemaking activity.
5.4.1 Active Construction Process
Agile development is fundamentally a software development methodology (Abrahamsson et al., 2002). Ultimately, the goal, therefore, is to develop a software product. This creative drive is imperative to understanding what agile development is about.
In sensemaking a similar principle is present in two instances. Firstly there is the preoccupation with sensemaking being a creative act of authoring (Weick, 1995). This means that sensemaking is not a passive interpretation process that occurs separate from the phenomena under observation. Rather, authoring positions sensemaking as an act in-the-world—an activity helping us construct meaning.
Agile development, in the same way, rejects the notion of external analysis and planning, positioning practitioners right in the thick of the problematic context; forcing them to cope
5
It is important to bear in mind that these organising activities can not be distinguished from their environment and therefore also impact the environment. This enactive effect is discussed in more detail later in this chapter.
5.4 — Agile Development as Process 94
with it, struggle through it and make sense of it.
Secondly sensemaking places the focus on action. This is especially prominent when Weick (1995, p. 13) contrasts interpretation and sensemaking by calling interpretation a “product” whereas sensemaking is an “activity” or “process”. This is typical of the action- driven, interactive nature of sensemaking and is further reinforced by the realistic notion of sensemaking as a way to “cope” with the world. The implication is that sensemaking is not only about understanding the ostensible predicament, but also about doing something about it.
Pragmatism is concordantly prevalent in agile thinking. The priority is always tilted towards action and delivery of a real product. Even the second tenet of the agile manifesto (Beck et al., 2001) states that the movement prefers
Working software over comprehensive documentation
The preference for action and development is repeated in the action-driven planning and aims such as “creating a culture driven by performance” (Sutherland, 2007). Agile development thus engages in an active construction process - not only in terms of the product under construction, but also due to the reality construction taking place during the development cycle.
5.4.2 Ongoing Enactment
Sensemaking is an ongoing activity engaged in by all actors. It is not a project or a task, but rather a continuous perspective on constructing and interpreting reality. This is emphasised when looking at sensemaking from the view of enactment theory (Jennings & Greenwood, 2003). This theory constructs a cyclical chain of change, enactment, selection and retention (see Figure 4.1). Repeating their explanation Jennings & Greenwood (2003) state, “sense- making can be treated as reciprocal exchanges between actors and their environments that are made meaningful and preserved”.
There is thus a constant interplay between the environment and the enactment process. The sensemaker has to be highly sensitive to environmental changes and adapt accordingly. Both agile development and sensemaking rely on some formalised structure to explain the internal mechanics of the processes. Despite most agile methodologies listing a stag- gered, chronologically sequenced set of steps or phases, the agile development mindset is
continuous. All the underlying assumptions, as well as the worldview, have a major impact on the way actors within agile processes act.
Scrum and XP (the two examples chosen for this study) both employ workflows that contain linear and cyclical elements. The introduction of feedback loops to these work- flows embeds these development processes in their environment (in contrast to traditional approaches isolating development from “external influences”).
Agile development is therefore not simply a “project” or “tool” that can be applied in certain circumstances. Once a team selects this approach, it has far-reaching and irrevocable implications. It is not possible to move a development project into an “agile phase”; agile development is an ongoing process deeply influencing the behaviour of individuals engaged in such projects. We can understand why this is the case when reviewing the matter from a sensemaking point of view.
In practice, agile development is also being used for the maintenance of completed products (Svensson & Host, 2005), albeit not without difficulties. This shows that agile approaches are not only ongoing during the initial development process, but may actually be applied throughout the software product lifecycle.
In referencing Heidegger’s concept of “thrownness” (Winograd & Flores, 1986), Weick leads us to conclude that if one accepts that sensemaking occurs in humans, it has to be a continuous, ongoing, basic process and that there is no real alternative to this. In fact, the first four points summarised by Winograd & Flores all explain how individuals are compelled to do certain things. (Please refer to the list on page 67.)
Agile development performs in the same way and the point is to allow for an emergent process rather than to contain or limit the process in formalised routines that become abstracted from the context of application and the goals of application. Since planning, adapting, coding and testing are all continuously taking place, the development process is transformed into an ongoing stream of activities with an end-point that is very difficult to determine (if possible at all).
5.4.3 Retrospection
Sensemaking theory proposes that all awareness is awareness of the past; it is not possible to gain access to the immediate present (Weick, 1995). This gives all sensemaking (and by implication all consciousness) a retrospective nature.
5.4 — Agile Development as Process 96
Agile development displays the same characteristic and is managed specifically to allow for learning and retrospection as a defined aspect of the process.. Firstly, if you accept the argument forwarded by Weick, agile development (and everything else) would be affected in the same way. This is, however, not the only reason agile development displays elements of retrospection.
Due to the previously discussed heightened sensitivity to feedback, agile development approaches develop several continuous retrospection mechanisms. The idea is that develop- ers should constantly monitor both the environment and the effect their actions are having on said environment.
To this end, teams are not only retrospective, but also introspective. Two of the cere- monies in Scrum (Schwaber, 2004), sprint review sessions and sprint retrospective sessions, deal specifically with looking back at the development process and investigating possible improvements or identifying learnings. These ceremonies happen in addition to the con- stant critical investigation of work in progress as well as several ad hoc discussions about recent developments.
Retrospective sessions are also important due to their focus on discussion (commu- nication). By talking through the past development sprint, members develop a shared understanding and experience and can process their experiences. This sensemaking process allows them to learn and adapt their own perspectives to foster greater cohesion within the development team.
5.4.4 Adaptive Presumptions
Sensemaking operates through a series of constantly adjusted presumptions, allowing the sensemaker to detect irregular perceptions and flag these for attention. This “series of approximations” (Paget & Cassell, 2004, p. 143) shows an intense adaptability and respon- siveness to the environment.
Agile development displays the same pattern during the life cycle of a project. Re- quirements and specifications are constantly adapted to suit evolving customer needs. In order to manage exceptions and control the development processes, presumptions about the expected state of the system also need to be adjusted.