I've had the privilege to work with some of the brightest minds and leaders in my 33 years of software engineering. I've also been fortunate to work for a manager who made me question my career daily and systematically broke down my passion—like a destructive fire sucking the oxygen out of a sealed space. It was an unnerving period, but once I broke free, I realized I had the opportunity to reflect on one of the greatest anti-patterns for effective teams.
It should come as no surprise that the culture of an organization and its engineering teams is the greatest challenge when embarking on a DevOps mindset transformation. The organization needs to influence through leadership and autonomy, promoting a culture of learning and experimentation, where failure is an opportunity to innovate, not persecute. Fear of retribution should be frowned upon like the archaic Indian practice of Sati. Teams need to feel they are operating in a safe environment, understand what the transformation entails, and know how they will be affected.
So, what is the blueprint of an effective team? The concept of autonomy, self-organization, and self-management is core to agile practice. In addition, lean practices promote reducing waste, creating short feedback loops, using lightweight change approval, limiting work in progress (WIP), reflecting and acting on feedback, and transparently visualizing work management. All these strengths need to be reflected in your blueprint.
Let's review an effective team blueprint's genetic information.
As shown in the graphic below, self-organization is a natural process that creates order within the team. It outlines HOW the autonomous team collaborates and coordinates. Self-management defines how the diverse team members work together in their own way, aligned with a shared vision and governance, owned by the leadership.
Line of autonomy and governance.
Team size is a topic that creates vibrant discussions. Some say the ideal size is 7±2, others say 6±3, while others maintain that there is no upper limit. Another argument comes from anthropologist R.I.M. Dunbar, who says in his paper on the relationship between humans' neocortex size and group size, "there is a cognitive limit to the number of individuals" in an effective team. He argues that if you want a highly cohesive team, keep your team size smaller than 12.
Amazon CTO Werner Vogels' famous quote "You build it, you run it" is reminiscent of the great thematic quote from Spider-Man: "With great power comes great responsibility." We need to foster ownership, accountability, and responsibility. Everyone in the team must be empowered, trained to run the business, responsible, and on call. When there is a live site incident, all designated response individuals, which includes members from the associated feature team, must join the 2am call to gather evidence, investigate, and remediate at the root-cause level.
EPIPHANY:
The 2am wakeup call is the best motivation for a production-ready mindset. Pull any engineer into an early morning live site incident a few times, and the quality bar magically shall improve.
Cross-functional is another key part of genetic information for an effective team blueprint. Contrary to common belief, it does not imply that everyone in the team can do everything. Instead, as shown in the graph below, the cross-functional team is based on the concept of T-shaped skills or T-shaped persons. The horizontal bar of the T stands for broad expertise and the ability to collaborate with others, while the vertical bar represents the depth of a single expertise. Assume we have a three-person team comprised of experts in development, testing, and user experience. Each has his or her own T-shaped skills. When we combine the three experts' genetic material, we get a joint T-shaped team with specialization and broad expertise that can design, develop, test, and support features as a cross-functional team. The culture of learning not only ensures that the team's combined broad and specialized expertise is aligned with business needs, but it also empowers and motivates the team and its members. Information sharing and brown bag events are two excellent team-building tools.
Shortage of testers? No problem; with the support of the test expert, the development and user experience experts can temporarily blend into a test role. When testers automate testing, learn and share good coding practices, help improve feedback loops, and help the team broaden their skills beyond unit and regression testing, the line between developers and testers begins to blur. The developer and tester roles evolve and merge into the engineer role.
This raises the question: "What if team members refuse to be cross-functional?" There is no place for heroes or knights in shining armor in an effective cross-functional team—find them another home.
Inspire and celebrate success as a team and an organization whenever achieving a goal. It motivates the team, fuels team spirit, and acts as a major source of inspiration for others to excel. Your team can enjoy a round of nachos to confirm a job well done, play and learn with a game of GetKanban, encourage team members to celebrate with their family after a hectic sprint, or review and celebrate fast feedback as part of your regular standups. The options are endless—just ensure you spend time together as a team.
For example, our scrum master always reflects on our achievements whether we pass or fail a sprint. It eventually dawned on me that it not only bonds us as a team, but others aspire to be like our team.
Finally, remember to keep it simple to reduce risk, cost of training, process, and products. Enable the just barely good enough (JBGE) approach. Simplicity positively affects maintainability and enables cross-functional teams to collaborate and fill in for each other more effectively.
You might be wondering why none of the above feels like a new revelation. As discussed in Analyzing the DNA of DevOps, we believe DevOps has inherited from decades of practices and learning, including waterfall, lean thinking, agile, and "real-world" 2am live site incident calls. We are not inventing anything new; instead, we continue to reflect, learn, and streamline our blueprint. The DevOps mindset is based on a few matured foundations, and DevOps lights up when the team is razor-focused on delivery, telemetry, support in production, and (most importantly) bonding together as a team. A team that doesn't enjoy being together is not a team; they are a group of individuals told to work together.
So, let's get back to the greatest anti-pattern I mentioned. Effective teams, who are autonomous, empowered, self-organizing, and self-managed are based on trust, inspiration, and support of their leadership. If any of these important pillars is missing, toxicity rises, passion declines, and you are an eyewitness to the most destructive anti-pattern that will doom any diverse, collaborative, and effective team.
Blueprint for an effective team with a DevOps Mindset.
So, are you on an effective team? Have you experienced anti-, negative, or positive patterns that have affected your DevOps transformation? Let us know in the comments!
1 Comment