I am sure you’ve heard the one about the man flying in a hot air balloon when he realizes he is lost. He reduces height and spots a man down below. He lowers the balloon further and shouts: “Excuse me, can you tell me where I am?”
The man below says: “Yes, you’re in a hot air balloon, hovering 30 feet above the ground.”
“You must be a software developer,” says the balloonist.
“I am,” replies the man. “How did you know?”
“Well,” says the balloonist, “everything you have told me is technically correct, but it’s no use to anyone.”
The man below says, “You must work in business.”
“I do,” replies the balloonist, “but how did you know?”
“Well,” says the man, “you don’t know where you are, or where you’re going, but you expect me to be able to help. You’re in the same position you were before we met, but now it’s my fault.”
My perception, your reality
There’s at least two sides to every story, I’ve come to realize over the years. And this is certainly true in the ongoing spat between Business and IT. I quizzed my business colleagues recently to discover the gripes they have against IT. Here are just seven of them:
1. Developers pad their delivery times because they don’t want to be proved wrong.
2. Development teams always deliver products short of features.
3. IT is always much too slow because of big teams, democracy in teams, too few hours worked by team members, and too many juniors involved in projects.
4. Developers use the market place to test the product, and QA can’t reliably trap the bugs we unfixed that were previously fixed.
5. The result of slow development delivery is animosity between IT and Business.
6. Rather than try to address slow delivery, IT Management defend it.
7. The Development Team lack the industry and business knowledge to spec a solution for the real world.
I understand there’s a fair bit of emotion in these perceptions, and they may be unsubstantiated. But that’s what perceptions are. Nonetheless they are real in the minds of those who hold them.
Far from being provocative for its own sake, I list them so that, through identifying which they are, we’re in a better position to calmly and logically address each one. Yes, each one, from an Agile point of view. Implementing Agile processes in a traditional organization will struggle, if not fail, unless these perceptions are dealt with one by one.
I’m sure there are others. Please let us know your gripes: If you’re in Business, against IT; if you’re in IT, against Business. Don’t feel you need to explain them, just put them down.
