David comments that agile is about discipline. I could not agree more.
Having encountered organizations that failed in a previous attempt at agile, one consistent story seems to be that agile was brought on board as a developers initiative in response to ‘lack of process’ complaints. However, agile seems to have been chosen by those developers as an answer not to up their game, but to give them an excuse for continuig with a low discipline approach to development. It’s the agile as a pseudonym for “we don’t want no stinking engineering practices paradigm”. It is for me, a big reason why agile has a bad name with some CTOs.
It is usually a shock for developers at those organizations when they encounter genuine agile, with a high-discipline approach to software engineering. That is not what they believed it to be. A lot of them balk, commenting that the high-discipline approach cannot be agile, because it seems to involve them in a lot more software engineering than they were used to. A lot of them resist BDD style approaches as taking time which they could use to deliver, at planning and retrospective sessions as getting in the way of ‘writing code’. For them agile means ‘everyone gets out of my face and I hack code as fast as I can’. There is often a corollary here with developers who have a background in waterfall projects that get handed over the fence once live. They never had to support the project once delivered, so only care about ‘time to market’ over ‘cost of owneship’ so cannot see the value of these practices.
The problem here is usually predicated not by classical waterfall approaches but organizations with homebrewed approaches to software engineering. (By homebrewed by the way I don’t mean the adapt the methodology to fit the project approach of the Crystal family, I mean the voodoo like approach of a collection of rituals to software delivery whose purpose or origin is usually shrouded in time or some incident). The term agile refers to the ability of the methodoligies to react to feedback, not their process cost by contrast to those homebrew approaches to development.
The problem her eis often that the term agile (or even lean) don’t recognize the fact that these homebrew methodologies are usually lightwieght and that agile practices seem heavywight by comparison. Some term that implies high responsiveness to feedback might well have been better, because it is more honest at describing their benefit.