Thursday, May 1, 2008

Scrum Team Composition

Scrum Team composition is very important for the success of the project. I have experienced it at many occasions. Many times, when an organization wants to take up a new important project, they tend to form an all star team - a team composed of all senior and experienced developers. Such a team composition poses following risks:
  1. Senior developers are more opinionated than junior developers. Thus imagine a team of 5 people, all stars, discussing a design. Everybody will have different opinions. Many times the design choice is not clear, it's philosophical. Such heated design discussions can cause a rift amongst team members.
  2. If junior developers don't work with senior developers, you loose a chance of training your junior developers.
An ideal team size is around 5 to 7. If you have a complex project that requires a much bigger team, then the project can be split into multiple scrum teams. Bigger teams tend to have multiple internal groups (with different school of thoughts) and hence struggle to arrive at a decision.

The teams should be cross functional. It should have all the skills that are necessary to complete end to end stories - front end, back end, database, testing etc. The exact mix of these skills depends upon the requirements of the project. It is possible to change the team composition every sprint if necessary. But the changes should be minimal because changing the core team every sprint will impair the desired velocity.

Scrum provides a platform for open communication and collective decision making. Open communication will immediately bring the philosophical difference of opinion to the forefront. The scrum master in most cases should not intervene design / coding philosophies battles. But if it starts going out of hand and affects productivity, it is important that the scrum master talks to them and brings everybody on the same page.

Monday, April 28, 2008

Self Organizing Team

A Self organizing team is a very powerful concept that liberates the manager from the agony of mundane tasks. In most cases people are not used to managing themselves and managers are not used to not manage certain things. Here are some problems the managers face moving towards a true self organizing team:
  1. Managerial ego: Some managers think "What would the team do without me?" The team needs my help to solve problems”. And they get satisfaction from the fact that they were able to help their team at every single occasion when the team needed his/her help. But in that process, they forget that they are making the team more dependent on him/her leaving him/her less time to do the real managerial tasks.

  2. Fear of losing touch with details: They always like to know each and every minute detail so that they are aware of everything and can answer their superior’s detailed questions. However, in some organizations this quality earns them respect.

  3. Forced involvement in development issues: Sometimes team members have disagreements amongst themselves on various issues such as design choices, engineering practices etc. Inevitably, these disagreements then go to the manager to get resolved. Thus, even if the manager is trying to stay away, he/she gets involved in the argument to save the productivity of team.

  4. Fear of not doing things the right way: Every manager has his/ her perspective on what is right e.g. right engineering practices, the right way to solve a problem etc. The manager keeps thinking that if he does not make the decision, the team will solve the problem in a "wrong way". This keeps the manager more involved in small decisions.

It is difficult to achieve a truly self organizing team. It is very tempting to use the decision making authority you have as a manager. But if that becomes a routine, most of your time will be consumed in making small decisions that could have been made by some other team member. It is difficult to resolve the above mentioned problems. You cannot make your team self organizing in a day. You have to train your team for months.

After working for months to achieve a truly self organizing team, the result is gratifying. The gains are phenomenal. You can save at least 50% of your mundane work. This gives you that 50% time to think about future architectures, long term career development of your engineers, attend conferences etc. Your job will be much more interesting than it was before.