DevOps Handbook Series Part 2: Defining DevOps Teams

Jumping into The DevOps Handbook Series halfway through? Read up on the previous installments here first:

• • Introduction Summary
  • Establishing the Three Ways
  • The Three Ways Continued
  • Begin the DevOps Methodology

Having identified an appropriate value stream in the previous post, today concludes Part 2 of The DevOps Handbook.

In this summary installment, we examine how to organize our teams with DevOps best practices in mind. This is notably relevant as architecture and team organization dramatically affects work performance and software. It is on this very concept that Conway’s Law is founded.

Organizing DevOps Teams and Architecture According to Conway’s Law

Author Eric S. Raymond conceived a simplified form of Dr. Melvin Conway’s original results as:

“The organization of the software and the organization of the software team will be congruent; commonly stated as ‘if you have four groups working on a compiler, you’ll get a 4-pass compiler.’”

Having multiple compilation units/people in the value stream (4 here), increases the number of steps source code must ‘pass’ before it reaches completion.

If followed improperly, Conway’s Law negatively impacts an organization’s production outcomes and prevents agility. When executed properly, developers are empowered to develop, test, and deploy with independence—generating significant value for the customer.

If you’re looking for ways to integrate DevOps into your organization, give Caylent a try here.

To embody DevOps best practices, we must organize our teams with certain insights in mind. This strategy should include making the most advantageous use of Conway’s Law:

• “Organizational Archetypes.” Businesses invariably fall into one of three organizational structures:
  • Functional: Companies who optimize for skills, labor division, and cost-reduction.
  • Market: Businesses who optimize for delivering value to customers at all cost.
  • Matrix: Organizations who attempt to combine both of the above orientations.
• “Problems Often Caused by Overly Functional Orientation (‘Optimizing for Cost’).” Traditional IT teams tend to split and organize themselves according to specialty. This has a compounding effect on the value stream by vastly reducing work flow and exacerbating long lead times. Other problems; poor handoff coordination, an increased amount of re-work, low-quality results, and bottlenecks are more widespread too.
• “Enable Market-Oriented Teams (‘Optimizing for Speed’).” DevOps best practices largely advocate “optimizing for speed” over cost to improve the ability for small teams to deliver on customer value quickly. Extreme versions of such teams are cross-functional and independent. These true DevOps teams can quickly become proficient in feature development on top of many other capabilities.
• “Making Functional Orientation Work.” The Handbook does not dismiss functional-orientation entirely. In the right high-trust culture, organizations can achieve high-velocity, effective work flow by enabling automated self-service platforms and promoting full transparency in work prioritization.

Functional vs. Market Orientation Work: The DevOps Handbook (1st ed. 2016) Kim et al.

• “Testing, Operations, and Security as Everyone’s Job, Every Day.” High-performing DevOps teams have one shared trait: the whole team shares a common goal. The goal of making quality, availability, and security “a part of “everyone’s job, every day.”

Jody Mulkey, CTO at TicketMaster highlights this theory in his DevOps American football metaphor:

“Ops are the offensive linemen, and Dev are the ‘skill’ positions (like the quarterback and wide receivers) whose job it is to move the ball down the field— the job of Ops is to help make sure Dev has enough time to properly execute the plays.”

• “Enable Every Team Member to Be a Generalist.” Over-specialization, an extreme consequence of functional-orientation, can cause siloization. (When team members are isolated in their contributions to the value stream and have no alignment with others.) To counter this, encourage people to become generalists by providing varied opportunities for skills development. Encourage a growth mindset in your organization and hire for generalist skills.

Specialists vs. Generalists vs. “E-shaped” Staff (experience, expertise, exploration, and execution): The DevOps Handbook (1st ed. 2016) Kim et al.

