SAFe — make agile projects great
This story is a personal view on one of my current software projects together with a customer. I’m an IT project manager at QAware in Munich, Germany, and work currently as a scrum master in a SAFe program.
Some years ago, it was still common practice to implement a software project in exactly the same way like it was planned some time ago in a long specification phase (I still can remember this kind of project). To put it bluntly: If something was not planned today it cannot be implemented 5 months later — even if one is aware of something better after 3 months. And almost even worse: The customer only receives the first (and usually at the same time the last) delivery item after 5 months. If the expectations were not completely congruent or the requirements have changed over time, his enthusiasm may be limited.
Agile is great— but in that size?
The agile way of working, especially according to Scrum, has meanwhile become an integral part of project management in my software projects. The shorter planning and delivery cycles lead to greater flexibility and the ability to act in the event of changing or additional requirements. In order to be able to work efficiently, a scrum team should ideally not be larger than 8–9 members. But how do you deal with it when a project is more extensive and 8–9 team members are not enough? And: “more extensive” here means “much more extensive”, i.e. around 250 project members? There are several possible answers to this question, such as SAFe, LeSS, Nexus or Scrum@Scale. In the program described below, the decision was made to use SAFe in Portfolio configuration. This setup is explained in more detail below.
The approximately 250 employees in that program (employees of the customer himself, of QAware and also other IT service providers) were basically divided into two Agile Release Trains (ART): The platform train for developing the basic software platform and the product train for developing various products on the said platform. The platform train includes 15 teams, the product train 12 and each of the two trains has a lead. The train’s own product managers, architects and RTE (Release Train Engineers) are responsible for the technical and organizational interaction of the teams within a train. While the roles and tasks of product managers and architects are quite obvious, the RTE also has a very central role: the planning, organization and moderation of regular appointments and collaboration in the ART. The RTE acts as the “over all Scrum Master” of the ART, so to speak. One of his main tasks is to organize and moderate the numerous events, from PI planning to Scrum-of-Scrum to system demos. Each team within the two trains usually consist of a PO, a Scrum Master and 2–5 other team members such as developers.
Do you have a plan?
Regarding the schedule, the program is divided into PIs (Program Increments) of 5 iterations each, which in turn each contain 2 weeks. These iterations are classic Scrum sprints in the program described and thus each contain a separete planning, review and retrospective. The timing of the two ARTs is slightly offset, since the results from the PI planning of the product ART are relevant for the PI planning of the platform ART and must therefore be available beforehand. Such a PI planning takes place at the start of a PI, usually lasts two and a half days and begins with the presentation of the business context by the leadership team. This ensures that all ART participants know the high-level objectives and can therefore align their tasks accordingly in the further planning process. This alignment of team objectives with program objectives is reflected upon at the end of a PI planning in a session between the team and the leadership team. After presenting the business context, the individual teams meet in their team rooms (e.g. Zoom, Webex or MS Teams) and plan their todos of the upcoming PI piece by piece. The Jira extension “Easy Agile” has proven to be helpful here. It can be used to implement cross-iteration planning in a clear manner, as the interdependencies of the individual tickets are highlighted in color. A green arrow between two tickets indicates a dependency, which was planned to be valid in terms of time. A yellow arrow indicates a dependency between two tickets that were planned in the same iteration and can therefore lead to problems depending on the inner-iteration planning. Finally, a red arrow indicates an invalid planned dependency (follow-up ticket in an earlier iteration than the basic ticket).
During PI planning, it is then explicitly desired that the teams coordinate with each other if cross-team dependencies arise. In order to simplify this coordination, the URLs of the individual team rooms are known by everyone and the attendance and break times of the teams are precisely planned throughout the day. Although a foreign team member can simply “snow in” it‘s nonetheless of course helpful for both sides to address the need for such a coordination beforehand so that the team does not disturb a discussion. The PO and the Scrum Master serve as contact points for this. In addition to these internal team discussions, the scrum masters of all teams meet twice a day in order to be able to identify and resolve organizational problems or obstacles as quickly as possible.
Analogous to PI planning, the other two sprint events “Review” and “Retro” also find their partner on the PI level:
- Review: As a System-Demo every two weeks and — especially — at the end of a PI. Here every team has the opportunity to present current results to the rest of the ART in a pre-reserved slot of 5–10 minutes.
- Retrospective: As a classic retro within the Inspect-and-Adapt at the end of a PI. This appointment presents a certain challenge because:
- On the one hand, the number of participants should be as high as possible (which is achieved through imaginative implementation, such as in the case of the “Festival Retrospective”) everyone should be able to have their say.
- On the other hand, the high number of participants requires good and structured moderation.
Many Topics with many dependencies
All epics to be implemented in a PI are placed on the ART board by the teams (more precisely by the respective PO or Scrum Master). Cross-team dependencies can then be made visible. Not all epics that a team is working on are placed here, as this would severely restrict the clarity. The ART board only shows epics that either have cross-team dependencies or are particularly relevant to the program objectives and are therefore of interest to the entire ART. The 5th iteration is not planned because this is the „Innovation & Planning“-Iteration. On the one hand, it serves as a buffer for unpredictable shifts and, on the other hand, offers the opportunity for new ideas and innovations.
The individual entries in the ART board are color-coded as follows: green corresponds to an enabler, blue to a feature, red to a user story and white to an element that has already been completed. The red cards are therefore an exception to the number of epic cards — but in some cases they are still useful and necessary. The arrows are also differentiated by color: while black arrows stand for dependencies that have already been fully coordinated, agreements must still be made for the red arrows. A green arrow, on the other hand, indicates a dependency that has already been implemented. In the middle of an iteration, the current status of the ART board is discussed in a ART sync meeting among all POs and Scrum Masters and cards are moved accordingly if necessary.
In addition to the coordination of content within the ART through the regular board meeting, there are also regular meetings between the Product Owners and Scrum Masters. On the product owner side, this “PO-Sync” ensures the consistent development of an “overall product” in which all the team components fit together. While in the ART-Sync the focus is on the “who” and “when”, the product owners coordinate with each other primarily about the “what” and “how”. It is also important to consistently consider current developments with regard to the ART objectives set for the PI. On the Scrum Master side, the so-called „Scrum of Scrums“-Event primarily looks at the collaboration in the ART. The Scrum Masters agree on current issues or clarify unclear responsibilities or disagreements among the teams. Both regular meetings are organized and moderated by the RTE.
Communicate!
Especially in a big program with many dependencies between the teams a good communictation is essentially important.
In order for the communication between the teams to work well — especially in times of remote work due to COVID19 — a good medium is of outstanding importance. In the program described here, Slack is used with the following framework conditions:
- Every program member has access to Slack (that should go without saying)
- Each team has two channels:
- A public channel where people outside the team can independently enter to ask questions directly to the team
- A private channel for internal team discussions - The Scrum Masters, Product Owner, Leadership Team etc. each have their own channels
- There are channels for general announcements (#general etc)
- For spontaneous topics (incidents, etc.), separate channels are created at short notice and the necessary people are invited
- The program members adhere to the “Slack etiquette”:
- Use of the reply feature for the purpose of an overview
- Use of @here and @channel only in exceptional cases
- Consideration of the naming convention for new channels - In the case of absences, this is indicated in the Slack profile (OoO on mondays, Vacation, …).
In such a program, it is of outstanding importance that the program objectives are formulated in a clear and understandable manner and that they are still valid a year later. Only with an appropriate formulation it is possible for all program members to consistently align their own team objectives with the program objectives. Each team should ask themselves the following question in PI planning: “How and with which new features can I contribute with my team to achieve the program goals?” If, on the other hand, the program objectives are not clear or comprehensible for employees, the question changes to “We are planning feature XYZ for the next PI. Which aspect of this feature does fit with which of the program objectives? ”. That means: At first the planning of great features and only after that the question of how they actually fit the objectives. The long-term nature of the objectives is important (despite the agile project character), since a program with 250 employees reacts comparatively sluggishly to changes in strategy. A spontaneous planning is therefore rarely meaningful. However, this is not to be confused with the adaptation or change of requirements in the classic agile framework, which are of course entirely possible and desirable.
