Focus on the principles and not the methodology when in an agile environment - (or just be more lean)

I have been working in an Agile environment for about 4 years, it’s my first time working in that environment and I have come to realise that we can often become too preoccupied with the methodology and adhering to that methodology that we can forget what we were trying to solve by becoming agile.

I have for the first time given a 10-minute lightning talk on this topic and thought that I would put it down in an article.

The intention is to try and help those attempting to embrace agile, to navigate through the jargon but also remind those already working in an agile environment to take a step back and refer any changes or discussions to the agile principles, or better yet, lean principles.

Recently I have been trying to introduce someone in a non-agile non-technical environment that agile will help them better manage their day to day. It has been a very worthwhile exercise for myself to better understand agile without the emphasis on software development. To do this I fell back on the 'explain it to me like I am a 5-year-old' approach, which made me think about what agile is to me, and I came up with:

'It encourages me to remain customer focused whilst delivering a continuously increasing quality of work with less waste'

Whilst this may seem a simplified view of agile I think it explains the reason for adopting agile quite well, on a level non-agile, non-technical people can easily get on board with.

Before the methodology came the principles

Lean really took hold in the 1930 - 1950's from the Toyota car manufacturing plant in an effort to become competitive in the industry. By looking at processes in the delivery system they realised small incremental changes could provide better less wasteful delivery. It was here where the concept of looking at flow through the system was defined, and the 5 principles of lean were developed.
A full history of lean can be found at: https://www.lean.org/WhatsLean/History.cfm

Lean and Agile have always had a connection, the initial Agile developers had all looked towards lean for inspiration. Martin Fowler explains that Mary and Tom Poppendieck helped inspire the original agile way of thinking and its principles. Mary, working in a manufacturing plant and Tom working in software. Both being active members in the agile community shaping its direction in the 1970 - 1990's.
For the full article by Martin fowler on this: https://martinfowler.com/bliki/AgileVersusLean.html

The agile manifesto was created with 12 principles in 2001 which encourage a way of working that adapts the lean principles for software development. It is the agile manifesto that is credited as being the defacto guide to agile working supported by the 12 principles.
The agile manifesto and the 12 principles: https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/

Once the principles were in place different ways to adhere to those principles formed starting with Crystal in the early 1990's and has since gone through many changes and is adapted in many different ways, some of the more popular include, Scrum, Kanban and SAFe.

The principles

Lean kit (https://leankit.com/learn/lean/lean-principles/) defines the 7 principles of agile as:

These 5 principles, as shown at the lean.org (https://www.lean.org/WhatsLean/Principles.cfm) form the lean continuous learning loop:

I find these 5 principles or stages of the loop when used with the 7 lean kit principles helpful to cement the lean thinking that is needed to be 'working lean'. Identifying the value to the customer gives the constant reminder of remembering who you are providing the service for before mapping the way to achieve what the customer desires. Once understood remove all obstacles from the flow of that service ensuring that it gets to the customer in a timely waste less manner of a high quality. Establishing pull in the system drives you to validate the need for the product, ensuring that work is not done that is not needed and then meeting that demand in the timeliest way possible without creating inventory. The Kanban Methodology encourages this pull of flow through the system rather than a push of the flow, this workflow builds responsible / respectful delivery of work to the next stage in the process, rather than just 'throwing it over the fence'.

The 12 agile principles as defined by the agile manifesto (https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/) build upon the previous lean thinking adapting it for software development.

They promote, individuals and interactions over process and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan. To me this sounds a lot like its roots, Lean. The 12 principles in my opinion, whilst I do not disagree with the message that they are trying to deliver could be reduced.

Without tackling all the principles, there are a few I wish to call out. Working software as the primary measure of progress, this principle can cause team members to become too focused with just getting 'tickets' completed and does not have any place for hypothesising, experimentation and learning. How does 'fail fast' and 'proof of concept' fall into the working software that I am to be measured by? Building projects around motivated individuals, prioritising face-to-face communication and continuous attention to detail, are 3 more principles that I consider to be good working practice of a mature software employee and possibly more a pre-requisite of a modern working environment that we should just naturally be doing.

One agile principle that I think stands above all others is that, ‘the best architectures, requirements, and designs emerge from self-organising teams’. I believe this is a really important principle and one that I feel advances the lean principles, as teams we should be responsible for our own workload, prioritisation and how to achieve the goals set forth by the customer. This should be something individual teams dictate, after all it is the team that will be held accountable for tasks not being completed.

To give some weight to my thoughts the agile principles are already being shrunk down, with 'modern agile' or 'heart of agile'.

Modern Agile: http://modernagile.org/
Heart of Agile: http://heartofagile.com/

The problems with Methodologies

When you have chosen to become more agile or are working in an agile way you will likely be working with an established methodology. But how do you know it’s the right one? I honestly believe that no methodology is perfect and this can often be an issue. Trying to adhere more to the scrum principles is not the same as being more agile, adhering to a methodology can often feel like you are going against the agile principle of being a self-regulating team.

Methodology’s should be treated as guidelines and not things to hold people accountable for not doing the 'task' in the right way. Treating any methodology as a guideline allows for blended (agile + agile), or hybrid (agile + good idea) ways of work, ensuring teams remain flexible to their working environment and self-regulating. Working in a Kanban way but want to promote more pair programming (Extreme programming), not a problem if the methodology is a guide and not a hard and fast rule.

Integration with the business or customer can be challenging if they do not know about agile and they are receiving emails, or involved in conversations about sprints, velocity, backlogs and t-shirt sizes. This lack of understanding can develop a lack of trust or confidence in those doing the work, which can turn into a lack of funding. Not talking methodologies to people and explaining without Jargon the agile reason for doing something can help build relationships, and can lead to non-agile people integrating with agile practitioners better. When we remove the focus from why we do agile to how we are doing agile we are adding a layer of abstraction between ourselves and the reasons for practising agile, we forget the motivation for doing agile and focus on the way to accomplish a task, which may not be in a very agile way.

So why focus on the principles?

Agile methodologies are a tool, like a JavaScript library or an IDE, and should be used as such. With this thinking we can see that all agile tools have the same tool kit, the '5 whys', Continuous feedback loops, customer focus, Transparency, to name a few. Focusing on the idea of why we do agile, customer focus, better deliverables, reducing waste, faster delivery, we can pick the best tool for the job, and not be limited to what a methodology says.

We can be truly agile by embracing the freedom agile gives us to do our job.

Whilst I know this has not been a deep dive into agile, its methodologies and the tools we use to do its job I hope that it helps remind people that we should take a step back from what we are doing and ask ourselves 'is this decision agile'?