We have to fit our agile development projects into the larger corporate IT process. The way we have done that is to define so-called “engagement models” that define the interaction between our agile teams and other IT groups on which they have dependencies, such as the security group, the database group, and so forth. Some of the other groups have learned to like working with the agile teams and they are very responsive. Others are more traditionally-minded and drag their feet. That’s the reason we have more than one engagement model – one for “nice” engagement and the other for “not-so-nice” engagement. ;-)

There is a point beyond which you can control what other groups do, and a dependency on one of them may cause a delay in your project. It’s going to be that way for a while, until agile and lean methods take a larger share of mainstream IT work.

Hang in there and keep doing the right things!

I’d pretty much through a royal fit if they tried to lock down developers that much. I’ve been helping one of the QA managers for the longest time for them to get the rights to install things themselves, but since they’re not developers the business treats them like they work in our call center and are not to be trusted.