3. Do not design your teams to be cross-functional
When we started out with Scrum we were told that Scrum teams should be autonomous and that they should be able to handle vertical, end-to-end user stories. We consequently setup teams which had all of the skills necessary to implement a story including tools, server components and management components. This did not work very well and we abandoned it after 1 sprint.
The problem was that our developers have different areas of expertise - some are very talented server developers, some have great Eclipse plugin development experience and others are web app specialists. We found was that at the end of the sprint there would always be a single grouping on the critical path and that there were other team members who did not have enough skills in specific areas to take tasks and complete them efficiently. This was wasteful.
We then re-organised our teams so that developers with similar skills were co-located (eg a tools team and a server team). Using this configuration some end-2-end use cases could not be assigned within a single team. This means that we have to co-ordinate the efforts and backlog for the tools and server teams but also ensures that overall resource utilization is much higher.
There is one downside to this approach - in cross-functional scrum teams developers are forced to learn new skills and product areas thus improving cross-training. This can be a good thing once you have good oversight of the designs and code that they produce. However I am not sure that it is realistic to expect developers to be generalists and to be able to turn their hand to any development area. Developers tend to specialise and become expert in specific areas (eg. tools development, DB, security etc)- ignoring this fact means that you must resign yourself to estimate tasks on the basis that it may potentially be done by somebody who does not know the functional area, who has limited prior knowledge of the technology areas which they may be required to use and who may not be interested in the specific technology area. It is similiar to having a sprinter but deciding that you will enter him/her in the decathlon. It the Cape Clear product development team the developers can develop their skills within the team and can of course transfer between teams occasionally. This recognises the developer's existing skills, experience and ambitions - to extend my athletics analogy it may be possible that the sprinter can be trained as a 100m, 200m and 110m hurdles runner but not as a shot-putter!
The
