Agile can mean more process

I used to work for a government customer that had (has?) a hideously bloated and rigid process for building software systems, that completely forgets about the actual building of it. I recognize and appreciate the parts of that process that have to do with project selection and budgeting and the like. However, it has completely glossed over the building of the actual software. In a 3 year schedule template, only 30 days are devoted to actual development. It's inside out. It also doesn't work.

Anyway, I was in there before trying to sell agile processes- and basically failing. It was hard enough to get them to buy into iterations, becuase their whole mindset was based on control gates as the measure of progress. Of course, the only control gate with any teeth was "user acceptance review", so you had to wait until the bitter end of the project to find out how far things were off course.

Now I am realizing that the agile process I was trying to introduce need to be sold as MORE process, not less, as I had presumed. We are really addressing massive gaps in their structure. The problem becomes layering this inside of a existing framework of control gates. So, if we have a systems requirements review, the waterfall methodology suggests that we cannot pass this control gate until we have all of the requirements gathered in specific enough detail to begin design. Of course, this is an out of control gate you just sail through, unless your reqs happen to tramp in someone else's turf, in which case you have to fight to have a widget in your app, because some other project is in charge of those types of widgets.

The real mindset change is, after a certain point, replace control gates with measures of actual progress, such as running features. But how do we know if the requirements are right if we don't have a requirements review control gate? Well, first, the control gate never did work, so maybe the requirements review=the acceptance test. The only control gate with real teeth is the one we should use. How do we validate the design? Performance test it. By bringing these tests earlier in the cycle, I feel like there is a way to actually evolve the current process, rather than to blow it up.

Agile is scary for lots of reasons, but I think they are good reasons. It's kind of scary to say that you have to have working code early enough to do an acceptance test on it at the beginning, but that's exactly the kind of scare that is need to ensure quality gets built in from the start. It's kind of scary to give up control gates, but what about replacing these control gates with ones that actually have teeth? It means you might fail earlier, rather than being able to coast along for a long time without having to show results.