Freigeben über

To Agile or Not Agile

  • Artikel

I have been pondering over the Agile, Iterative, XTreme, waterfall and several other software methodologies. I think that each of them have their strengths, I have no reason to bash one methodology or pump some other methodology.
Personally, I really don't care about the methodology. I don't think it matters. Let me explain.

Since I started working about 20 years back, I always wanted to be organized and accomplish more. In one training class, 20 years back, the instructor said
"I know of no better idea than to just write down your tasks and prioritize". I heard it, I nodded. Since then, I have been trying to follow that simple principle.
I start using Outlook tasks and not really update them or use them as guidance. Before outlook, I used to purchase day planners from a reputed company
and I eventually left 95% of the days unfilled or unused. Then I bought a palm pilot. Then upgraded the memory. Then decided to switch to the paper based planners.
You get the idea. I am still looking for a methodology.

The point is that the methodology, or the means, is not the problem. "I" am the problem. If "I" decide to be more disciplined, a mere post it note would have
served the purpose. Well may be a $2 note book. The problem is that I imagine the most complex of situations, and imagine my self following the
discipline to the core and create all sorts of scenarios where I need to have more elaborate mechanisms to keep me disciplined. Some where along the line,
my focus goes form "I" to the "methodology" and one more year passes before I get really disciplined.

There is NOTHING wrong with the waterfall methodology. I am sure that if we send a bi-partisan committee they will find projects where waterfall is just worked fine.
There is NOTHING wrong with agile either. There are projects where it succeeds and there are projects where it fails.

But I BET that in both cases, the projects that succeeded would have succeeded with either methodology, and that they would have succeeded not because of
the methodology, but because of the fundamental discipline of how they conducted the business.

When it comes to software "engineering", there are some fundamental principles. Like Mr.Covey says in his "Principle Centered Leadership", there are some
fundamental principles when it comes to software engineering

  1. Have your requirements
  2. Have an idea of what you are building
  3. Develop the fundamental architecture of the components
  4. Have a release plan
  5. Write very detailed specs and design documents (sorry agile folks!). Spend time in making sure
    that the design is solid. The code should be a mechanical reproduction of the design (as much as possible.not taking a religion here)
  6. Don't pretend Quality is #1, behave so. Role model Quality as fundametal principle
  7. Take time to test - functional, API, Perf, Stress
  8. Fix bugs. Don't let service packs be the bug fix vehicles.

Fundamental, natural principles don't change. It is our never ending quest to invent schemes that lead us to believe that we can defy them - that blinds
us.

Let me tell you about losing weight. Atkins, South Beach, Nutri System? Or Eat Sensible and Exercise?
Let me go buy the South Beach Diet book. The girls on the cover page look beautiful.

Comments?

Comments

  • Anonymous
    January 22, 2009
    PingBack from http://www.clickandsolve.com/?p=547

  • Anonymous
    February 17, 2009
    The comment has been removed

  • Anonymous
    February 24, 2009
    Interesting :-). Makes me think. I do the same, search for tools that I think will keep me disciplined, but it never really happens!