Whenever I happen to interact with a team that is said to follow Agile, the conversation usually starts with asking the question –
‘What do you do differently?’
The answer is something that is not uncommon for most of us and we keep hearing this…
The first and foremost response invariably will be:
‘Well, we have Daily Standup calls ….’
‘Anything more?…’ – you are curious.
After a pause, you hear them saying,
‘… Sprint, we work in iterations …. And ….’
Sometimes, they hurriedly say, “we don’t do documentation!!!!’
If you probe little deeper, you often hear them reluctantly saying
‘Hmmm ….. See, we are not doing true agile…. but something … called Hybrid Agile!! ‘
‘Hybrid Agile’?
That is – ‘Analysis and Design in Waterfall, CUT in Agile and SIT in waterfall…’
‘Something like Agile Fall … Scrum Fall ‘(the word ‘fall’ – here, is the substring derived from ‘Waterfall’).
Recently in an agile conference, during a casual interaction, one of my co-participant was sharing an incidence where their customer had asked the team to build features using agile development model. Without any clue, and the team responded to this customer’s request by renaming the project roles in such a way that the development model appears Agile.
The role PM was changed to Agile PM, Architect – Agile Architect, Tester – Agile Tester and so on without any fundamental change in the way the development is being done!!!
I was sharing this with one of the agile thought leaders and an industry veteran, alongside the same conference.
He quipped, “Knowing the name of something, and knowing something are two different things!!!”
No wonder, a lot of mix-match terminologies are used in the industry today.
First of all, does the term Agile – denotes or represents a Methodology? Let us look back…
The history of IID (Iterative and Incremental Development) dates back to 1950’s. Many prominent software engineering practitioners and thought leaders from succeeding decades supported these.
1950’s? This may sound ridiculous and unbelievable?
It will be even more surprising to know the original article in 1970’s “Managing the Development of Large Software Systems” that ultimately became what is popularly known today as “Waterfall” model, recommended a different approach from what has devolved into today’s single-pass, strictly sequential, Analysis, Design, Development, and Testing Phases. In fact, the article recommends a “Do It Twice” philosophy.
See this extract below from the paper:
“If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operations areas are concerned.”
Late 1980 and 1990’s saw proliferation of IID in various forms such as Scrum, XP (eXtreme Programming), FDD (Feature Driven Development) and so on.
In February 2001, a group of 17-process experts, proponents of DSDM, FDD, Scrum XP and others who are interested in promoting simple modern IID principles, met at Utah. From this meeting came Agile Alliance (www.agilealliance.org) and the popular phrase ‘Agile Methods’.
Agile Alliance, framed 4-agile values that is expanded those values into 12-agile principles together known as Agile Manifesto.
All those modern IID methods and any other development methods that conform to the agile manifesto are known as ‘Agile Methods’.
Let us try to understand this using a simple analogy.
Most of us are familiar with Codd’s 12-rules (and would have definitely faced this question in one of the job interviews!!!) defining relational databases (RDBMS). Those database products which satisfies the Codd’s rules are known as relational databases (RDBMS).
Similarly, a development method is said to be Agile, when it supports the Agile Values and Principles (Agile Manifesto).
Therefore, when a development is said to follow Agile, the development methodology – or – methodologies should be carefully chosen – such as Scrum, XP, Kanban etc., which are known as ‘Agile Methods’.
Agile – is a term that expresses values and principles, and not methods and practices. There are many methods and practices that support the Agile Values and Principles.
Exploring alternate software development approaches for over two decades. Deeply involved in creating empirical software development models for Data Warehouse, Business Intelligence and Analytics. Enterprise Agile Coach having special interest in Systems Thinking and Organisational Design.
