The debate over capital A vs small a variation of agile continues – and is an interesting one. Let me first explain it for those of you not familiar with the difference.
Capital a Agile is the formal set of methodologies that provide structure to the concept of agility. These methodologies have given shape to the Agile manifesto (http://agilemanifesto.org/) and the 12 principles (http://agilemanifesto.org/principles.html) that had initially defined agile. The methodologies include Scrum, SAFe, Disciplined Agile etc. – they provide a streamlined way of following a defined path to achieve the goals of a project. Small a agile on the other hand is just the idea of being agile, not following any specific methodology – but charting your own path while staying true to the Agile manifesto and the 12 principles.
As you can probably guess – capital A gives you structure, small a gives you freedom. Both have their benefits and drawbacks – and both have their supporters…
Here are my thoughts –
Defined frameworks are very important. I do not agree with the idea of not following any defined practice at all and leaving everything for the team to decide. It can work, but you will need a team of superstars every single time to pull it off. Not something that is not always practical. Most teams, especially if involved in any project of significant size, will welcome some structure. Trying to be agile in the absence of any given structure, I believe will be an additional burden on the team.
Having said that, I feel it is unfortunate how many teams tend to get obsessed with the specific rules of a methodology and in the process often ignore the true agility principles. I have seen practices that were originally designed to avoid older ceremonial processes somehow themselves become ceremonial and counter-productive. Using sticky notes during spring planning is a brilliant idea – but refusing to use anything else, even when working in a remote, distributed team – is just not smart (yes – I have seen it happen).
I look at agile processes as an evolving set of best practices. Evolving as a general body of knowledge, as well as within the confines of an organization. The manifesto has brilliantly set some guidelines for what we should be valuing when we set out to build products – namely, focus on customer needs, collaborate across teams and produce value (in the form of code) as quickly and as often as possible.
I have a lot of respect for Scrum, SAFe, Disciplined Agile and other such methodologies – agile would not exist without them. Agile concepts and the practice of agile exist today because these methodologies have given shape to the core ideas and made them real. My own journey through agile would not be possible without the structure these methodologies provided. In the early days, Scrum (https://www.scrum.org/) and Extreme Programming (http://www.extremeprogramming.org/) clarified and made the concepts real for me, SAFe (https://www.scaledagileframework.com/), LeSS (https://less.works/) and DAD (https://disciplinedagiledelivery.com/) helped scale the concepts and made them applicable for the enterprise. … but none of these, I believe is a one size fits all solution. Instead, they are treasures of knowledge that are there to be drawn from as you shape your own way of doing things.
In my mind, the discussion should move from the debate between capital A and small a to focus on being agile, being nimble, being responsive by learning and adopting best practices from the rich body of knowledge provided by the various methodologies. In other words – don’t try to ‘do Agile’ by doing every thing as described in a specific method – whether it makes sense in your situation or not, but be agile by learning, tweaking and implementing best practices gleaned from the established methodologies.