Open Thinkering


Tag: agile

TB872: Differences between project management and systemic inquiry

Note: this is a post reflecting on one of the modules of my MSc in Systems Thinking in Practice. You can see all of the related posts in this category.

As I explained in my last post, systemic inquiries can be thought of as a meta-form of purposeful action. In other words, it provides a setting for programmes and projects. So we’re not setting one against another, but rather understanding that systemic inquiry is a cyclic process focused on learning and so without ‘outcomes’ or ‘deliverables’ defined at the start.

AspectTraditional ProjectsSystemic Inquiry
DefinitionA structured process with a specific goal, end product, or result to be achieved within set parameters.An adaptive approach to practice, focusing on continuous learning and adaptation to changing circumstances.
ApproachLinear and sequential; follows a set plan from start to finish.Cyclic and dynamic; not strictly linear and evolves as the inquiry progresses.
OutcomesSpecific outcomes or deliverables are defined at the beginning.Outcomes are not pre-specified; open to new possibilities and adaptations.
FlexibilityLimited flexibility; changes often require formal processes to revise initial plans.High flexibility; able to adapt to surprises and changes in circumstances.
FocusTypically focuses on achieving specific, tangible results within a certain timeframe and budget.Focuses on understanding and learning, often dealing with complex issues requiring adaptive change.
Management StyleOften managed through traditional project management methodologies.Managed through principles of systems thinking, action research, and adaptive management.
SuitabilitySuitable for projects with clear objectives and stable environments.Suitable for complex situations with uncertainty and evolving requirements.
Time FrameGenerally operates within a fixed timeframe with specific deadlines.Timeframes might be more flexible, with a focus on the process rather than strict deadlines.
BudgetUsually has a predetermined budget.Budget might be more flexible, accommodating changes in the inquiry process.
Quality StandardsQuality and performance standards are often specified and measured against pre-determined criteria.Quality is assessed in terms of learning outcomes and adaptability to changing scenarios.
Emotional UnderpinningOften characterized by a focus on efficiency, control, and predictability.Embraces uncertainty and maintains an openness to surprise and adaptability.

In my experience, Agile software development can be understood as a way to combine systemic inquiry with project management. According to the Manifesto for Agile Software Development, it’s the idea of valuing:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

It doesn’t always work like that in practice, and there are plenty of un-agile ‘Agile’ approaches in the wild. But that speaks more to it becoming a dead metaphor in command-and-control environments, rather than the original ideas not being sound.

Agile approaches usually centre around the learn-build-measure cycle, with an important element of the process being ‘discovery’. This involves talking to stakeholders to figure out their problems, find leverage points, and unearth users’ jobs to be done.

'Discovery' with the learn-build-measure cycle 

CC BY-ND Bryan Mathers for WAO

Conceptualising agile approaches as systemic inquiries (which I haven’t done previously) helps explain the value of user research. Systemic inquiry foregrounds social relations: it’s not just about the theory or method, but how these are applied and evolve through collaboration.

The scary thing for most people is that recognising that life is uncertain and unpredictable is a little scary. Traditional project management, with its outcomes, deliverables, and Gantt charts looks impressive but is likely to bear little relation to reality. In addition, not only is the world constantly changing, but our interactions with our environment change it and us. So our plans need to be adaptable; it’s not about doing things to a group of people, but rather doing it with them.

'Doing to' vs 'Doing with'

CC BY-ND Bryan Mathers for WAO

They say that the best way to learn something is to teach it, and the above images come from work that WAO did as part of an emergency response during the pandemic with Catalyst-funded charities. We helped them move away from pretending they knew what their stakeholders wanted to actually asking them. Although this sounds obvious, in the grant-funded world, where organisations have precious little time to reflect on their processes, delivery is hard enough.

What was interesting was how transformational this shift was for participants in the programme. Although it wasn’t couched in the language of systemic inquiry, the iterative nature of what we helped them do, along with understanding that they needed to learn from their successes and mistakes, really helped them.

What I’m still getting to grips with is how to explain systemic inquiry to others. The boxes-in-the-arrow approach and reference to Agile software development only takes me so far — especially for those who are less technical.

Images: CC BY-ND Bryan Mathers for WAO

Managing projects is about understanding context

Agile is a verb, not a noun

Ah… projects. There are some people who believe that the One True Way is Agile™. And by that they mean agile development frameworks such as SAFe and RAD and ASD and other awkward acronyms. At least for the kind of work I do with my co-op colleagues, those people are wrong.

The main thrust of the Agile Manifesto is that ‘agile’ is a verb rather than a noun. You don’t “do” agile, you work in an agile way. The difference is important.

Just as a recap, or perhaps for those who haven’t seen this before, here are the twelve principles of agile software from almost 20 years ago:

  1. Our highest priority is to satisfy the customer
    through early and continuous delivery
    of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

For me, the five bits that tend to leap out at me are those I’ve highlighted above. I believe agile methodologies can be applied to almost everything, so stripping out the references to software, focusing on the parts I’ve highlighted, and doing a bit of rewriting gives:

  • Simplify
  • Establish a sustainable pace
  • Build projects around motivated individuals
  • Create self-organising teams
  • Welcome changes based on feedback the audience you’re targeting

I have little time for people who try and impose a particular approach without understanding the context they’re entering into. Instead, and although it may take longer, co-creating an agile approach to the problem you’re tackling is a much better solution.

So, in summary, investing in people who work within a particular context, while being informed by what has worked elsewhere is absolutely the best approach. At least in my experience. But the best of luck to those who think that Industry Best Practices® and blunt implementations of complicated frameworks are going to save them.

I’ll be watching with my co-op colleagues, eating popcorn, getting ready for the inevitable call or email to help. And, you know what? We’ll be happy to.

This post is day three of my #100DaysToOffload challenge. Want to get involved? Find out more at

Header image by Christopher Paul High

Setting an Agile School Rhythm [DMLcentral]

My latest post for DMLcentral is up. I’ve been thinking about agile workflows and team productivity a lot recently and, in this post, I attempt to apply it to (formal) education environment. Give it a read and see if you think it works!

Click here to read

Thanks again to Bryan Mathers for the great header image!

Note: I’ve closed comments here to encourage you to reply on the original post.