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 over the long term. 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 entire 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 with individual teams

Since a SAFe team can no longer autonomously determine all aspects of its work, the backlog for the team must be coordinated with the overarching backlog, on the other hand, that critical overarching decisions on interfaces and architecture must be coordinated.

The Product Owner, Scrum Master, and other team members have additional responsibilities to collaborate on the overall planning, coordination, and learning process of the entire Train.

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 accepted code.
• All stakeholders understand 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 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), providing an estimate for the next sprints for its product owner
• 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).