Developer
Characteristics
- It is a cross-functional team: all members work together in solidarity, with shared responsibility for the increment. If the team fails, the team fails; if it succeeds, the success belongs to the team.
- There may be members who specialize in specific areas, but responsibility for the increment lies with the team as a whole, not with individuals.
- The recommended team size is 3 to 9 people. Beyond 9, it becomes difficult to maintain direct communication, and the usual frictions of group dynamics become more intense.
- Neither the Scrum Master nor the Product Owner is counted in the number of developers, unless they actively work on developing the product.
Working group vs. team
The difference between a working group and a team is central to Scrum:
- In a working group, people have specific assignments of individual responsibility and follow execution guidelines. Each person is individually accountable, even if they work in the same organization.
- A team has a collaborative spirit and a common purpose: to deliver the greatest possible value for the customer's vision. Developers self-manage, coordinate without a manager who assigns and monitors the work, take part in decision-making, and share the Sprint Goal and responsibility for achieving it.
The developer in AI teams: evolution toward the product builder
The incorporation of generative AI tools—code assistants, autonomous agents, specification generators—is transforming the developer profile. The Scrum Manager guide Scrum en equipos con IA [Scrum in Teams with AI, in Spanish] describes this evolution with the term product builder:
- Value shifts from implementing to orchestrating: designing architectures, writing specifications that guide the AI, reviewing and validating what it generates, and ensuring quality and security.
- New competencies required: prompt engineering, context engineering, and spec writing, in addition to traditional technical competencies.
- Expanded responsibility: the product builder is responsible for ensuring that AI-generated code meets the reinforced DoD: static analysis, non-duplication, security, and cross-review.
In AI contexts, the developers handle three types of tasks:
- Automated tasks: performed by AI agents with minimal human supervision (generating unit tests from a spec, scaffolding components).
- Human tasks: work that requires creativity, judgement, or contextual knowledge that AI cannot provide (product strategy, user experience design, negotiation with stakeholders).
- Review and integration (R&I) tasks: human work dedicated to reviewing, validating, and integrating what the AI generates. This is the type most easily underestimated in planning and the one that creates the most bottlenecks if explicit capacity is not reserved for it.
If the sprint is planned solely on the AI's generation velocity and no capacity is reserved for human review, the sprint collapses: all the code is "generated," but no one has been able to review it. Explicitly estimating review and integration tasks is what prevents this bottleneck.
Common mistake
Treating "developer" as a synonym for "programmer." In multidisciplinary teams that build digital products, the developer role can include UX designers, technical writers, data analysts, and QA or accessibility specialists. Limiting the definition to the programming profile is one of the reasons why some disciplines remain outside the Scrum Team and keep working as separate departments, breaking the cross-functionality that makes the team effective.
Resources
📄 Scrum Master v.4.0 [in Spanish]Free download · Scrum Manager
📄 Scrum en equipos con IA v.1.0 [Scrum in Teams with AI, in Spanish]Free download · Scrum Manager
See also
Want to advance in agility? You can search for course and exam calls, or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.