Codified Common Sense

The more time I spend in this software development game, the more I believe that all these fancy methodologies are just codified common sense.

Back when I first started managing projects, I got hold of a great book called “The Project Manager’s Desktop Reference”. It was full of interesting information about planning, risk management, SWOT analysis, accrued value, and other such useful yet blindingly obvious tidbits. I read through this and nodded in sage agreement, waiting for the big “AHA!” moment. It never arrived.

And so it continues. I’ve been reading up on Scrum recently, looking to cement my understanding of this particular ‘agile’ methodology. So I was stunned to read a summary of Scrum, because it codified the exact way that I have chosen to run my teams at Datacom (where the particular project allowed it). I’ve been aware of Scrum, just as I’ve been aware of waterfall, XP, pair programming, PMBOK, PRINCE2, RUP, and any other methodology you care to mention; but I’ve not once gone out of my way to read about it and implement it.

I guess it’s the same with any of these emergent methodologies: if you work with good developers, and trust in their abilities, you will tend to arrive at “best practise” sooner rather than later. It doesn’t make sense to throttle good developers with undue process, and I can’t count the number of times that heavy up-front process has brought a good development project to its knees.

So yes, more codified common sense. I’m starting to wonder if it’s just that my common sense is not so common after all?

Join the Conversation

1 Comment

  1. You’re right; common sense isn’t that common! From all I’ve learned about scrum it is just codified common sense. Once you unlearn the bureaucracy and shit that goes along with modern work and accept ‘Theory Y’ type things can work, you’ve basically got scrum

Leave a comment

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: