Everybody codes. Everybody tests.

 

 

 

Dev Team

The Dev Team is a subset of the Agile Team. It consists of the dedicated professionals who can develop and test 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.

Details

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’ [1]. 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.

Responsibilities

The Dev Team’s responsibilities include:

  • Collaborating with the Product Owner to create and refine user stories and acceptance criteria
  • Participating in PI Planning and creating Iteration plans and Team PI Objectives
  • Developing and committing to Team PI Objectives and Iteration plans
  • 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
  • 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.

Continuous Delivery

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.

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

[1] Cohn, Mike. Succeeding with Agile: Software Development Using Scrum. Addison-Wesley, 2009.

[2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

Last update: 26 October, 2017