Agile: Methodology, Process or Framework?
This is a question that often pops up on internet forums as well as real life. Lets start with the dictionary definition of the word:
agile adj 1 quick in movement; nimble. 2 mentally quick or acute. – Collins
Hmmm – so its an adjective. I'm not going through the definitions of the other terms in the title (all nouns!) but the following immediately spring to mind - purely based on the dictionary definition.
- You cannot adopt or implement agile
- You cannot follow agile
- You cannot enforce agile
- You cannot impose agile
- I’ll stop now as this could become a very big list.
So what can you do with agile?
At school we learnt that an adjective is a descriptive word applied to a noun (entity). Logically the only thing you can do with it is to become agile – unless of course you choose not to. Well that was easy, the answer is clearly none of the above.
How does an organisation become agile?
Firstly its important to recognise that true agility can only be acquired at organisational level. Having agile individuals or teams within an organisation does not make the organisation agile.
Too often organisations make the decision to do agile because of the successes of true agile organisations or simply because it is externally imposed. Without the recognition that becoming agile is a cultural shift that affects every aspect of the organisation and the way it does its business this can be a very difficult task – perhaps even impossible. The most common manifestation of this is management that refuses to relinquish the illusion of command and control. Adopt a bottom up approach at your peril – without the full support of management (and this includes their understanding) - an organisation has very little chance of successfully becoming agile. And agility most definitely is not just a development thing!
The number of organisations that miss this is staggering. Have a look on the job boards and see how many organisations require someone to implement or champion agility with the following attributes
- Must be strong on formal change control mechanisms – isn’t agility about recognising that change is inevitable and managing that as part of your daily life!!
- Certified <insert formal waterfall methodology> practitioner
- Must be experienced in enforcement of agile processes
- Must be strong on governance mechanisms
Of these governance is my favourite. What a beautifully concise way of describing command and control syndrome.
We will move to agile because I command it. However we will not lose control by ensuring that we have appropriate management processes in place and these will be based on what we know and trust.
Please don’t think for one minute that becoming agile means a lack of discipline or a loss of control. In reality it means exactly the opposite – but management must believe in what they are trying to accomplish. So if you are an agile coach, or assisting an organisation with the transition to agility start with the management team – and that includes the CEO. Just because they have expressed a desire to become agile does not mean that they understand agility or subscribe to its ideals. Common drivers for switching include:
- A desire for greater productivity – in management speak this can translate to how can I reduce headcount or even how can I reduce headcount AND achieve more than we are currently doing?
- To fix a problem – usually poor quality and / or a poor track record of delivery
- They have been told to do so
- An act of desperation – everything else we tried has failed so lets give this a go.
This does not make them bad people or mean that there is no hope. Many of their views and behaviours have come about through years of training and environmental influence, and some of these will need to be unlearnt. You do need to understand what the real drivers for change are and to establish the agility of the management team. Just because they engaged you does not mean that the don’t need help too! And its your job to provide that help.
So how does one become agile
No – I am not going to give you the answer. Many books have been written on the subject and frankly there is no simple recipe that will get you there. As a starting point we need to understand and embrace the agile manifesto (as an organisation):
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Don’t forget the last line – nobody is advocating that we abandon the items on the right!
It is also useful to think about our values. There are 5 widely cited values (borrowed from XP)
- Communication – this means talking and listening
- Simplicity – do what is required, no more, no less
- Feedback – give, receive and act on it
- Courage – sometimes you have to take risks. You also have to say and face up to those things that nobody wants to hear – or acknowledge. Your environment needs to foster this
- Respect – everyone can add value; even if their ideas are different
Here’s an interesting blog on the subject where the author extends these to include trust and transparency.
Which agile is right for our organisation?
Actually I am going to stop now. It’s a blog – not a book! Perhaps a teaser for a future blog…


Agile Pragmatism
Hi Sean ,
This is a great post , echoes many of my own thoughts. One thing I would like to pass comment on though,I am in a very large organisation that is driving towards Agility at a rate of nott's and as you state this is a very big change affecting every facet of the organisation.
We do have the senior management buy in, however there are many who take this mandate and try to enforce the change by enforcing the Jean Luc Piccard theory of "make it so". I mention this because it ties back to your point around the fact it is a cultural change rather than just a process change.
Having been involved in Agile for the last 11 years I am now one of the champions for the organisation. When I talk to people about becoming Agile the very list you have dot pointed for championing Agile is always included in my conversation.
There is one other point that I constantly preach as well and that is "Agile Pragmatism", being pragmatic about introducing the change and how change can be wrought in small increments. An example of this is on a recently we couldn't convince our business partners of the worth of committing full time resources for SME and Acceptance, now I could have thrown the hands in the air and said that's it the project can't go forward Agile. Instead I convinced them to give us a SME on call when needed ( obviously needed more than they could imagine) and in terms of acceptance ,provide us with acceptance people for a week at a preset time.
This meant of course we had to package up the release and put in a separate environment for them to look at ,we had to accept the risk of refactor and bug fixes could be larger ,however for the greater good it was worth it. The business team enjoyed the process that much that I pitched to them to join use one day every week , again the obvious risks applied.
Again I suggested that they would get greater benefit from joining us on a permanent basis and they agreed.The final upshot of this is that they have been assimilated into the process by being Pragmatic , and making change by stealth so to speak. This is only one example may others around the challenges of pair programming, TDD and so on.
Interested to hear your thoughts on this ?
You're absolutely right
Tony
Apologies for my delayed absense (and I have now turned moderation on cos I found loads of spam in here). Started in a new role shortly after starting the blog and became totally absorbed - also with a very large organisation: two in fact as one is the client and the other is the delivery partner.
The key is in being agile rather than blindly following a process. I worked with an organisation that had major quality and delivery issues, primarily because they had always paid lip service to quality and proving the value of testing is always the hardest business case to stack up - until of course it goes horribly wrong. They enthusiastically adopted Scrum but there was no way on earth I could ever convince the exec that we could improve quality by abandoning a formal (and rigorous) QA phase. At the same time I realised that I had to convince them that testing was something they had to invest in.
To get the ball rolling I introduced a "QA" cycle that always lagged the "development cycle" by one sprint. This meant I could get much needed funding for technical resources and the opportunity to prove that testing was not a seperate activity. From day one I assigned half of the new test team to scrum teams and the balance formed what I termed the "regression team" which did lag the scrum teams by one sprint. Of course this was not agile (another term I hate). Initially the testing on a legacy suite was all manual because the company had always shied away from the cost of implementing automation. This team did manual regression testing in the beginning but most of their real task was building the automated testing framework, and as such became a separate scrum team in its own right.
Our first major release was the best the company had EVER had in terms of quality because real testing was happening in sprint (and we introduced TDD as well). This was the opportunity to focus this team on the automation suite and spend less time on testing other teams work. In less than a year (and once we had fully automated regression testing coupled with continuous integration) I was able to integrate the members of this testing team into the regular project teams and get rid of the pipelined activity.
The pitch to the executive was that we had improved our processes to the point that we could do the same testing earlier which would allow a shorter time to market. Although the teams were really benefiting from TDD and automation I played this down for the benefit of the executive as there was a bit of an economic crisis going on and the very un-agile management team would have responded to the news that unit and regression testing were now automated with "Great - how many heads can we lose, surely if our testing is automated we no longer need testers".
Sometimes stealth is the only way to introduce change, and very often the only way to gain acceptance of something new is by hard evidence, and the easiest way to provide this is by producing the results.