October 27, 2007
Every problem is a people-problem
A friend of mine who just starting working in an Agile project said to be worried that all problems in the project seem to people problems. I started to think about project problems. Technologies? Time and money constraints? Quality? The list can go on and on. However the bottom line is that people will have to code the solution - I know it's a simplistic view but computers will do nothing by themselves - and assuming that a minimum level of sanity was applied while establishing the deliverables, everything else must be people problems then.
Don’t believe me? Take Kent Beck’s words for it then. In his book XP Explained he says: “… no matter what the client says the problem is, it is always a people problem.” Ok now that I’m on giant’s shoulders let me try to make my point.
What bogs velocity down?
Interruptions – people are taken away from what they should be doing, justifiably or not. Illnesses or life administration matters.
Over commitment – one promises to do more than can actually be done.
Fear/Resistance to change – I already know this technology/methodology and changing threatens me
Bad sloth - In opposition to Good sloth which I’ll write later, hopefully :0) – I’ll only do the minimum and if I can I’ll do nothing.
Tedium – I’m so damn bored I can’t motivate myself to do nothing.
Over engineering – Pythagorean Switch syndrome.
Excess of political concern – If there is no positive press I won’t do it.
The scales tilt to softer aspects and not to technical ones. Once we admit it and put effort into really understanding the team-members, their frustrations, aspirations and turnons we might be able to successfully remove most of the hurdles that hinder software development.