If you have been following my series on agile development then you will have some understanding about the concepts behind the terminology. My article on Test Driven Development covered one aspect of that practice within an agile process. The article on standup meetings covered one aspect of how communication between team members could be carried out, as did the article onpair programming. Sprints looked at one form of timeboxing to constrain what features are implemented in an agile project, while the article on Kanban looked at one particular flavour of an agile process.
Hopefully these articles have helped the reader decide if a) agile will work for them and b) if they are already working in an agile way. However these articles do not attempt to answer that question for you. If we look back at the original article we remind ourselves that there are no proscribed processes or practice which make your team agile, and yet without using some of the practices examined in the above articles people would not consider your environment to be agile.
So what does being agile really mean?
Well the important word in all this is agile. The whole agile movement exists because that was exactly what software development wasn’t. In the book Introduction to Agile by Sondra Ashmore, Ph.D. she covers a brief history of software development before the rise of agile. The whole point of the agile movement is about delivery. Delivery of software which meets your client’s needs, and which is delivered within a time frame which also meets those needs.
This is why practices such as TDD are important, because they help to ensure the quality of the software you are delivering and help to give a more robust framework for change. If you haven’t got started with TDD then the book Test Driven Development (The Addison-Wesley Signature Series) by Kent Beck, one of the founding fathers of TDD is a good place to start.
In my opinion if you are delivering product at regular intervals and using practices such as TDD to ensure robustness, and iterative releases to ensure correctness, then you are being agile. The whole point is to deliver product which will delight your customer. If you are not doing that then maybe you should look at the processes you use to deliver your software.