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).
Twitter
LinkedIn

Team Skills and Qualities – Teams in Scaled Environment, Part 2

Leave a Reply

Your email address will not be published. Required fields are marked *

On Key

Related Posts

Thoughts about strategy

… Vision is different from purpose. A purpose is similar to a direction, a general course. A vision is a specific goal, a picture of

Thoughts about strategy

… Vision is different from purpose. A purpose is similar to a direction, a general course. A vision is a specific goal, a picture of

The Adaptive Organization at Agile Tuesday

December 2021 Almost unnoticed, an ecosystem has developed alongside the agility we are familiar with that comes from a completely different approach: rethinking the structure

Five steps to building trust

Last week in our Meetup on Growing Adaptive Organizations we had a very interesting topic: Leadership for Trust i.e. what aspects of leadership are important for building trust.

I present a small part of the discussion here.

Cookie Consent Banner by Real Cookie Banner