One thing that has changed for me over the last few years is that I find myself working with people for whom agile has become the norm. Indeed, I have even begun to work with people who have never done waterfall. My frames of reference are changing; I am starting to find that comparisons with waterfall don’t carry very much weight these days.
Ten years ago, I was working as a test manager on multiple projects, some waterfall in delivery approach, some with agile aspirations that were experimenting with elements of Scrum. I wrote a piece entitled “The Essence of Agile” to see if I could get to the heart of this new way of doing things.
Here it is:
"Essence of Agile" sounds potent, doesn't it?
Since the Agile Manifesto is already a succinct summary, then its essence will surely pack a powerful punch.
It sounds like something that I might be able to sell. So, before I go any further, I'd better think up some tag lines for my marketing campaign.
"We build software. We build it fast. We build it right. That's agile."
I like that one because: It's snappy, it's bold and it delivers the message that we know what we're doing.
"We build software. We deliver it incrementally. We adjust when we need to. That's agile!"
I like that one because: It's honest, it empowers the customer and it delivers the message that we know what we're doing and are willing to discuss it.
"We build software. You may not get what you want! You may not pay what you want! But you'll get something! THAT'S agile!!"
I like that one because: honesty, humour and exclamations! Knockout!
However, building software is an exercise in engineering, not marketing, so maybe I should put some effort into the product itself. Or at least consult Wikipedia on the definition of the word “essence:”
"...essence is the attribute or set of attributes that make an object or substance what it fundamentally is, and which it has by necessity, and without which it loses its identity. Essence is contrasted with accident: a property that the object or substance has contingently, without which the substance can still retain its identity."
As a way of building and delivering software, “agile” looks to me like the application of common sense in a sequence of coordinated actions designed to deliver a pleasing result.
In the whole short history of software development, we may well consider that all methodologies have been attempts to apply common sense in a sequence of coordinated actions designed to deliver a pleasing result. So, it may be argued that agile methods are simply the natural outcome of smart people working together to build useful software at a reasonable cost.
If we were to pay someone to estimate the dollar cost to businesses and governments of failed software projects, their fee alone would make us yelp.
So how loud would we be yelping if and when we knew the dollar cost of failure?
Maybe we could estimate it using the “software project under-estimation” method: Think of a large number. Now double it.
This is to say nothing of the impact to human lives, societies and communities of failed software projects.
The attributes that make agile fundamentally what it is are: "common sense" and "coordinated action."
This is in contrast to pure common sense which can be suggested, mooted, opined, considered and even written down without ever being translated into a verifiably actioned result (i.e. saleable code).
This is also in contrast to pure action whereby 10 developers or two architects or maybe one developer with a smartphone start to "bash" out what we all hope will one day become saleable code, whilst a project manager and a handful of business analysts engage in long and detailed discussions with the people who want the software built.
Somehow, not everyone is quite exactly available at the same time, so they fly around a lot and talk about how the software will look and review their decisions. Those decisions are then re-reviewed and re-decided with the provision that any decision made can always be unmade, and then made again later, because that is what agile is all about.
Fortunately, the developers never actually meet the business analysts, so they are able to get some real work done without having to refer to outdated and changing requirements.
This is great news for the testers who are able to catch up on their blogging commitments, speaking tours and internet-based self-teaching programmes.
The essence of agile is direct and frequent communication based on a combination of data about how we are measured against what we’re aiming for. The goal in this communication is to evaluate what we did, what we need to do next and what is preventing progress.
It sounds simple, but communication is the key, and it is the hardest component to perfect.
What is useful about the agile approach in this regard is the emphasis on regular, focused conversations in a facilitated format.
We constantly have to check our assumptions and agreements with each other. Have you noticed how easy it is to go off track and how quickly it can happen, even when everybody “knows what they’re doing,” the team is “experienced” and the client “knows what they want?”
In fact, in those cases it is especially easy to get side-tracked. I may know what I’m doing, but is that helpful to our goals right now? The team may be experienced, but what are the lessons of that experience that are going to be useful this time around? Do we have the skills, willingness and courage to learn what is needed as we go? The client may know what they want, but have they asked for what they want? And, how much control are they expecting to exert over what can change over the life of the project?
Taking daily doses of the essence of agile minimises the key killer of software project value:
Doing the wrong thing at the wrong time even if we do end up getting paid for it.