Wednesday, April 2, 2008

Company Policies and The Team's Design Choices

Our company is becoming more and more corporate day by day. Ironically as it becomes more corporate, it tries to adopt more agile methodologies.

One of the company's director is an expert in databases. Some teams in the company regarded him as a data architect. Eventually he was officially appointed as the data architect few months ago. We were asked to consult with him for any database schema design or other database related issues.

The data architect then took it upon himself to standardize solutions across various teams. He came up with a database schema design for a feature and proclaimed that every similar feature should use the same schema. Everybody, albeit reluctantly, agreed with his schema design. Now when a similar feature needs to built as part of the sprint, the developer who was reluctant (let's call him "A') in accepting the architect's schema design has to face the data architect again.

'A' rebelled and came up with a simpler easier domain specific schema design instead of the architect's generic schema design. He emailed the design to the team on the mailing list. A team member (let's call him 'B') spotted the inconsistency and asked the developer to reuse the architect's schema. This attracted manager's attention and the manager too asked 'A' to get the data architect's approval.

A meeting was setup to discuss the design with the architect. As expected, the architect and the manager opposed the idea of deviating from the standard, already agreed upon design. 'A' is very unhappy as he will have to now code a complicated solution.

This incident raises many questions. Should the scrum master intervene? He did not and he should not. Design is the team's responsibility and the scrum master should completely leave it up to the team.

What is the manager's role? Should he be involved? This is the grey area. In an ideal scenario, the manager should let the team figure out the design. But in large corporations, they often have policies and procedures which cannot be thrown away because one team is implementing scrum.

What should the team do? Other team members should talk to the unhappy developer and try to comfort him so that his productivity is not affected.

No comments: