Scrum Master.

As a Scrum Master, I am an experienced agilist, understand and respect agile principles. Agile frameworks, with their tools, ceremonies, and artifacts, provide me with a framework for solution development that I exploit together with the team, always keeping an open mind for optimization opportunities. However, I do not violate agile principles in the process because of the extensive negative consequences. As a Scrum/Agile Master, I am always able to communicate to my team members the meaningfulness of an agile approach, using tangible examples based on my extensive experience to demonstrate both the monetary and organizational benefits as well as the consequences of non-compliance. On a team level, I am a member of a project team. I support the team methodically and organizationally, am responsible for achieving the sprint goals, and keep the team members’ backs free so that specialists can concentrate on their core tasks. To ensure the achievement of objectives, I have sub-project budget responsibility and disciplinary responsibility for my team. As a Scrum Master, I communicate with the Release Train Engineer, the Product Owner, the Business Analyst and the Product Management to align the project goals within the team.

With my structured work style and confident demeanor, I combine a supportive role for the team with active leadership in the day-to-day operations. When challenges arise, I find solutions and liaise with external interfaces to remove obstacles to implementation. As a Scrum Master, I act openly, transparently and constructively towards all project participants.

Release Train Engineer (RTE).

As a Release Train Engineer, I am a program-level member of a steering team. I support several project teams with technical and methodological knowledge and experience transfers from other teams. In addition, I am responsible for the achievement of the release targets as well as the release train and therefore actively involved in the content-related steering of the team targets. I coordinate the processes in the teams in such a way that both time windows for the delivery of sprint results to the release train are adhered to and the collaboration with the business units and project management is ensured.

With my structured working style and confident demeanor, I combine a supportive role for the program with friendly enforcement of program goals within the teams. When challenges arise, I find solutions and communicate with all assigned teams to remove implementation barriers. As a Release Train Engineer, I act openly, transparently and constructively towards all project participants.

Solution Train Engineer (STE).

As a Solution Train Engineer, I am a member of a control team at the Large Solution level. I support program-level steering teams in prioritizing and targeting solution content. My role is to ensure that programs deliver working solutions at established milestones to meet management’s project objectives in terms of time and content. When deviations occur, I work with Solution Management to restore or adjust content and schedule goals.

For implementation, I work closely with Solution Management, Product Management, Release Train Engineers and Product Owners.

With my structured work style and confident demeanor, I combine a supportive role for Solution Management with friendly enforcement of project goals in the programs. When challenges arise, I participate in solution development and interact with all assigned programs to remove implementation barriers. As a Solution Train Engineer, I act openly, transparently and constructively towards all project participants.

Demand

The Scrum Master is an indispensable role for any project team.

The Release Train Engineer is only useful for a project size of 3 or more teams, because 2 teams can still coordinate well. For teams of 5 or more, the tasks of a Release Train Engineer fill about half a day, but can still be performed by the Product Manager within this framework. From 10 teams upwards, the release train engineer becomes an indispensable role in any case, because otherwise the product manager will no longer be able to perform his actual tasks. For the number of teams, it is irrelevant for which programs or projects the teams work.

The Solution Train Engineer is only useful when the project size is 3 or more programs, because 2 programs (usually “at least” one development program and one HR program) can still coordinate well. From 5 programs upwards, the tasks of a Solution Train Engineer fill about a half-day, but can still be performed by the Solution Manager within this framework. From 10 programs upwards, the Solution Train Engineer becomes an indispensable role in any case, because otherwise the Solution Manager will no longer be able to perform his actual project management tasks. For the number of programs, it is irrelevant for which projects the programs work.

Duration

All three of the above roles are designed for long-term use in a project. Changing these roles during the course of the project carries great risks due to the experience built up over the course of the project and should only be done if it is relevant to success or otherwise unavoidable. In my case, therefore, only the use via Piterion would be recommended for these three roles.