Team skills and qualities – teams in a scaled environment, part 2

Code quality and architecture

In larger development, the effect of poor code quality becomes much more pronounced: teams no longer rely on deliverables, cannot make realistic predictions, or make commitments.

A scaled environment generally produces long-lived code, and the effects of poor quality add up and hinder deliverability in the long run. Therefore, code quality is a key building block for an effective agile team and release train.

SAFe draws the consequences from this:

• Maintain continuous integration (successful integration is the most important indicator of code quality and challenges the agile quality of the whole organization)
• As much foresight as necessary – with the “architectural runway”, necessary central determinations are made in a cooperative manner.
• Stabilize in time – at team level and at train level there are regular these stabilization points with the sprint review and the release review meeting.

Alignment – differences to individual teams

Since a SAFe team no longer has autonomy over all aspects of its work, the backlog for the team must be coordinated with the overarching backlog, and critical overarching decisions about interfaces and architecture must be coordinated.

The product owner, scrum master, and other team members have additional responsibilities to participate in the overall planning, coordination, and learning process of the entire training.

Transparency

Agile teams need comprehensive transparency to function well. Various measures contribute to this transparency:

• All backlogs and the work status of all teams are continuously visible
• Teams provide meaningful metrics based on working, tested, and approved code.
• Everyone involved understands the concepts of a backlog, velocity and work-in-progress.

This transparency must be ensured across the board, and the necessary open environment must be ensured and supported by management.

Planning and estimation

The individual team contributes to the planning at various levels:

• The team estimates its user stories in its Scrum role (as part of the IP sprint or in backlog redefinition meetings) and thus provides its product owner with an estimate for the next sprints
• The team takes responsibility for user stories as a result of sprint planning
• Team members previously attend the program level iteration planning meeting, the program increment (PI), where they create a coarser forecast for the sprints during the program increment (PI, the basic release cycle in SAFe).