What about Ego?
Today during the Mob Programming session at Agile 2013(#Agile2013) we were asked the question
“Does the Mob have to deal with issues related to Ego?”
The Egotistic Developer
In my experiences in previous jobs, egotism came into play when a developer or manager attempted to push a personal agenda related to a decision suggested to the rest of the team and is unwilling to back down from that decision when it is questioned by that team. The person will have to be backed into a corner before the correct decision can be made because they do not want to “lose face.” These ideas then become particularly hard to extinguish because the egoistic person has now defended it to all levels of the company and can possibly force a team to take the wrong approach.
The Mob and Gathering Ideas
In practice we, as a mob, try to ensure that everyone has an equal voice. We want to take the best possible approach and evaluate them with an objective eye. When trying to decide on an architectural approach everyone in the mob can say their idea however effective or ineffective the approach might be. Having multiple ways to do something is good because it will help us refine our thinking about how an approach should be done. Many times we have taken parts of multiple approaches suggested.
Who has the right approach?
After we have discussed the possible approaches and we want to take one approach in particular we need to figure out which one would be the best approach. In the past before working with the mob, in my experience the approach taken was based on seniority and not by any criteria that would improve the performance of the team or the software. As a Mob what we do is evaluate the each approach on a number of criteria. The “Right Approach” will follow clean coding principles, it will be cohesive, decoupled, tested, and the simplest thing that could possibly work. Our definition of the “Right Approach” of course can change due to a retrospective. Regardless of seniority architectural decisions can be made by any team member as long as it fits the criteria best.
How does the Mobs approach eliminate Ego?
In our Mob I don’t think we have anyone on the team who is particularly egotistical, however if we did have someone who was I don’t think they would be able to show it. Since we make decisions as a team and judge the validity of an approach as a team it would be impossible to “pull rank.” Furthermore if someone suggests a decision and the team uses it, the mob becomes responsible for that decision, not the individual. This means that an idea does not need to be defended to “save face.” Not having to “save face” in a corporate environment can be incredibly lucrative for a company since many bad decisions are made and followed because people do not want to look bad.
What if there is a tie?
I can’t remember too many times that two ideas had equal validity in the mobs eyes so decisions have usually been quick. The few times this did happen we could have chosen randomly, however we went with the idea of the person with the least total time navigating. Meaning that they would have an opportunity to get better at navigating since much of what we do is in the name of Mob Improvement. This form of decision making brings more value to the team in the end than if we had gone with the more experienced navigator.
Mob & Ego
If your software development team is dealing with Ego problems. Try Mob Programming and then retrospect about it! I think you will find the experience will be extremely valuable!
