Agile or Not-To-Agile
All of you had definitely heard of a buzzword “Agile”. The mostly used words whenever some geeks discussing the development approaches, processes, management style blah blah blah. You will hear these terms Agile development, Agile design, Agile modeling, Agile testing, Agile project management, Agile roll out planning, Agile decision making, Agile Scrum, Agile languages, Agile database, Agile programming, Agile assembly, Agile game development, Agile thinking, Agile usability, Agile IT… You must be “Agile overload” now 🙂
I have all my sympathies with this word as its been used wrongly most often. Normally its being used to defend when someone is trying to hide his mistakes of violating company’s policies or processes etc. When I finally digged into real details for Agile after hearing a lot of differentiating opinions, I thought to share it with all of you as well.
First of all we should know who started thinking about Agile and what were the principles upon which its foundation had been built. In 2001 seventeen software anarchists met to agree upon the following principles that was later recognized as agile. These values are phrased as preferences for one aspect of software development over another:
- Individuals and interactions over process and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
For complete details, refer to this web page http://www.ibm.com/developerworks/rational/library/mar07/pollice/index.html.
Is my project Agile?
After taking a look at manifesto, still what project should be regarded as Agile or non-Agile? Secondly, may we designate some part of a project as Agile and the rest as non-Agile? Does implementing continuous integration and unit test automation makes my project Agile? There are a lot of questions. I think we may come up with something like:
- You have frequent releases and deliverable.
- You welcome and manage change requests.
- Larger projects changing into smaller applications is also a possibility you need to provide for.
- You work closely with the client and/or business experts to provide a real business solution.
- There are no fixed bids.
- You wanted to be flexible and your client also wants the same.
May be you can add a couple of more items to the above list. The point is to know for yourself do you wanted to go for Agile and then really go for it. Remember one thing always “its not about Agile, its about success” as says Gary Pollice.
Know for yourself what are the drawbacks or using Agile or let me re-phrase, when Agile should not be used:
- Do not use Agile if your team size is more than 80 and increasing.
- Do not go for Agile if the management style is not Agile. If the management is bureaucratic and you wanted Agile, you will definitely be pissed off.
- People are inflexible and/or unable to react to change, using agile will be too hard for them to follow.
- Stakeholders are unwilling to be involved actively. They like to invest time to make decisions.
At the end, before taking any decision do learn about it. Read this story about 6 blind men and an elephant, if you have not already read. As you take a decision think twice about this story to reach towards a good conclusion 🙂