+91-7710033016 / +91-8291749529 support@effectivepmc.com

The Developers consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.

Developers are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.

Developers Characteristics

Developers have the following characteristics:

  • They are self-organizing. No one (not even the ScrumMaster) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
  • Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
  • Scrumrecognizes 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 Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development 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 tradeoffs 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 Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment.
  • Having more than nine members requires too much coordination. Large Development 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

Specialist Roles

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

Architect

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

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.