We consider 2 ways to form developer/tester teams:
1. Use a fixed team that move together from one project to the next.
2. Form a new team from a developer pool each time a new project come.
In my opinion using the first approach (a fixed team) is preferable than the second (project based team).
A fixed team will be more productive since its members have learned to trust & anticipate each other (regarding competences, work styles, personalities). Besides, it's easier to measure the velocity (thus improving your estimation & planning) with a fixed team. On the other hand, you need to give time for the team to "gel", once the team spirit is formed the productivity will increase.
A scrum team facilitates itself for this fixed-team approach. The daily scrum meetings facilitate the face2face communications between team members thus strengthen the "glue" inside the team, good for bashful geeks who otherwise will hide the whole day behind his PC.
Strangely enough, my observation of the drawback of a project-based team came from outside the professional works. I can share an experience in our church music team. As one of the biggest church in the Netherland, we have lots of talented musicians in the pool. Every week we will draw a set of band members from the pool. We spend the first hours of weekly exercise struggle to blend as a new team, so less time left to build the musical quality nor to worship as a team.
As conclusion, teams are harder to build than projects so it's better to form a persistent team that move together from one project to the next.
How's about your experience in your organization (work, church/community project etc)? Please share your comments.
Source: Steve's blog http://soa-java.blogspot.com
Reference:
The Clean Coder by Robert Martin
Disclamer: the 'bash-ful' term in this article has nothing to do with the bash shell in Linux.
No comments:
Post a Comment