Agile Software Development: Are we really equal?

When people talk about agile process like Scrum, it is pretty normal to hear that there is no job title like architect or programmer, etc. so many will think that as a "developer" or a"team member" everyone has to be equal. Well :) if you think the same, you are wrong.

Agile process' usually define for a small teams (like 4-9 team members) so it is understandable to expect people to have some common knowledge, but of course that doesn't mean that you are equal even if the whole team works in a same department. 

Here I want to share some of my personal experiences with you:

Personal Experiences

It is very important to recognize the individual in the team. Each person has some special abilities and came from different background, We all write software systems but even on a single project, we have different tasks so it is clear that each one looks at the task from different aspect.

When team needs to take a decision about an issue, it is important that all attend the meeting and share their ideas, but it is predictable that someone who has some background will have more to discuss. More importantly it doesn't mean that you have to convince everyone that the idea is great. Of course if your team members are mature enough, they won't insist much to choose the easy way when the ones with more experience already chosen another one or vise versa.

As an example, I was working in a very good team and all members were senior developers and we used scrum. When there was a discussion about structure or architecture, it was people with architecture background who discussed the ideas mostly, but of course everyone shared their ideas and tries their best to improve the solution. After some discussions, sometimes one or 2 didn't convince totally but since we know each other, we just trust on the solution on experts.

The role of a "dean"

On a daily basis, a normal team can handle most situations. But there are some times that you need to ask someone to help you choose. I want to emphasis on that there is no boss or things like that in the team and when I refer to dean I don't mean someone that is superior to others in any aspect, I specially believe that a software team has to be flat and everyone has to be responsible for what he do. So what does it mean to have a dean?!
A dean is someone whom you trust, with his judgment. It doesn't even mean that the one has more knowledge than you.

For instance, we had a small project and we had to implement a service with lots of needs. The 3 of us researched for 2 weeks and discussed the solution almost everyday. After all, we could't agree on a single result since there was different possible scenarios. Then we explained everything to the one and asked him to choose between our solution.

Bug Ratio and "Blame" tools

It is really important to know that we don't blame people for their code! Because we all know that as humans we all make mistakes and more importantly as a team we have to support each other, not to blame each other, So how can we use the blame tool? (as git called)

Believe it or not, we know each other when we work together for a portion of time and we use this knowledge to understand why someone did something. To be more specific what is your reaction when you have to change an old code and you think it is not efficient, or it is not what you think it has to be?

* If you simply change it to what you think is correct, or you afraid of changing it at all then you need to gain more experience, please don't change anything and ask someone with more experience to work in pair with you for some time.

I normally try to understand the method, what it does, why the one implemented it like that and where it has been used, If I still believe that it is not good and I want to change it, I will check the history line by line using blame tool to understand the process of change and to define the owner. If the code has been changed dramatically by time, or if the owner is someone with normal bug rate, I will refactor the code immediately. But if the code has been written by someone who has low bug rate, (someone who maybe has a clue about the future) I will talk to him first, because it is probable that he knows something that I missed.