One of the tasks my current team was given when it was started was to do things “the right way.” In other words, the company felt like maybe they weren’t /really/ practicing XP, and perhaps there was a way to crank it up to 11.
However, yesterday my pair leaned over and said, “We’re only as agile as our process”. Unfortunately he’s correct on that. The two of us do everything possible to crank XP up to 11 there. We are in constant, open, honest communication with our customer. We test-drive everything. Our customer writes Fitnesse tests to express requirements. We don’t have a big tracking process, we use stories (index cards and ProjectCards) for everything.
But, because we’re in a legacy environment, we are stuck with their process. Want to make a change to the Database? Sure. Just create a tracking ticket, then go over to the DB changes application, making sure to fill out everything correctly. Eventually a DBA will review your changes and “approve” them to go to the Test database. Then you go back in, mark that as complete, “promote” the ticket, and then once you get approval you notify change management who then also gives the green light. And then you can make your change.
For an /alter/ script. That adds one column. To a table only our app uses.
Or, maybe we want to try out a new framework, or a new version of Eclipse, or NetBeans, or Rails. Sure! Just create a tracking ticket, making sure to get approval from your manager. Send it to our Ops team. They will download it, create a secure network which doesn’t let you access the other network, place it there, and let you VNC over to a machine to play with it. Oh, you want to use it in production? Well, make sure to get the approval from the Change Management team, and the Ops team, and management and, and, and….
Or production deployment? Make sure to get QA approval to Develop, and Alpha, and Beta. And then *one* person in the whole company is allowed to move it to production. One. And we only do go lives once a day. Hope it was right!
Ed Gibbs calls it the audit excuse in a recent posting, and I think that’s exactly what it is. We are scared of the machines being different, of having something that every single person might not understand. But in XP, you can’t solve the problems with policies. You can’t solve them with tools, or software. Nor can you solve it by management. You can only solve problems by having the team recognize it, talk about it, and discuss ways to fix it. In other words, communicate.
Communication is the lifeblood of an XP team. Between developers, between the customer, between teams. Unfortunately, it seems that in a world of cover-your-butt, we are happily willing to trade communication for bureaucracy and policies and paperwork. Hopefully we can have an impact on that before it becomes really bad.
Ouch, sorry to hear that you’re in one of those places where developers aren’t allowed to try out tools on their own and have to have a seperate group download and validate them. These tend to be people who only know a bit about Windows networking and look at you funny when you mention Python or CVS.
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.
Our company is also a legacy environment, with an IT department of about 1,300 people of whom 70 belong to our group and about 15-20 are proficient with XP. A drop in the proverbial bucket.
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!