Agile production is nothing new, anyone involved in software delivery will know all about SCRUM and sprints etc, if not a quick Google search will give you all you need and more. What I am looking to introduce in this article however is a view beyond the current uses and into how agile methods came about, and ultimately to shine a light on the core principles.

Firstly: Agile is not 100% defined as a software delivery method.

Admittedly the software community now appears to own the most commonly used terms but if you can grasp the principles they can be applied to any commercial [or non-profit] situation regardless of sector and size.

Secondly: Agile development is rooted in Japanese culture and working methods.

There is a massive amount of academic literature around this subject  [“The Knowledge Creating Company” by Nonaka and Takeuchi is the definitive example ] but it is safe to say that the core principle is as much about mindset than it is about process, with great emphasis on learning by doing rather then planning, planning some more, and then doing.

Thirdly: Agile methods were originally developed to solve the problem of how knowledge is created and shared within an organisation.

The reason for this being that knowledge was seen as a tangible asset within any organisation and not just a by-product of the production process or something that could be hired in when needed.

Finally: Agile is really another word for collaborative problem solving and solution creation.

So in summary:

• It’s not just for the software developers
• Its much more about how you approach a problem than what you do to solve it.
• It’s really about sharing what you know and helping everyone know more.
• It’s really about creating anything [it’s just that the software people got there first]

So how does it work?

The principle building block and idea that runs through the whole concept can be explained in two words: Narrative and Iteration, let’s start with narrative:

As with the other elements a quick Google Search will throw back all you need to know about themes, epics user stories and everything else. The point as before is not to get caught up in the how but to embrace the idea that unless we make the best use of first person narrative then we cannot ever be truly agile or deliver a fully effective solution. This is why phrases that begin with “I think we need…” need to be banned and replaced with “The user will achieve …” This places the end user in the driving seat, which is really where they need to be. If we then add a failure point along the lines of “unless this happens then we can all go home” we are setting a clear definition of what words like “done“ and “finished” actually mean in our frame of reference.

Iterations are key part of the agile process, as before ask Google for the definition of an agile iteration and it will give you all you need. The point here is that we often still use models and principles that are rooted in our culture and language. If we can get rid of the idea that we are building a house along a definite and fixed timeline [i.e. waterfall] then we can make best use of the idea of agile as a principle. If we can accept are essentially creating a living thing that will grow through time [and not in any way a house] then we can welcome the changes in direction rather then seeing them as obstructions. Likewise failing is seen as an essential part of the process as it is used to inform the stages of development. So getting rid of the idea that failure as negative is key [easier said than done I know].

So what does that mean for my project or my organisation?

Using agile solves the problem of how knowledge is created through human interaction and as a result can [when used correctly] help establish a much clearer communication channel between all parties, whether they are clients or team members.

For example: A common scenario happens when a client makes a request of some description. This often starts with “Can we just….” or “We need to…”

This is often followed by further requests of a similar nature that can often overrun and cause issues with development, time boxing and also costs. Not only that but the “solution” being proposed is often an ill-informed response to a vague brief and as a result it rarely results in satisfaction from the client [or anyone else for that matter].

So a much better solution could be:

Ask for a simple user story that defines the problem rather than proposing a solution, the acceptance criteria will then define where the failure point is and what will be considered a success. So straight away the dynamic  should have more clarity and the path to the solution should be clearer.

So just to summarise:

Agile is as much about mindset than it is about sprints, scrums or anything else. Narrative isn’t just about talking a lot, it’s about creating meaningful dialogue that sticks and serves a purpose. A lot of what agile is about can seem unintuitive, but like I just said, mindset.