Blending Agile Approaches (1) Dealing with Complexity
This is the first in a series of posts about why I think it is good for agile coaches and agile teams to blend approaches, and to experiment about how best to deliver in an agile way. I’m working towards articulation of a semi-formed idea, so it might take 4 or 5 posts to get there.
Let’s say there will be 5 :)
First things first: why do we even need agile approaches in the first place?
It probably makes sense to start by pointing out the painfully obvious, that most software projects are complex. Exhaustingly, relentlessly complex. Indeed, at times, working on software development can feel so complex that it borders on the chaotic.
For example, when requirements are discussed with stakeholders, there can be many voices involved, each with their own expert, tacit knowledge. And that’s before we even consider the challenge of building relationships. Building consensus between all stakeholders to an important software project is incredibly challenging for a product development team.
This means that, when teams are trying to forge a common understanding of the task at hand, sometimes even that first definition of ‘what’ we are building can be elusive.
Then comes the ‘how’. Alongside these consensus-building efforts, there can be any number of architectural choices available. We might need to prototype, or evaluate and compare alternative approaches. And when we set out at the start of our journey towards delivery, many of these choices are far from certain.
Ralph Stacey understood how the interaction of these two activities can render projects and decision-making more complicated. When requirements are not yet agreed, and technology choices are uncertain, projects can feel complex, and at their worst, chaotic.
The Stacey Diagram above is a great visualisation of this matrix.
Dave Snowden has also visualised this complexity, in the Cynefin (ker-nev-in) framework (below). Cynefin is the Welsh word for ‘habitat’, which Snowden himself describes as a complex system, made up of the interaction of many influences, some of which we might only be partially aware.
So, with models and frameworks, we can understand how complexity can grow, but how do we interact with these complex environments in order to reduce complexity?
Snowden asserts that we need strategies to help to make sense of complexity, and the best available strategy in a complex environment is to “probe, sense and respond”.
In order to make that happen, we establish conditions where experts can safely check theories, and potentially fail without serious consequences. Once we can work in this kind of environment, it becomes possible to move forward with our understanding, one small step at a time.
As well as describing complexity, Stacey’s matrix and Snowden’s framework can also help us to understand that some decisions can in fact be simple. If requirements are fully agreed, and the technological choices are understood and not up for debate, then we are in a place of routine.
In this space, we may even be able to successfully run a waterfall project! Gasp!
However, Snowden also rightly warns of the dangers of complacency, or assuming we are working in a simple space, and predicting that things will always be this simple. If we assume a lack of complexity, we risk suddenly moving into a zone of chaos, because we only realise too late that things are more complex than we thought. The danger here is that we will fall ‘off the cliff’ into a zone of chaos.
Given that the majority of software projects face an environment with low levels of agreement between stakeholders, and high uncertainty related to how we deliver, it seems agile approaches are better suited to help us make sense of the environment, and give us a better chance of delivering the right thing.
Agile approaches to software development generally work in small bursts or batches of work, and ensure that stakeholder feedback is an important part of the process, validating what we have done so far, and feeding into our decisions of what to do next.
In a complex environment, agile approaches don’t guarantee success. Indeed, Stacey and Snowden’s theories illustrate how difficult success can be to achieve! However, these theories also reinforce why agile’s core assumption of potential complexity can reduce risk, and give a better chance of success.
In addition, the goal of agile approaches is to continually ‘uncover better ways’ of developing software, whether that is via process, technology, or how we work together. Agile approaches involves learning as a starting requirement, and at its core that requirement asks us to reject complacency, and its hard-boiled assumption that things will continue to be simple.
As humans, we’re optimists by nature. We always hope things will be simple, even when experience tells us they won’t.
Agile approaches protect us against that potentially misguided optimism, and help us to move forward and make sense of complex environments.
Next up: learning, how we all learn in different ways, and why it is important for agile practitioners to understand how learning can happen.
References:
