It’s easy to get good players. Getting them to play together, that’s the hard part.

- Casey Stengel

Team Level Abstract

The SAFe Team, Program and Portfolio levels provide a rich and deep construct to reason about development agility in even the largest software enterprises. The Team Level of the SAFe framework provides an organization, artifact, role, and process model for the activities of D/B/T Agile teams. Each team is responsible for Defining/Building/Testing user stories from their Team Backlog in a series of fixed-length iterations (sprints), using cadence and synchronization to help manage the variability inherent in software development. Further, some number of Agile teams (typically 5-10) cooperate by integrating their code with that of other teams to build the features and components of larger, higher-value products, applications and solutions at the Program Level. In order accomplish this, they operate on an identical cadence and iteration length. That way they have common planning and development cycles, allowing them to more readily plan together when necessary and integrate their assets on a fixed schedule.

Agile Teams are individually and collectively responsible for implementing and executing the basic Agile project management practices (primarily from Scrum) and Agile technical practices (primarily from XP) that are necessary to yield high quality software in the iteration and PSI/Release time-boxes. As indicated in the Big Picture, teams may use periodic HIP (Hardening | Innovation | Planning) iterations to finalize things such as Release documentation, system performance and other nonfunctional requirements testing, and exploratory testing. The HIP iteration may also be used as a planning buffer, allowing teams to plan to less than 100% utilization, which increases flow (teams can flex resources to react to unforeseen events) and commitment reliability (no teams plans are perfect; even in the short run).

Details

The Team is the Thing

At the Team Level, we find the primary “fighting force” for software development, the Agile teams that collaborate on building the larger system. Since it’s an Agile team, it has a maximum of 7-9 members, and includes all the roles necessary to Define/Build/Test the software for a feature or component. The roles include a Scrum/Agile Master, Product Owner, and a few dedicated developers, testers, and maybe a tech lead. In its daily work, the team is supported by architects, tech writers, SCM/build/infrastructure support personnel, internal IT, and whoever else it takes such that the team is fully capable of defining, developing, testing, and delivering working and tested software into the system baseline.

Teams are typically organized around a set of software Features or Components. Most enterprises will have a mix of both, some component teams focused on shared infrastructure, subsystems, and persistent, service-oriented architectural components, and some feature teams focused on current larger scale, value-delivery initiatives. Agile Teams and (Programs) are self-organizing and reorganize continuously based on the work in the program backlog. Over time, the makeup of the teams themselves is more dynamic than static; static enough to norm and storm [2] for reasonable periods of time, dynamic enough to flex to the organization’s changing priorities.

Roles in the Agile Team

Product Owner

The product owner is the member of the team responsible for determining and prioritizing user requirements, and maintaining the product backlog.

Scrum/Agile Master

The scrum/agile master is the team-based management/leadership proxy whose role is to assist the team in its transition to the new method and continuously facilitate a team dynamic intended to maximize performance of the team.

Developers and Testers

The rest of the core team includes the Developers and Testers who write and test the code. Since this is an Agile team, the team size is typically limited to about 3-4 developers plus 1-2 testers, who are (ideally) collocated and work together to define, build, test, and deliver stories into the code baseline.

Iterations

The teams apply short, time-boxed events called Iterations (Sprints in Scrum) to develop and deliver new code. In the Framework, teams share start and stop boundaries and common iteration lengths so that the code maturity is comparable at each iteration-boundary system integration point. While there is no mandated iteration length, most have converged on a length of two weeks.

Each iteration represents a valuable increment of new functionality, accomplished via a constantly repeating standard pattern: plan the iteration, commit to some functionality, build and test stories, demonstrate the new functionality to stakeholders, hold a retrospective and repeat.

Number of Iterations per PSI/Release

A series of iterations is used to aggregate larger, system-wide, functionality into Potentially Shippable Increments (PSI/Releases) for release (or potential release) to the users. While we’ve illustrated four development iterations (full iteration backlog) followed by one HIP iteration (indicated by an empty backlog) per (PSI/Release, this pattern is arbitrary. In practice, the number of iterations per release increment, the need for HIP sprints (if any) and the decision as to when to actually release an increment is left to the judgment of the Program.

User Stories

User Stories are the primary currency that carries the customer’s requirements through the value stream into code and implementation. As opposed to requirements (which are something the system must do) user stories are brief statements of intent that describes something the system needs to do for the user. Originally developed within the constructs of XP, user stories are now fairly endemic to Agile development in general.

Team Backlog

The Team Backlog (often called a project or product backlog) consists of all the user stories the team has identified for implementation. Each team has its own backlog, which is maintained and prioritized by the team’s product owner. While there may be other things in the team’s backlog as well – defects, refactors, infrastructure work, etc. – the user stories carry the value stream and are the primary focus of the team. Identifying, maintaining, prioritizing, scheduling, elaborating, implementing, testing, and accepting user stories is the primary requirements management process at work in the Agile enterprise.

Tasks

For more detailed tracking of the activities involved in delivering stories, teams typically decompose stories into Tasks that must be accomplished by individual team members in order to complete the story.

Learn More

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

[2] See the Forming – Storming – Norming – Performing model of group development proposed by Bruce Tuckman at en.wikipedia.org/wiki/Forming-storming-norming-performing

Last update 15 January, 2013