Prasanna's Diary

I happen to remember my brother and his comment as I write this. This was when he had just finished his doctoral thesis, he said "When I finished my bachelor degree, I thought I pretty much have a good grasp on computer engineering having spent 4 years in it, when I finished my masters I realized that I may not know all of computer engineering but definitely compilers, but now that I have done Doctoral work, I realize that I know nothing in Computer science!". He has been one of the best persons I have seen who can provide a simplistic yet strong conceptual view of anything that is cryptic. The key point is as you move up the knowledge maturity, the softer tendencies and philosophies of being human takes over than the actual knowledge itself. If you take Software Engineering process, I see a similar view on maturity and see Agile taking that paramount step in the progression of Software Engineering Process. Software being a Knowledge based workshop, people come before process...

The question I keep pondering, "when do you use agile?". "can you use agile for Fixed price projects?" is another question that is being discussed frequently and recently in Agile Alliance. Well, read on my thoughts ... You should use agile when you cannot define requirements to the last line, when you are not clear exactly what you want and these wants potentially change depending on what you see. It is ironical that more often than not, this is the case. Hence you should use Agile more often than not. When the requirements are in various levels of grey, agile works very well - like a dream. The key there is that details are expected to come later but commitments are expected without the details. If you try to get the details in such a case, you are force fitting a wrong peg. It is in such situations, teams should accept the shades of grey and work towards achieving business results. Will they end up achieving exactly what they want - yes. The reason is simple - no...