I’ve recently watched a great presentation by Venkat Subramaniam titled “Pragmatic factors for Agile Success“. It’s about one and a half hours long, but if you’re doing agile project management in your company, I believe you should definitely watch it. Venkat talks about some good and bad practices, and mostly deals with communication issues. The presentation is cleverly organized into parts, each of which having two sides of it’s own - one beginning with a little devil saying some stuff (the bad practice) and the other one with a little angel saying how the things should work.
The part of the presentation, which in my opinion got the most attention from the audience (and myself), was the part where Venkat talked about the idea to criticize ideas and not people and dealing with communication between team members in general. I believe that this part is highly relevant to lots of people, because the every day communication is possibly the hardest thing to get right in any team. I strongly support the ideas of egoless programming and making design (or for that matter any other kind) decisions based solely on the solutions merits and drawbacks. The latter is the idea that I’d like discuss a little bit more in this post.
I think that although picking some solution based solely on it’s advantages and disadvantages is the only logical thing that comes to mind, I disagree that it is possible to just “let go” of the idea’s ownership. Of course you should go ahead anyway and try not to think about the solution in terms of “my idea” or “someone else’s idea”, the problem is that no matter how hard you try there is just no possibility of really doing that. Sure, you can release the idea, no longer considering “yours”, but if you have already put a substantial amount of thought into it, it’s become a product of your knowledge, experience, your character and beliefs. Your idea is yours not because you consider it yours or not, it’s yours because you’ve made your mark on it.
Hardly ever do you encounter a problem which solutions can be objectively evaluated to pick the best one. Most of the decisions we make are made totally subjectively. Of course in software design the subjectivity level is lower than in for example making business decisions, but it’s still there. From my experience, the area in software design that raises the most controversy is user interface design. The reason for that is that in user interface design you often base your opinions on your own preference. Something that is unintuitive for one person may be perfectly intuitive for another. Other design decisions can be evaluated a little better - something either handles concurrency, or it doesn’t, it handles all the functional and non-functional requirement’s or it doesn’t. However, even if you created a list of facts about some design, which are objectively true, people still can differ about how important those features are, as advantages or disadvantages. What I’m saying is, even when everybody in the team is perfect and letting go of the idea ownership - it’s still pretty hard to arrive at a conclusive decision without someone coming and saying: “OK, I’ve heard all your arguments - let’s do it this way” and ending the discussion. It’s not anybody’s fault - it’s just human nature.
In Agile the communication between the team members is of utmost importance. It’s really hard to succeed if you can’t talk with your team, so we should all try our best and learn communication skills. But if you have a colleague, that disagrees with your opinions and criticizes your designs, don’t think that you’ll change this by just changing the way you speak to that person. You have to understand that the differences between you will still be there, and you’ll still disagree with each other, but that’s the way it should be. The key is to seek those differences, because you might learn from them, and when you still disagree at the end of the day - just learn to let go, sometimes the other persons idea is different, but just as good.
Psyho
