Asking for the wrong things
A lot of people ask for repeatable and efficient development processes. One of the biggest arguments against many of the agile practices is that they introduce inefficiencies:
“Refactor the codebase? But it is more efficient to just do it right the first time.
“Write tests while I code? But its more efficient to write them afterwards when I know what to test”
As for Repeatable, that is the Holy Grail of process to many managers. If they can have a repeatable process then they can just write the plan, kick off the project, and watch the software being delivered.
The problem is that in the quest for efficiency and repeatability we can loose the more valuable qualities of effectiveness and reliability.
No amount of efficiency will help if you are developing the wrong thing and, brutally, the only repeatable process most software shops have mastered is when to give up on the specified process and get on with shipping something.
When you are thinking about your process forget “repeatable” and ask yourself: “Will this reliably deliver what we want?”
When think about some practice ease up on how “efficient” you will be and ask yourself: “By doing this will we be more or less effective?”
November 14th, 2006 at 6:23 am
After working with Agile methods for many years I have come to the conclusion that they do not accurately encompass the relationship between the development community and the end users. I have always failed to be able to get the users to buy into the investment that they need to make to ensure the true agile process. The technical details of the process pail in comparison to an end user community that wants software delivered yesterday without significant investment. Also unit testing is poorly defined for many developers which means that coverage can either be poor or meaningless. As a process for certain types of projects I would recommend it but in the face of tight deadlines software development processes tend to fail (i.e. diverge from their principles).