More Agile

Burst out laughing when I read
“Soon all of our singletons were composite, we could use the factory method on our abstract factory to get the prototype of the builder which would make a proxy for the decorated adapter that acted as a facade for the visitor which took us to see all of our singletons”- http://jroller.com/page/rolsen?entry=turn_it_up_to_11
Since it reminds me of a certain project I was in where the chief designers had obviously come out of a design patterns course and so there were *Factory aplenty which then lead to the creation of a class named FactoryFactory and the clients of this API who ofcourse had their own factory came up with FactoryFactoryFactory. Ok the last class is fictional , but the one before that is an actual class.
And so yes the latest rage is Agile and Scrums and what nots. I remember reading Kent Beck’s book on extreme programming about 5 years ago when agile had not yet caught up here in India, agreeing vehemently on the accept change and disagreeing just as vehemently on pair programming (some people interpret this as side by side programming, a practice I wholeheartedly endorse , and not just for technical reasons, its how I met my wife to be :-) )
As the years went by and I saw more and more of the strict waterfall model , the im not going to start design till requirements are signed of, im not going to start development till design is signed off, I realized the agilest were right , waterfall like practices are no way to run a project. Agile was the way to go. And though we didn’t practice all the various XP practices or Scrum or whatever, most projects I worked on were pretty much flexible, with changes being accepted after the date for code freeze (which magically thawed)
Oh just to clarify , we are a service/project oriented organization , providing services to various clients. The client I work with now has decided to go Agile in a major way and to impress the client agile training is now mandatory for everyone in our group in our organization. And ive kept up with some of the articles that the agilists keep publishing. And so the inevitable conclusion. There is no practice in the world that people cant screw up.
So lets see where do we start.
First the proponents of agile itself. While they make the right noises (Each process must be tailored to what works for you), the answers given most of the time is ,(to quote cedric beust) “if you aren’t getting benefits from agile , you aren’t doing it right.”
Second the insistence by some on absolutely silly practices. Like Code the test first before you write the code. I cant and don’t want to code tests that don’t bloody well compile , I have to define the interfaces and classes implementing those first atleast! Though of course testing is good , automated tests are better, unit tests are ok, mock tests are ok, Integration tests are worth their value in gold. But try getting some agilist to talk about tests other than unit tests.
Then we have the silly rules that follow from the above. You must have 90% coverage in your tests cases, otherwise code is rejected. Heres a thought experiment. Write a function doubleIt , return the value 4 always and write a test case which passes in the value 2. You have voila 100% coverage. Beat that. No need to write more tests. If you impose silly rules , developers will work around them.
And then we have the other problems. Daily status calls, not exceeding 15 mins. Must be at the start of the day. Ok cool. Umm the delivery head is US based, the customer in UK and the dev team in India. Whats the start of the day? Oh agile doesn’t work so well for distributed teams! Well what do I do then go back to waterfall? Stupid.
And the ofcourse the famous if you aren’t doing practice x, you aren’t agile.
I think I prefer the time when in a project of duration of 1 month you could relax for 15 days and then work double for the next 15 instead of work uniformly for the 30 days.
Though people may say that quality in the latter case is better, I don’t think that’s necessary.
I don’t think agile works in the real world. Distributed teams are a fact of life. Multi vendor projects with conflicting interests are a fact of life too. I suppose agile would work with a closely knit team. But that’s fast becoming an exception in the areas we work.
And with new processes and positions (like agile coach) the Agile methodology is becoming as rigid as the other processes.
And a final thought whats remained the rule in software , good people can make any process work, incompetents can make any process fail.