• “Fund Not Projects, Rather Services and Products Instead.” Adopt a product-based funding model, enabling teams to finish projects fully—delivering value to internal and external customers. With correct funding, DevOps teams are able to implement and execute self-devised strategies to fulfill customer value goals.
• “Design Team Boundaries in Accordance with Conway’s Law.” One of the biggest challenges faced by organizations is sustaining effective team coordination and communication. Empower small teams to be able to work independently of others without the need for superfluous communication and coordination.
• “Create Loosely-Coupled Architectures to Enable Developer Productivity and Safety.” By encouraging loosely coupled architecture, we can avoid small changes having a snowball effect and instigating major failures. Architecture which creates freedom for teams to self-sufficiently implement, test, and deploy code into production boosts performance productivity and output.
• “Keep Team Sizes Small (The “Two-Pizza Team” Rule).” Conway’s Law advocates small team sizes to reduce inter-team communication and keep the work scope feasible and bounded. Small teams can operate at speed; free of “administrivia.” Amazon suggests DevOps teams that two pizzas would feed (5 – 10 people).

Merge Dev and Ops Together at Every Stage of the Process

Making Development work more visible to Operations is the key to establishing the DevOps culture. There are three broad strategies which can accomplish this:

1. Empower developers to become more productive by creating self-service proficiencies
2. Integrate Ops engineers into your service teams to encourage collaboration
3. Include Ops engineers with all daily Dev work from inception to project conclusion

To achieve these strategies:

• “Create Shared Services to Increase Developer Productivity.” Get Operations to build platforms and services which will boost Development efficiency. Encouraging the creation of DevOps tools optimized for internal customers (Dev teams) reduces Ops becoming a bottleneck in the value stream and enables the realization of market-oriented goals.
• “Embed Ops Engineers into Our Service Teams.” Integrating Ops into Dev teams early on is fundamental to fostering closer interaction on production responsibilities. On top of that, merging the two connects Ops to service delivery and support, and promotes cross-skills training.
• “Assign an Ops Liaison to Each Service Team.” If it is not possible to embed an engineer within a service team, delegate an Ops liaison to coordinate with the team directly. This will motivate Dev and Ops to collaborate better at all project stages.
• “Integrate Ops into Dev Rituals.” With Ops engineers—or a liaison—working closely with Dev teams, it’s important to ensure they get involved with all existing development culture and practices. This way, Ops can better plan and influence work early on, pre-production.
• “Invite Ops to Our Dev Standups.” One of these rituals is the Scrum daily standup, where everyone shares what work was completed yesterday, what is to be done that day, and what is preventing them from moving forward. With Ops present to listen to Devs describe this, they can glean valuable information which may affect their own activities.
• “Invite Ops to Our Dev Retrospectives.” Just as crucial as the daily standup is ensuring that Ops attend Dev retrospectives at the end of each development interval. This agile practice encourages a review of past tasks, promotes feedback and improvement for future work, and prompts organizational learning within teams.
• “Make Relevant Ops Work Visible on Shared Kanban Boards.” As established in The Three Ways principles, the visualization of work between Dev and Ops is an integral component for improving work flow. This does not simply mean that Devs share their work, it is vital to highlight relevant Operations activities. Kanban boards are an excellent team management tool to achieve this. Implementing this strategy can help to prevent Operations crises in production and reduce blockages on product delivery.

Up next: DevOps Handbook Series Part 3: Exploit Continuous Delivery….

Caylent is a cloud-native services company that helps organizations bring the best out of their people and technology using AWS. We are living in a software-defined world where technology is at the core of every business. To thrive in this paradigm, organizations need to empower their people and processes through technology. Caylent is uniquely positioned to fuel that engine of innovation by bringing ambitious ideas to life for our customers.

Caylent works with customers to build, scale and optimize sophisticated cloud solutions using deep subject matter expertise to deliver world-class outcomes through an agile co-delivery model.

Reference material:
Kim, G., Debois, P., Willis, J., & Humble, J. (2016). The DevOps handbook: how to create world-class agility, reliability, and security in technology organizations. Portland, OR: IT Revolution Press, LLC.