I've worked in a variety of development environments, from the isolationist to the chaotic to the insane.

I've also seem to get involved in seemingly endless battles to improve the development methodology. It is something that interests me as much as the development itself.

What I've found is that every environment is different, and the things that work best are often informed as much by the business environment (e.g., how much does a bug really cost?) as it is by the technical environment and culture.

So while I can say that team programming, peer review and regular shotgun meetings are what I've found to be the most useful, I offer the following advice:

• Be prepared for the changes to take a long time to implement and gel amongst the team. Six months to a year would not be atypical. Let the business people in the company know what your ideas are, but also let them know that your ideas will take some time to implement properly and for the results to show. You will need the buy-in of the suits over a long time horizon, so manage their expectations: You are not going to cut development time in half overnight, but you should see a gradual but consistent improvement over time in coordination, estimation, output, and quality.
• Any methodologies do need a strong advocate. Every formal process takes time, and there needs to be a strong and informed individual to push back when business decision makers want to take shortcuts which may appear innocuous in isolation but which breed a culture of sloppy work habits.
• Don't be too inflexible. Every environment is different, and one development technique may work well in one shop and not another. Keep trying things, promote an environment that encourages constant and positive feedback, and keep the things that work and discard those that don't. Don't rely on a single development methodology, though you may favor one over others: No single development methodology is a silver bullet. Inform yourself and pick and choose.

Hope this helps :-)

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.