We have a large enterprise application where projects are scoped designed and finally coded using a formalized waterfall process. I am often given code changes for non related initiatives just because they are in the same section of code. All initiatives must be turned over at the same time. Development team also has little say over scope or delivery time line. We are not able to talk to the users we must go through a group of requirement gathers who don’t know the business.
Does any one have any advice on how to implement even the smallest of agile techniques to such a entrenched environment.
At least you could start writing unit tests, or even – as much as circumstances allow – Test Driven Development yourself (possibly spreading the ideas among your fellow co-developers too). You can change a lot without management even noticing anything 😉
Of course, in an average or better place, people in the management are not completely stupid. Over time, when you have managed to raise awareness about these issues among the development team, you (as the team, collectively) can talk to upper management too, and convince them to take steps toward the right direction. Start small, get concrete results, and build on them – and build leverage by finding allies both in the dev team and (as much as possible) among management and users.
Very often certain processes are followed only because “we always used to do it like this”. If you can show people that there are better ways – and prove it with convincing arguments – you have a good chance of succeeding. Note that management and users need quite different arguments than developers. You can try making rough cost-benefit calculations (or google – I am pretty sure there are lots of stuff on the net about these). I also remember there is good material about this in Kent Beck’s first XP book. You can also collect bug statistics which over time (hopefully) show that features developed the agile way have noticeably less defects in later (integration test or production) phases. (For this you need a defect tracking system, if you don’t already have one.)
Another useful tool is asking questions. If you something – a document, a way of doing things – you don’t understand, dare to ask questions:
Often people just take things as “given”, but when you start asking for causes, you may find lots of interesting things… and ideas for improvement.
A very useful agile tool is retrospectives. After each iteration (whatever it is called in the actual process) the team gets together and brainstorms about
This may be fairly easy to get accepted by management, and is a good way to start positive changes. The most important thing is to wake up and activate people – to make everyone realize that the success or failure of the project is (at least to some extent) in their own hands, that they can do something to improve the situation.