If I arrange to meet you somewhere at a particular time, I don’t expect to have to tell you how to get there. I don’t expect to write down the route for you. I don’t expect to write down alternative routes in case there’s something wrong with the preferred route. I don’t tell you what mode of transport to use. I don’t check the weather forecast and let you know what you should wear.
You figure all that out for yourself.
I just expect to see you there, unless you run into problems that delay you, in which case please let me know so you don’t leave me standing around in the rain wondering when you might arrive!
Obviously it’s okay to ask questions. Not stupid questions like “How do I get there?”. But maybe questions like, “I was thinking of going by chauffer-driven limousine and putting it on expenses, is that okay?”, because that affects me. Maybe questions like, “Is there a dress code?”, because that affects the appropriateness of the decisions you take.
Questions like this are okay because they are questions to establish the boundaries. Within those boundaries you can decide for yourself.
If we can apply this thinking to our everyday lives, why do we expect something different when we work on software?
What happens to our ability to think for ourselves when we walk through the office door?
Is it a lack of skills or knowledge? I doubt it.
Is it laziness? Maybe, sometimes, but generally I doubt it.
The answer, I think, is fear of failure.
If I let someone else do the thinking, noone can blame me if it’s not right.
“You never told me that”, “that wasn’t in the spec”, unfortunately are just excuses for not thinking for ourselves.
Agile teams should be empowered. Empowered to make decisions for themselves. But being empowered requires team members to accept it, to use their own judgement and initiative, and to take responsibility.
Go on, grasp the nettle.
I dare you.
Photo by JoeLodge