“Break down barriers between departments. People in research, design and production must work as a team to foresee problems of production or in use …”
As coaches, we are often asked to help SAFe ARTs (Agile Release Trains – teams of Agile teams) improve their development/testing practices to optimize their delivery of customer value. Yet, technical improvements of D|B|T (Design, Build Test), are only part of the value stream optimization equation. The other “+” is the deployment pipeline (D|B|T|”D”eploy).
To codify the various roles representing deployment practices, Scaled Agile utilizes a collection strategies called DevOps. (If you haven’t already, check out “What You Need To Know About DevOps” for more.) Many organizations do not have a designated team called DevOps, and rightfully so; but they do perform these essential roles every day. Unfortunately, more often than not, these activities are disconnected from the demand flow of business needs.
In a SAFe world, we consider these roles and activities to have an equal seat at the table. In order to optimize the flow of work and increase the delivery of value, a “systems thinking” approach is critical and DevOps activities are most certainly part of the “system.”
In this article, we will address the definition of DevOps, it’s relationship to the System teams, and to the people who comprise DevOps.
Early SAFe coaching experiences found DevOps as a pattern of…
- A and people executing as a composite team of developers.
- System team members.
- Other production-minded folks, who build and streamline the deployment pipeline to get the software to production.
The SAFe codification and differentiation of both the System team and the DevOps practice is an important one. They are unique in purpose but act with integrated goals towards the support of the ART’s PI objectives.
The System team is focused on the Train’s D|B|T and release-packaging activities. DevOps is focused on a Train’s production deployment steps, environments, production-like systems/environments, actual production systems, and product operations.
The Systems team focuses on 4 main things:
- Streamlining development environments.
- Performing systems demos.
They support the development work of the train and have their own special ‘boxcar’ role. Together with DevOps practices, they play a key role in the “systems thinking” of how products can be built and deployed in the most effective manner.
DevOps is about the deployment pipeline operations, pushing software out to production, and managing the software during use. Scaled Agile Framework® DevOps page describes deployment operations roles as network and storage engineers, DBAs, system admins, etc. Those folks support the infrastructure. They would sit in on “Shared People” teams and support the products in production.
DevOps is a practice that includes the system team, not separate from the system team. If we allow the system team to compartmentalize themselves so that they don’t pay attention to the pipeline or to production, then the delivery of value to the user is jeopardized. To a certain extent the system team is an integral participant in the practice of DevOps.”
— Richard Lowery, Davisbase
The newest SAFe DevOps abstract under SAFe-LSE.com will expand on DevOps.
Here Scaled Agile codifies two truths about DevOps:
- They are an integral part of a value stream’s success.
- All teams on the train must take part in the practice.
“All teams on the train”, is a keystone habit of highly effective operations capable of continuous flow value through the ART. This evolves the equation even further to “D | B | T | I | D | E.” We could describe “deployment” further by adding the security and legal compliance practices as well.
As coaches, we often find little clarity around the deployment pipeline being seen as an integral part of a value streams delivery system. Instead, we find silos based on security, governance, and “IT as a black box–even inside IT” services which remain operationally bias against the continuous flow of customer value. “All products and services must stop at the Big Gate, be deeply scrutinized by teams with different biases (security, legal compliance, data center ops) and then blessed to proceed–often in a painful, drawn-out event”. Worse yet, we sometimes see large batches of often unrelated products being spooled up for months and dropped into production in large, risky chunks.
As ARTs mature their value-focused delivery processes and roles, it’s a natural pattern to “pull” these deployment pipeline and productionalization steps inside or in-step with the needs of the ARTs.
In order to improve, DevOps & Systems Team practitioners should attend Leading SAFe courses. The core values of SAFe (Code Quality, Alignment, Transparency, & Program Execution) have a place in the daily workings of both groups. After class, the ART team(s) need to be coached/facilitated through a value stream mapping exercise to discover bottlenecks/barriers that exist with the ART’s boundaries.
Practically speaking, here are two final thoughts and recommendations:
- Enhance test environment to be as close to production as possible. This will increase the predictability and reusability of tests, reduce defect resolution cycles, and provide for faster feedback.
- Remove the invisibility cloak. Operations folks tend to be sequestered “behind their firewall.” they are spread so thin [people-wise], they have no time to collaborate with other teams.
For example, one client allowed an integrated Operations person to sit within the team area. He supported the builds/deployment of 6 teams to a suite of web/mobile apps. This person was trained in Operations but because they were embedded with the teams, they had decentralized authority to build/deploy, and ran all deployment pipeline requests using a kanban system, As a result the teams had much-improved responsiveness, while the Operations had governance and more autonomy/decentralized decision making.
Have you done something with DevOps and Systems Teams that has gotten you a win? If so, share your story. We’d love to start a conversation.
1 The Fourteen Points for the Transformation of Managment, Out of the Crisis (Point 9 of the Fourteen Points of Management). Quote also referenced on Scaled Agile Framework on DevOps / Systems Team. https://www.deming.org/theman/theories/fourteenpoints
Scaled Agile Framework® and SAFe® are trademarks of Scaled Agile, Inc
Implementing SAFe 4.0 with SPC Certification | Upcoming Opportunities
If your organization is using SAFe and you are interested in becoming SPC4 certified, we invite you to attend one of our upcoming public SAFe classes. These highly experiential classes provide the perfect place for you to learn what it takes to train others in SAFe practices and principles, while also giving you an opportunity to share ideas with other Agile and SAFe practitioners and to learn from some of our most seasoned Consultants. The class is designed for middle management, directors, executives, especially at the Program and Project level.