The Developers consists of professionals who are committed to creating any aspect of a usable Increment each Sprint. Only members of the Scrum Team create the Increment.
Developers are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Scrum Team’s overall efficiency and effectiveness.
Developers have the following characteristics:
- They are self-organizing. No one (not even the Scrum Master) tells the Developers how to turn Product Backlog into Increments of potentially releasable functionality;
- Developers are cross-functional, with all of the skills as a team necessary to create a product Increment;
- Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
- Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule;
- Individual Developers may have specialized skills and areas of focus, but accountability belongs to the Scrum Team as a whole.
- The team should be cross functional. i.e. they should have all skills necessary to complete all work necessary to deliver value to customer.
Building a Scrum Team
It is really no different from building any conventional team in theory. Key modifications to this rule are as follows
- Team members need to collaborate more than conventional teams since the team is self managing.
- There is nobody to tell them what to do and that they have to release a releasable code every interaction which will force them to collaborate a lot more
- Therefore, naturally you will look at team members who are good at working in teams and have good communication skills.
- You will need specialists of course, however, you will need more generalists who are versatile and can do multiple activities e.g. code, test, if required jump into areas which are not his/her own but need help etc.
- You will need highly motivated individuals who can make decisions and stand by the decisions and commitments and strive to meet the goals.
- This essentially means you need to coach the team and trust them to deliver. Thus they will definitely promote a right attitude.
- One must remember that they will always not be successful. Therefore make it “Safe” for people to make mistakes so long as they are learning from their mistakes and learning as they go along.
Building Empowered Teams
Key concept here is “Empowerment”. An empowered team is a team which acts on its own and within. Therefore Empowerment is
- Responsibility and ownership and NOT throwing rule book out of the window.
- Working independently towards common objective and NOT bypassing everyone who say NO
- The team can understand reasons behind a decision so that they can apply sound judgement in decision making. It is not always doing the fun part of the job and ignoring the rest.
- It s about weighing the impact of the decisions on stakeholders and not freedom to unilaterally make decisions that impact others.
- It is about making trade-offs while making decisions that impact others.
Therefore “Empowerment” does not mean you throw out the rule book and do whatever you want.
Developers Team Size
- Optimal Developers Team size is small enough to remain nimble and large enough to complete significant work within a Sprint.
- Fewer than three Developers Team members decrease interaction and results in smaller productivity gains. Smaller Developers Teams may encounter skill constraints during the Sprint, causing the Developers Team to be unable to deliver a potentially releasable Increment.
- Having more than nine members requires too much coordination. Large Developers Teams generate too much complexity for an empirical process to manage.
- The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint
There may be requirements for Specialist roles in a team which may be appointed based on the nature of the project. However, the Specialist roles should be in a position to fold their sleeves and get down to the core development work if there is no Specialist work pending.
Some of the Specialist Roles seen in the industry are
Sometimes the project is highly technical. An Architect can play a key role in making crucial decisions on designs, review designs. In Scrum, it is expected that even the Architect is “hands on” and should be able to fold his sleeves and help out others in solving critical issues.
Automation Test Expert
Automation is the key in ensuring Quality in a Scrum Project. Since the team sizes are small, there may not be dedicated manual testing teams. In such cases, a Automation Test Expert is essential so that many of the testing can be automated.
Configuration Manager role will be required for managing the repository and proper versioning. This role may be required in case of complex projects which require help of a independent person to maintain the right versions. This will help save the time required by the Scrum Team while developing and producing the outputs quickly.