. . . a holistic or “rugby” approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.
—Nonaka and Takeuchi, The New, New Product Development Game
ScrumXP is a lightweight process for cross-functional, self-organized teams to deliver value within the context of SAFe. ScrumXP combines the power of Scrum project management practices with eXtreme Programming (XP) technical practices.
Most Agile teams use Scrum as their primary, team-based project management framework. A lightweight yet disciplined and productive process, Scrum allows cross-functional, self-organized teams to operate within the context of SAFe. It prescribes three roles: Scrum Master, Product Owner, and Development Team.  The Scrum Master is a servant leader who helps the team adhere to the rules of Scrum and works inside and outside of the team to remove impediments. The Product Owner (PO) is responsible for defining what gets built. When extended by Lean quality practices and engineering techniques inspired by eXtreme Programing (XP), the ScrumXP team provides the basic Agile building block for SAFe.
But, of course, ScrumXP teams do not work in isolation. Each team is part of the larger Agile Release Train (ART), where they cooperate in building the larger system.
The ScrumXP Agile Team is a self-organizing, self-managing, and cross-functional group of five to nine people, collocated wherever possible. The size and structure of the team are optimized for communication, interaction, and the ability to deliver value. Self-organization implies that there is no team leader or manager role that tasks the team members, estimates their work, commits the team to specific objectives, nor determines how exactly they will advance the Solution. The team is presented with the intent of the Iteration and is solely responsible for determining how much of that scope they can actually commit to, and how they are going to build that increment of value. The team is cross-functional, so it has all the roles and skills needed to deliver an increment. The self-organization and cross-functional nature of the team, along with constant communication, constructive conflict, and dynamic interaction, can create a productive team and a more enjoyable work environment for the team members.
Scrum defines two specific roles, the Product Owner and Scrum Master, who are members of the Agile Team, each with a unique and specific set of responsibilities. Each of these roles is elaborated further in a SAFe article by that name. A summary of the responsibilities for each is provided below.
Product Owner (PO)
Each ScrumXP team has a Product Owner who is responsible for the Team Backlog. The interaction of the PO with the rest of the team is a significant, daily, and highly focused effort. Therefore, the most effective model is to have a dedicated PO for each team, or to share a PO across no more than two teams. This allows the PO to effectively support the team during Iteration Execution by answering questions, providing more detail on the functionality under development, and reviewing and accepting the completed stories into the baseline.
Scrum Master (SM)
The Scrum Master is the facilitator and Agile coach for the team. Primary responsibilities include ensuring that the process is being followed, educating the team in Scrum, XP, and SAFe practices, and providing the environment for continuous improvement. The Scrum Master is also typically charged with leading the removal of impediments. The Scrum Master may be a full- or part-time role for a team member. Alternately, some dedicated Scrum Masters may support two to three Scrum teams.
The Scrum Process
The Scrum process itself is a lightweight project management framework that fosters quick, iterative advancement of the solution and facilitates continuous improvement in support of higher productivity and quality and better outcomes. The process is centered around the iteration (note: Scrum uses the term Sprint; SAFe uses the more general term iteration)—a short timebox, two weeks in the case of SAFe—during which the team defines, builds, tests, and reviews results. The Scrum process is further described in the sections below.
Planning the Iteration
The iteration starts with Iteration Planning—a timeboxed event (four hours or less) during which the Product Owner presents the Stories for the iteration. The team then reviews the stories, defines the acceptance criteria, splits larger stories into smaller ones where necessary, estimates them in story points, and, finally, commits to what they can build, based on their known velocity (story points per iteration). Many teams further divide stories into tasks, estimating the tasks in hours to better refine their understanding of the work ahead. Finally, the team commits to a set of goals for the iteration.
Even before the iteration starts, the ScrumXP team is preparing content for the new iteration by refining the team backlog items to make sure they understand the work to be delivered during the upcoming iteration.
During execution, the team builds and tests stories, with a goal of delivering a story or two every few days. This serialization limits work in process and helps avoid “waterfalling” the iteration. Teams use “big visual information radiators” (BVIRs) to understand and track progress during iteration execution. The team’s story board visualizes the stories and their progress throughout the iteration. In so doing, they often use development steps as the columns and move stories left to right over time, as Figure 1 demonstrates.
Some teams also apply Work-in-Process limits to some steps to create a “pull” process within the iteration, and to continuously balance the work to increase throughput. Indeed, many teams integrate the best practices of Scrum and Kanban to facilitate the flow of work through the iterations. In this case, the simple story board above evolves into a more structured Kanban board. See the Team Kanban article for more on the use of Kanban by ScrumXP teams.
Coordinating with Daily Stand-up Meetings
Each day, the team has a formal ceremony—the Daily Stand-up Meeting (DSU)—to understand where they are, escalate problems, and get help from other team members. During this meeting each team member describes what they did yesterday, what they are going to work on today, and any “blocks” they are encountering. As this is a daily coordination meeting, it has to be kept short and to the point by the Scrum Master. The DSU should take no more than 15 minutes and is done standing up in front of the story board.
Team communication does not end there, however, as team members interact continuously throughout the iteration. The facilitation of such communication is the main reason why ScrumXP prefers that the team be collocated whenever possible.
Demonstrating Value and Improving the Process
At the end of each iteration, the team conducts an Iteration Review and an Iteration Retrospective. During the iteration review, the team demonstrates each story accomplished during the iteration, the summation of which is the team’s increment of value for that iteration. This is not a formal status report; rather, it is a review of the tangible outcomes of the iteration. Thereafter, the team conducts a brief retrospective, a time to reflect on the iteration, the process, things that are working well, and current obstacles. Then the team comes up with improvement stories for the next iteration.
Building Quality In
As a tenet of SAFe says, “You can’t scale crappy code.” Therefore, one of the Core Values of SAFe is “Built-in Quality.” Built-in Quality begins at the code and component levels by those who create the solution, otherwise it is difficult or impossible to ensure quality later as the solution integrates and scales from component to system and solution.
To make sure teams build quality in to code and components, SAFe describes five engineering and quality practices that are inspired by the tenets of XP and that augment the project management practices of Scrum. They are Continuous Integration, Test-First, Refactoring, pair work, and collective ownership. Some teams use other XP practices in addition to these five, such as a pair programming and metaphor .
ScrumXP Teams Are “on the Train”
While the teams are cross-functional, it isn’t always realistic for a team of seven or eight to deliver end-user value when a large system includes different technology platforms and a spectrum of disciplines including hardware, software, and systems engineering. Many more teams are typically required. To address this, SAFe Agile Teams teams operate within an Agile Release Train (ART), which provides mission alignment and a collaborative environment whereby teams can cooperate with other teams to build the larger solution capabilities. As part of the ART, all Agile Teams plan together, integrate and demo together, release and deploy together, and learn together, as illustrated in Figure 2.
Each team’s participation in this “shared responsibility program” is further defined in the Agile Teams article.
Leadership of ScrumXP Teams
Managers are typically not part of the cross-functional team. However, the initial organization of such teams around features, components, and subsystems and the design and structure of the ART is typically a management responsibility, based on input from the teams. Thereafter, the ongoing management of such teams typically undergoes a qualitative shift, from manager as expert, directing the team to specific technical achievements, to manager as a Lean-Agile Leader and enabler and developer of people.
Learn More Kniberg, Henrik. Scrum and XP from the Trenches. lulu.com, 2015.  Beck, Kent and Cynthia Andres. Extreme Programming Explained: Embrace Change, 2nd edition. Addison-Wesley, 2004.  Sutherland, Jeff and Ken Schwaber. Scrumguides.org.
Last update: 21 June, 2017