MikeBD

weblog for MikeBD.com. Musings of a 24/6 techie (Software Architect / Technical Manager) family guy struggling to find meaning, balance and strong design / implementation supporting excellent user experiences.

Your Ad Here Your Ad Here Your Ad Here

Thursday, August 07, 2008

Agile Software Development: an Answer to Procrastination?

A recent LinkedIn question on Software Estimation and Agile Methology included a concern that Agile could lead to Procrastination. I believe otherwise as detailed below. What has your experience been?
Software Estimation and Agile Methodology

I am new to Agile Methodology. I am working on a project which is following Agile. I have the following questions:

1. What are the estimation techniques for Agile?
2. Typically which type of Projects use Agile?
3. In the name of Agile, can people procrastinate every single decision during requirements gathering? For example, we know what is expected but we don't know the most atomic level of the requirement. Say, I know I must build a webpage, but I don't know the validation of the webpage.
My Response:
I think Agile principles can be an antidote against procrastination. I would agree with the thoughts expressed in this post. If you continually drive to keep the design and implementation as simple as possible and don't get overly concerned with anticipating potential future needs, there is nothing left to do but build what you know is needed now.

This hinges on the fact that scope is always negotiable as long as quality remains consistently high. Therefore, developers can feel confident delivering features as required without excessive buffering of estimates and over building solutions just in case something may be needed in the future. When and if it is needed, it can be built, and the customer will defer other scope items because they have learned to trust the development team due to consistent and frequent delivery with high quality.

You may appreciate some of the points made and links posted on my blog entry which captured the introduction of Agile practices at my company.

Another important factor in your scenario is the provision of a "Customer in the room". The process works best with a high level of interactivity between developers and end-users or a suitable surrogate that can effectively direct the developers through the micro decisions (like field validations).

Many businesses balk at providing a true customer in the room because of how valuable their time is. I think this is short-sighted and would always expect better results with direct customer interactions vs. large formal requirements documents.

Labels: , ,

0 Comments:

Post a Comment

<< Home