The Scrum Development Team is confusing to anyone who originates from a standard IT background. There are no architects, Business Analysts, Testers or UX Specialists, there are just Developers. This does not mean that there is no Business analysis, Software architecture design or system Testing. All the skills needed to finish the Scrum are there. Each Team member is referred to as a Developer while they remain in the Scrum. For this reason, the adjective that is most utilized to describe a Scrum Development Team is “Cross-Functional”.

So you know you must pick the right expertise to cover the Project scope, titles do not matter. Well, there is another adjective describing a Scrum Team that moves the Goalposts out a few more metres. Scrum Teams are “Self-Managing” or “Self-Organizing”. This means that there is no Project Management, all decisions about the Work are made by the Scrum Team.

Development Team Size

So, you have picked a Team of 12 people for your Scrum Team. They might have some Personality clashes but have all the ability and experience you require for a successful Project. Regrettably, there is another element you have to take into consideration. Scrum Teams ideally ought to have 5 to 7 Developers, but no more than 9. Add to this the knowledge that no Project, Traditional or Agile, has ever got the exact Project resources that were requested. However, there are some other factors in your favour. These can increase the number of people to be co-opted for the Scrum Project and provide you with resources with the requisite skill sets.

Large Scrum Projects

If this is a very large Project, 7 individuals may be insufficient. In this case, you will need to establish 2 or more Scrum Teams. Each team with 5 to 7 people. For this we will need to utilize an additional co-ordination system, the “Scrum of Scrums”. This is to keep all the Scrums synchronised and Collaborative across Teams.

There is a temptation to pick only experienced people for the Team, however this is a short-term perspective. If you do not include less experienced members into the Team, you are denying them the Opportunity to Develop into the capable Team members. These team members will be needed on future Projects. They may likewise be more respective to Working in a Scrum Team than the more experienced members. Experienced team members may have to unlearn the old way of doing things.

Another thing to ensure is a commitment from each Team member that they are there for the duration of the Scrum. Team members should be available for the entire project barring for unforeseen circumstances. The reason for this is that Team Dynamics are important in any Scrum. If a Team member leaves and is replaced by a newcomer, the Dynamics and Teamwork are impacted.

The Development Team: Supplying the Right Environment

At first, the individuals you pick for the Team might be complete strangers. They may have just a slight acquaintance with each other. Depending upon the size of your Organisation, you may have brought in contractors or Team members come from a different branch or region. Even if this is not the case, they may not have actually Worked Collaboratively with each other before. Calling a group of individuals a Team does not always make them a Team. You are required to ensure that they have an Environment that is favourable to the Team Dynamics to Develop and Mature.

We found these books great for finding out more information on Agile Scrum:

Development Team Location

First of all, you want the Team to be co-located, so that they are Working in close proximity. A dedicated Work area should be found that will accommodate them. Perhaps you can commandeer a Meeting space for the period of the Scrum. The Team do not only Work in this room. The Scrum “Ceremonies”, or Meetings (such as the Sprint Planning, Daily Stand-Up, Sprint Review and Sprint Retrospective Meetings), can be kept in the same space. Any Artefacts, such as “Burndown Charts”, which reflect progress, can be displayed on the walls.

We have not mentioned them as yet, but space should be provided for the other participants in the Scrum. These participants are the Agile Scrum Master and the Scrum Product Owner. The Product Owner specifically needs to sit with the Development Team. They have been brought in from business, and are required to be away from his typical Environment. This ensures that their attention is not diverted from the Goal of Developing an effective Product. The Scrum Master also needs to be on hand. They are the steward of the principles of Agile and Scrum. They exist as both a coach and to ensure that there is no deviation from the Framework.

Growing the Team

As we discussed before, the Team might be strangers at the start of the Scrum. They are anything but a Team at first. There is a maturity model explained by Bruce Tuckman that applies to Teams. This Team should develop through three or 4 stages. With luck they will reach the 4th stage during the Scrum. The Scrum Master is important in coaching and guiding the Development Team through these stages. They understand that this is a necessary journey in each Project.

Bruce Tuckman

Stage 1 or “Forming”. This is where the Team meets. The ability and appetite for collaboration and Teamwork are very low at this point. Each Team member is acting as an individual and is not aware of the capabilities and temperament of the others.

Stage 2 or “Storming”. This is a high-conflict stage. Team members challenge each other and conflicts and disputes are common. Ideally this stage is brief and results in shared acceptance and trust among members.

We found these books great for finding out more information on Agile Scrum:

Stage 3 or “Norming”. At this stage there really is a Team. Members Work in collaboration with each other and identify each other’s strengths and weaknesses. Work is carried out effectively. However there is room for improvement.

Stage 4 or “Performing”. The performing Team Works in harmony, producing Quality output from each Sprint (the output is called the Product Increment). This level of maturity is not always possible within a Project, however if it is achieved, the Value of the Team should be acknowledged.

Tuckman included a fifth stage to his model, “adjourning”. This signifies the decommissioning of the Team. The issue with adjourning is that the stresses of reaching stage 3 or 4 are not acknowledged as having significant Value for the next Scrum. The whole cycle will have to begin again, rather than utilizing a group of Developers who have actually learnt to Work and deliver together.

Decommissioning

Whether the Team is decommissioned or retained at the end of the Scrum, there is satisfaction in knowing that the uncertainties of combining different Personalities and skills into a coherent unit were overcome, and that a successful Product delivery was made in Record time. Lessons Learnt by observing the Team and how they coalesced over the Project can be applied when selecting the next Team for a Scrum.