DevSecOps is quickly becoming one of those trendy terms that everyone tries to use on social media. If you can somehow work #devsecops into a post, you’re using today’s forward-looking language.
The problem is that many articles and blogs miss some of the most important aspects of what makes a great DevSecOps team a valuable asset to an organization. If you look at the DevSecOps Manifesto, you’ll see a common thread of community-related phrases such as “like us,” “we will” and “we won’t.” DevSecOps was envisioned from the beginning as a team endeavor, as opposed to a loose collection of people with technical expertise.
Much like a sports team, a DevSecOps team brings a group of people together who each possess different skill sets in a structure that benefits their organization. In sports, a successful team is one that defines specific roles for different aspects of the game and leverages each of those roles working together to reach a common goal.
And DevSecOps is not like just any type of sport, but a contact sport. In contact sports, no one does their job in isolation. Each member of the team gets in close and personal to get the job done. A DevSecOps team may not get physical on the job, but figuratively, conflicts and collisions occur often. Understanding how to handle the bumps and bruises of working on an interdisciplinary team can mean the difference between dysfunction and consistent effectiveness.
Let’s explore how looking at DevSecOps as a team contact sport can help provide guidance on a holistic approach to better managing your team.
Most organizations that implement DevSecOps do so to proactively increase product quality. The whole purpose of DevSecOps is to move quality and security “to the left” in the software development lifecycle.
Team membership is generally based on technical requirements. You’ll need representatives from development, security, and operations organizations. If you’re new to building hybrid teams, you might notice an early tendency of many team members to emphasize their own role’s importance over other roles. Developers may look at security and operations as being “lesser” players, while security and operations each perceive themselves as the more influential players.
This tendency toward overinflation of self-worth is common, often unintentional, and in most cases minor enough. However, over time such unconscious bias can lead to grouping with other team members in similar roles that can stifle free expression and diminish the stated DevSecOps goals of open contribution and collaboration and shared threat intelligence.
Many of the shortcomings of DevSecOps teams are in the area of destructive team dynamics, not technical deficiencies. It is often easy to identify DevSecOps team candidates for any organization based on technical skills and experience. In most cases, you already have most of the team members you’ll need in the organization; all you have to do is attach them to the team. But all too often, management fails to explore how well each team member will integrate into and enhance the operation of the team.
Sports teams, especially collegiate and professional teams, spend substantial effort balancing technical skill needs with how well a prospect integrates with the team. The most successful team managers have learned that a great player won’t help the team if they don’t work well with everyone else. Both technical and soft skills are mandatory for team success, and DevSecOps teams are no different. Coordination is just as important as any individual’s skill.
Simply putting a group of technically proficient individuals together doesn’t guarantee an effective team. Most of the obstacles DevSecOps teams encounter relate to soft skills, with team dynamics deficiencies being a common pain point. Just like a traditional sports team, each DevSecOps team member must understand their role and how that role interacts with other roles to effectively satisfy goals.
Using American football as an example, there is only one quarterback, but that quarterback can never succeed without every other offensive player working together to ensure that every play succeeds. There are bumps and bruises along the way, and some of those are a result of colliding with your own team members, but they are necessary to advance the ball.
Technical preparedness has become a badge of honor among technical professionals. Take a look at most technical people’s email signatures and you’ll find a list of certifications. The length of the certification list subliminally equates to one’s technical “weight.” However, certifications and technical training only address one aspect of a DevSecOps team’s needs.
DevSecOps teams need far more soft skills training than technical training. While ongoing training in technical areas is beneficial and necessary in rapidly changing domains, soft skills training makes proficient technical personnel better team members. You can see this concept echoed over and over in many contexts. The 1977 disaster in Tenerife, in which a KLM 747 collided with a Pan Am 747 and killed 583 people, was a result of poor communication and a lack of coordination among the KLM crew. That disaster led to sweeping changes in the airline industry and a focus on crew resource management.
DevSecOps outcomes rarely mean the difference between life and death, but a poorly functioning team can directly affect the team’s ability to meet quality goals. Organizations that view a DevSecOps team in light of the sports team analogy will have an easier time elevating the importance of soft skills that lead to more functional teams.
Ongoing skills training is important for all DevSecOps team members, but that training shouldn’t focus only on technical skills.
Getting on any team should be a result of meeting skills requirements. The fact that you’re on the team means you made the cut. New teams may “try out” potential members, but when the final roster is set, there shouldn’t be any concerns about glaring technical deficiencies. Don’t ignore technical skills — they are necessary to be effective in any technical role — but once those requirements for DevSecOps team membership is met, focus on the team.
The Project Management Institute’s (PMI) Project Management Body of Knowledge (PMBOK) Guide defines one of its 49 distinct processes of managing projects as “Develop team.” (Technically, a DevSecOps team is an ongoing entity and not a project structure, but the PMBOK’s process descriptions still apply.) This crucial process doesn’t just happen once; it can happen any time the team changes. Developing the team refers to any activities to prepare the team to carry out its mission, so don’t ignore the nontechnical training!
Effective teams are teams that work together well. That sounds like an oversimplification, but think of a time when you worked on a team that failed to meet its goals. Chances are that team suffered from poor team dynamics. Basic team dynamics and communication training can go a long way toward making teams more effective and fostering a more pleasant work environment.
DevSecOps team leaders should prioritize ensuring effective team dynamics over ongoing technical training. There are many approaches to building effective teams, but all should focus on breaking down bias and other obstacles that can derail positive momentum.
Here are a few tips on building more effective teams:
These tips can help DevSecOps team move beyond a loosely related group of technical personnel into a cohesive team that improves quality. Approach your DevSecOps team like a contact sports team and you’ll be better prepared to move the ball together.
