Formalizing the Software Development Life Cycle?

James asks: "My employer is a small consulting firm. Our owners have always tried to sell us as a solutions provider and tried to land project based contracts. Currently though our only truly successful business model is staff augmentation. I feel that our main failures in project based contracts is in our bidding and software development process. Our sales staff always seems to oversell our capabilities (not technically, time and money...I cannot squeeze 70 hours of work into one day). I want to better formalize our processes and was looking into the IEEE/EIA 12207 standard. Has anyone gone though the pains of formalizing to this extent their software development life cycle? If so, are there any tips, good resources to look to for insights?"

Comments

Re:SCRUM/Other Agile methods

[greenhide]

Hmmm...

Scrum seems to me, just at first glance, to be a sort of "hostile" development process, because of the way the whole project begins:

Describe the project, include how long it's estimated to take, how much it is estimated to cost, how it is expected to perform, etc. Now tell them that their job is to do it in half the time, with half the cost, twice the performance, etc. Tell them how it's done is up to them and explain that your job is to support them with resources. Now leave.

I don't know about you, but being presented with a project in that way would be demoralizing, not to mention weird. Also, their explanation of why it works is weak:

Why does Scrum Work?

The basic premise is that if you are committed to the team and the project, and if your boss really trusts you, then you can spend time being productive instead of justifying your work.

That's not a development methodology. That's just common sense. What I've read so far seems to boil down to, "It's a flattened waterfall cycle that the Japanese developed" and "it's a Rugby term".

Scrum sounds to me more like the sort of thing that you feed to corporate managers who read books like Who Moved My Cheese? rather than developers desperate (or even just interested) in cutting down and refining their development cycle.

At the very least, I'd go for a methodology that has actual printed books (e-texts are great for source code and learning languages, but lousy for the philosophy or process of programming, IMHO) that you can refer to with your back to a computer. Right now it looks like to learn about Scrum, you hire (a) consultant(s) to come to your business and teach it to you, which sounds like an expensive proposition to me.