Development Process

Tonight I was asked some high-level questions about development process. I wound up responding w/ enough material that I thought I'd share the thoughts here for broader consumption.

Hey guys,Please  feel free to ignore this email but I'd extremely appreciate some advice  if you have a couple of minutes.  I am trying to compare best practices  for teams over 10 programmers to determine what software development  methodology has been the most productive for your company but at the  same most fun for your team.  If you have time I'd appreciate answers to  the following:1) Software Development Process used (i.e. Scrum,  XP, custom)

"agile" (no scrum)...  weekly iterations/sprints (no standup). have driven/done xp (pair  programming mix) as well; I'd only go this (xp/pairing) route again if I  were in a more supportive ecosystem (e.g. SF).

2)  Do you track # of hours programmers work in a project?

never.  bad idea IMO.

3) Do  you have a QA team, if so how many?

no. though  I've considered one or two QA folks... it'd definitely be nice to  objectively do white/black box testing outside of dev. we're pretty  close to TDD, so we've convinced ourselves we "don't need it." I go back  and forth.

4) How  often is your release cycle?

we deliver code to  production once a week.

5) Who is allowed to deploy code into production?

we  rotate who does the deploy (everyone on the team, including me, is  capable of doing it). we run a shared responsibilty/exposure shop in  order to reduce/eliminate the "john's the only one who knows that  code/process" scenarios. my general philosophy here is if you're not  hiring engineers that you don't trust well enough to do a deploy...  you're liking hiring the wrong folks.

6)  What project management tools do you use?

http://pivotaltracker.com  . in the spirit of agile... we're very light on process/tools. never  document something in more than one place (e.g. in the "story"), and  even then be light.

7)  How accurate are your release predictions?

eh.  having tried (as mgr and individual contributor) everything under the  sun... I no longer believe numbers folks toss out ("we're 90% on time"  etc). I've found everyone's (mine included) numbers are BS, and if you  dig into what actually transpired after the release... enough corners  were cut, enough brilliant engineering ideas employed, and enough  requirements were relaxed during the release cycle, that you never end  up with what you started with anyway, so the A to B comparison and  judgement of "on-time" is never valid. your mileage will vary though. it  all comes down to the "unit"... the "team"... their cohesiveness,  experience working together and trustworthiness amongst eachother. that  said, if you handed me a green teem of folks that never worked together,  I'd drive it agile-style with one to two week iterations/sprits (and  production deploy) cycles with goal-level commitments (e.g. team  committing to having x y and z done by date 'a'... and working as hard  as they can to meet that commitment).