Everybody codes. Everybody tests.
The Dev Team is a subset of the Agile Team. It consists of dedicated professionals who can develop, test, and deploy a Story, Feature, or component. The Dev Team typically includes software developers and testers, engineers, and other dedicated specialists required to complete a vertical slice of functionality.
For consistency with the Scrum definition, the Dev Team excludes the Product Owner and Scrum Master; they are part of the larger Agile Team.
Developers and testers are the core of Agile development. They work in small, cross-functional teams and can quickly create working, tested code that delivers value. They build the systems we all depend on.
In traditional development, the developer and tester roles are typically differentiated, often with each reporting into a different management structure. In Agile, the two roles blend. For example, Mike Cohn doesn’t distinguish the roles and instead calls everyone “developers” . Engineers that develop hardware, firmware, and other components are also considered ‘developers’ in the context of SAFe. The line between development and test is purposely blurred. Developers test and testers code.
Dev teams are empowered by the enterprise to manage and self-organize to accomplish their own work. They include all the skills the team needs to create an increment of a working, tested solution.
The Dev Team’s responsibilities include:
Collaborating with the Product Owner to create and refine user stories and acceptance criteria
Developing and committing to Team PI Objectives and Iteration goals
- Working with the Product Owner to confirm that the code and acceptance tests reflect the desired functionality; writing the code
- Conducting research, design, prototyping and other exploration activities
- Creating unit tests and automated acceptance tests
- Using design and coding best practices to build high-quality components and solutions
- Checking new code into the shared source code repository
- Pairing to write code and automated acceptance test cases
- Executing acceptance tests and maintaining the test cases in a shared repository
- Continuous improvement of the team’s process
Collocation, Collaboration, and Knowledge Sharing
The collocation of Agile team members and the blurring of the traditional roles optimizes velocity and quality. It also helps create empowered Agile teams. However, this means that developers no longer operate collectively from a shared resource pool, where one could argue that it was easier to learn, share, and advance collective competencies. To address this, the Agile enterprise must consciously create a culture and environment where best practices and knowledge are shared. This includes new-found Agile skills such as story writing, Continuous Exploration, Continuous Integration, Continuous Deployment, collective code ownership, and automated unit and acceptance testing, which are easily shared across teams. This is often facilitated by Communities of Practice.
As implied above, the Dev Team is directly responsible for much of the culture and many of the practices necessary for building the Continuous Delivery Pipeline and implementing DevOps. To this end, their ‘T-shaped’ skill training also includes developing expertise in developing and managing staging and deployment environments and mastering techniques for independently releasing elements of the larger Solution. They assume additional responsibilities for following the code downstream and into production. This further blends traditional siloed responsibilities such that Agile teams, and even individual developers, can master the ability to Release on Demand.
Build High-Quality Components and Solutions
Dev Teams are relentless about quality and build quality into their development artifacts and practices. They follow test-first practices when writing tests for their code (Test-Driven-Development) and acceptance tests for their stories (Behavior-Driven-Development). Agile Dev Teams apply quality design (abstraction, encapsulation, SOLID, Design Patterns) and implementation (Extreme Programming) practices so they can reliably and quickly meet new business goals. And they relentlessly refactor their designs to ensure they can continually respond to emerging requirements. See the Technical Agility section of SAFe’s Team and Technical Agility competency article for more information.
Design for Testability
Since all code is tested code, developers design and evolve the system to support testability and test automation. In practice, designing for testability and good design are synonymous and imply modularity, low coupling, and high cohesion of layers, components, and classes. This supports the testability of any separate fragment of logic, as well as the ability to create higher, system-level, integration tests. In a similar manner, the solution should be designed to make it easy to deploy and release.
Learn More Cohn, Mike. Succeeding with Agile: Software Development Using Scrum. Addison-Wesley, 2009.  Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
Last update: 9 October 2018