'Agile' - much to learn about working in complexity

I have been able to get a sense of what 'agile' is over the last month and I've had to conclude that, yes, there is vast experience in programming that will be of value for those helping government manage complexity better.

The method parallelogram

We can create a neat parallelogram, combining

• Waterfall > Agile
• Government (as it is typically today) > Redesign (and like design-thinking methods)

Waterfall programming gets its name from an approach to work where each step is completed in-full before progressing to the next stage. The issues with Waterfall programing and typical government methods are the same: the methods are built on an industrial-era philosophy of the world and work that is much simpler, and can be reduced to predictable bundles to be addressed efficiently in compartmentalised steps (along with other traits that are no longer applicable).

Agile is much more fluid, and includes (re)design-like elements, including rapid prototyping.  The heart of agile isn't a rule-book, but rather a manifesto and a set of principles.  Those familiar with design-thinking will see an obvious similarity - strip out the programming-specific elements and the heart of the approaches is much the same.

Programming methods and language generally

Programming methods and ways of understanding tasks tend to pop up in unexpected places.  I asked someone (Matt @Collabforge) their opinion on how well government manages complexity, and in response he talked of how government seems to not deal with complexity, but rather be counter-productively reductionist  - which in programming would apparently be understood as 'inappropriate compartmentalisation'.  In government, you won't have much luck explaining it, let alone have a word for it.

There's something about the very conscious logic and structure of software project management that appeals, and I'm curious about how much one can learn.

Experience

The thing that is getting me excited - particularly about 'agile' at the moment - is the experience of making this very different approach work.  The experience fighting up the other arm of the parallel. Practitioners that have had a clear vision for years, of a working method appropriate for complex systems, but still seem to need to fight to make those principles work.

So how do they fight? And where they do, how do they win?

www.jsbaxter.com.au

@JohnSBaxter