During a SAFe RVA meetup session with several top businesses in the Central Virginia region, I was honored to give a presentation around the SAFe System team – a history and evolution. It was great to get direct feedback from local SAFe practitioners since before and after my keynote presentation, attendees participated by sharing experiences and interests in learning more about SAFe. Specifically, I shared several examples during my early Release Train experience with System teams while SAFe was still in development and discussed more current cases as well. In 2010, Release Trains within a global consumer telecommunications product company division were developing into a 5-10 team Program, with only one QA person assisting with automated testing and deployment acting as the “System Team.” With the later evolution of the program, that same QA automation expert was aided by an operations group that ensured hardening and integrated system demos were successfully completed. The “one person” System Team had evolved to a more conventional multi-person team that is represented in the current SAFe Model. At the same time, the one QA person in the Program continued to rotate from team to team as an extended team member while additional ops folks stayed on the periphery to assist with continuous integration and prepared for hardening and multi-team-integration/demo sprints.
At the other extreme and more recently at a healthcare client, a much larger System Team consisted of (1) an infrastructure design and build out team (2) an architecture component team as well as a day-to-day operations and environment support team operating in a Kanban workflow system. Those teams began to split later in their evolution as a Portfolio-level architecture and design with Program-level ongoing team support for integrated demos, automation at all levels and test-first method support. After hearing these examples and the “textbook” SAFe System Team description, folks present at the meeting from a local consumer finance company agreed that sticking to the current SAFe model best represented the “right-size” approach to System Team setup.
In addition to the structure of the teams, I shared the various methods that the Systems Teams had used to structure the delivery of their work. The smaller Systems Team(s) had no internal work delivery methodology specific to the systems work, rather they leveraged stories within Scrum teams that were serving. The larger System Teams would generally either organize as a Scrum Team themselves, utilize Kanban or some combination of both. The largest team in my experience had a day-to-day Kanban system for support tickets while a Scrum board for planned test and automation infrastructure development.
In the end, the I recommended that companies take a hard look at their current state of infrastructure support, the level and frequency of code/system integration as well as all code, test and deployment automation needs as they staff the Systems Team. While the examples I used showed how much that staff can vary, the best practices incorporated into the latest version of the SAFe model work as an ideal starting place at initial program launch.