Enhancing Agile to solve wicked problems
I’ve been thinking a lot recently about the what the post-Agile age will look like. Maybe I’m just getting tired and a bit cynical of writing things on cards, writing tests and the emphasis on practices within the Agile community.
How well does Agile help us solve the important problems? I’d say it’s a good start but we can learn a lot from change management and system thinkers that can deepen and enhance our understanding. In doing so, the Agile practices serve the mindset and not the other way around.
I’m interested in how software helps us solve wicked problems:
Rittel and Webber coined the term in the context of problems of social policy, an arena in which a purely scientific-rational approach cannot be applied because of the lack of a clear problem definition and differing perspectives of stakeholders.
Wikipedia goes on to say:
Thus wicked problems are also characterised by the following:
- The solution depends on how the problem is framed and vice-versa (i.e. the problem definition depends on the solution)
- Stakeholders have radically different world views and different frames for understanding the problem.
- The constraints that the problem is subject to and the resources needed to solve it change over time.
- The problem is never solved definitively.
Sound like any problems you’ve worked on recently? Compared to, say, even 5 years ago, software developers are taking on more of these multi-stakeholder problems because organisations are getting pushed in this direction through the emerging forces of social media, corporate social responsibility and a great emphasis on networks in business.
For software developers, we’re building systems in the context of much greater social complexity. There needs to be a much great awareness on our part of what is emerging around us.
I took a stab at capturing this in the context of Agile Planning:
Agile lends itself to dealing with high social complexity due to the emphasis on self-managing teams and collaboration. The feedback loops in the Agile planning process provide the means for co-creating the solution with the stakeholders.
Retrospectives are an important part of this. In this presentation, I emphasis that a retrospective isn’t about learning from the past:
A retrospective can and should be used for incremental, iterative stakeholder engagement, which, to borrow from Theory U, taps a different source of learning. It is an attempt to tune into the future that is emerging around us.