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.
In my experience, large enterprises are concerned with RISK, PREDICTABILITY, and MEASURABLE RESULTS. You'll have an easier (though maybe not easy) time introducing Agile if show how it aligns with those metrics better than existing practices.
Make it possible to ship often, even if you don't do it yet: Leverage CI tools and automated build scripts to build and package your application. This way you're primed to capitalize on any opportunity to incrementally release new code that might come up.
Measure your productivity now so that you have a baseline: The more you can measure the better.
Project the changes in these metrics under an Agile process: For instance, in most cases the sooner we find a bug the easier/cheaper it is to fix, so benefits from TDD and rapid releases to QA should be easy to quantify.
Start small: You may have a waterfall schedule handed to you, but you can still break that down into iterations, so do so. Get your engineering practices in place, then start trying to adjust process. See if you can try Agile on a small auxiliary project as a proof of concept.
Find a sponsor: Try and convince someone higher in the pecking order than yourself of the merits of Agile. Engage their help in framing the "Agile vs. Waterfall" arguments in terms familiar to the decision makers.
Be patient... it may take time to see results.
... or don't. If you're deeply interested in Agile and are getting zero support, find a new job. Yes it's rewarding to effect change from the belly of the beast, but it's also rewarding to work with people that share your ideas about building software.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With