My thoughts on Agile Development


I dont confess to be a authority on 'agile' , however in my last five years with various companies i have seen 'agile' becoming a buzzword  and a fad i.e. people say we do agile while they end up following water-fall model. I have learned from talking to people and understanding the challenges they faced and running scrum myself and learning from my mistakes.

sometimes people get up hung up in 'following the book to the last word' while they forget that it is "essentially" an evolution based on the current times.

what is 'agile development'

  - the only problem that matters here is that the time to market is very large for  water-fall / RUP blah blah model e.g. how would you manage your project if your time to project is 1 month or rather continuous , we can no longer afford to have requirement complete before we start design and design complete before we do development.  In other words the entire environment is continuous i.e. all stages need to react to changes as all of them are working concurrently in other words 'agile' development.

How do i get agile

  - people tend to condense the process into the small timeframe without adopting some of the principles of being 'agile'. let us consider the problem mentioned in the above paragraph and try to figure out how would we solve the problem.

• the first thing that it means that i am not going to have complete requirements before i design and develop. it means close co-operation with my product manager and my designer i.e. we collaborate on the product in an iterative process.
•  some people thing that agile means PM can give a completely new requirement 2 days before a release and expect it to get done.  to be fair to the entire "PM community" i think there are some PMs who get it and understand how it works  and some who don't get it. ( i am not going to get into why they don't get it) .
•  i can surely hear a lot of people cry out loud that what happens when it is a genuinely such a condition for e.g. an unexpected market opportunity.  to all those people out there yes agile is supposed to address this.   One of the most important features of being agile is  to instill the thought " ALL PARTIES  eng/product/qa/ops are equal stake holders in the project" , if your org does not believe in this then in my opinion you are not agile. coming back to argument , in such a case where all parties are equal parties to the project it means couple of things
• every body in the project recognizes the opportunity and willing to accept the change
• once consenus is achieved , it comes down to resource planning and scheduling and this is less of a problem in my opinion and needless to say "to put something in a bucket which is full, something needs to be taken out first"

 - make sure all the members of the project know what every member is responsible for , one cannot have mis communication when one is working on such short time projects.  have a daily scrum meeting.

• keep is small , i have been part of scrum meeting which run for one and half hours long everyday
• scrum meetings should be of the following , every team member needs to say only 3 thing

• what am i  woking today
• what i did yesterday
• am i blocked on something i am working. if there is a dependency please dont make that discussion a part of the scrum meeting.  

-  make sure you develop something, give a demo to all the stake holders of the project and then iterate on the feedback. giving early demos and collecting feedback is invaluable.

- MOST Important . RECOGNIZE that there is no single solution that fits all, a team is made of people and people are different in different teams and different orgs just because one worked in one project does not mean it will work everywhere.

• for e.g. if you successfully ran scrum in a startup with 3 engs and  qa, it  does not mean the same process applies for a large group where there are some 20 eng and 10 qa.  in this example dont hesitate in breaking up the scrum to multiple team scrums and have a representative from that team 
• understand that "agile"  means being "agile" ourselves. learn what works and does not work and tweak process till you get the desired effect.

- Lastly,  if you want to learn 'agile development' do the following

• get a book. after you read the book throw it down the drain or sell it on ebay, whatever you do don't ever touch that book again. sometimes i have a sneaking feeling that some books are ambiguous so that we can hire consultants who will explain it in lay man terms.
• understand what is the problem that you are trying to solve
• apply you analytical mind to the problem , in this way u will adapt the process to the problem instead of adapting the problem to the process.

would like to hear how other people adapted scrum to their projects.