Continuous Delivery promises to deliver more business value by bringing features in shorter lead time. It presents the golden ideal for business owners who are looking to do more for their customers, faster. But getting started requires a level of considering that goes beyond the end goal.
Most organisations look at tools and practices like Scrum, Continuous Integration, Testing, or Automation as the end state of DevOps transformation. However, there is the backbone to change that we need to start with -- finding the right team structure.
Is the concept of Autonomous Teams a DevOps & Agile utopia? DevOps culture and Agile Transformation share a lot of the same principles with teams being self-organised, cross-functional, and empowered. The critical aspect of the process is the path to get to your final organisation structure.
Is there one path for all of us? Well, it all depends on the context.
You can’t compare a 10 person startup with a 1,000 person engineering unit. You have to assess your current team structure and ask: what are the next steps to get better business results and values?
Every organization should look at the ways to improve its structure and organizations, roles to achieve better DevOps Maturity.
It was obvious as far back as the late 1960’s when Mel Convway wrote what became known as Conway’s Law:
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.”
What he meant was that the structure of the organization impacts how people work. Large teams resulted in a design by committee approach that resulted in a final product that strayed too far from the original goal.
Conway’s Law was eventually used as a way to promote smaller, more efficient teams, which produces better results than larger teams, but the problem of Conway’s Law still exists -- the structure of the company reflects the structure of the system being designed.
The structure of DevOps teams can influence how effectively they work together, the speed that they can deliver a quality product, and the longevity of the knowledge that exists within a team, among other things.
With DevOps, some structures are more conducive to these goals than others.
This is typically an anti-pattern when teams are communicating over high management where work is thrown over the fence and feedback comes back in several months.
There should always be a discussion between Product vs. Engineering vs. Quality vs. Operations due to different points of views and need to protect different aspects.
You may observe a nonsense situation where engineers will write code and features and it will be tested a few months later. That will cause engineers to need to go get the context of the feature once again, refresh code with recent changes, restart work, and then provide a fix.
Operation teams try to limit changes because stability is more important for them.
Visible indicators that you are are involved with this kind of organizational structure:
The only way is to move forward with the maturity of your organization and try to bring a bit.
With this structure, the team is formed to collaborate better around deliverables, like product designs or how to release applications.
Some shared decision making, but communication is managed. The result is more meetings to properly share the knowledge found inside the team to avoid any miscommunication.
With this structure, the first step is to integrate the teams by including engineering and quality on the same team and department.
Sometimes, though, a DevOps silo is required to support deployment. DevOps acts as a middleman between dev and ops, creating an anti-pattern.
The DevOps silo between Dev and Ops teams (source)
We beg, borrow and steal, to get the right people to work on a project. But, what ends up happening here is that everyone is working on several projects at once, meaning there’s not much talent left for new projects.
When a project wraps, some portion of each team member’s hours are released back into the pool and they’re once again “available” to work on a new project.
This results in endless frustration over how team member’s resources (aka their time) are being managed. Everyone has a full roster all the time and there’s little downtime between projects.
The big disadvantage with this setup is that teams are short-lived. Even if you find a team that you work well with, once the project is over, you’re no longer with that team.
There’s a constant need to go through form, norm, storm, and perform as part of the team lifecycle.
This setup does have it’s advantages, though. There is a standardized communication process that helps ensure that not only is communication effortless, but also that it’s the same across teams. You don’t have to switch to a different communication process every time you switch teams.
Both dev and ops also have a connected lifecycle and change management process. The tools that get used in the dev side, are used in ops to deploy. This helps eliminate the siloed team problem that arises where everyone does their own thing with different tools and processes.
Under this structure, teams are organized in one of two possible configurations:
These structures bring teams that are both long-lived and have a full understanding of their scope of responsibility. They don’t have to waste time context switching. Even when the project changes, their focus doesn’t.
This setup allows for frequent and collaborative communication and frequent releases from the teams. Not only that, but because each team owns a certain aspect of the project, there is code ownership for any defects, maintenance, and fixes that are required.
Groups have accountability, strong guidance is provided by roadmaps from the top, and there is clear accountability due to the reduced number of decision makers.
These teams often lead to innovation by design.
The best way to look at how teams organized around objectives and key results (OKR) works is to examine it from three different perspectives: people, process, culture.
In this setup, you use fullstack teams that have the roles needed to achieve success for any given project. All disciplines must be present, with a mix of technical skill levels for this to be truly successful. The goal is to get as much diversity as possible in each team, covering all possible angles (like culture and personality types (MBTI) for example).
There is job rotation in this structure, but the main focus is getting the right people for each job, rather than people moving around because there aren’t enough team members, like there is with point number three above.
Leadership plays a different role here, as well. Rather than being present to direct the project, there is more of a focus on servant leadership. They are there to help the team and ensure that they have everything needed to achieve success.
As a result of the servant leadership, teams are highly autonomous. There is a push to have as many decisions made at the team level as possible. This helps teams feel more empowered and focused on intrinsic motivation, rather than having someone directing them at all stages.
OKR places the focus on outcome, rather than output (which also happens to one of our Core Values here at GAT).
Teams have defined quarterly OKRs that map with company directions. These objectives are often somewhat lofty, but the whole point is to encourage a push towards a little something extra. Even if teams don’t quite hit their full goals, they’re still right on track to get projects done because they’ve been motivated to get a little outside of their comfort zones. There is something of a sweet spot where around 60% - 70% of teams are hitting their objectives.
Teams have a shared understanding that helps that iterate faster, without having to get permissions from other teams.
When an organization is structured around OKRs it creates a culture of trust. Unlike structures that base themselves around knowledge silos, knowledge sharing becomes a core component with OKRs.
Everything happens in public. OKRs are known across teams, past results from all OKRs are publicly known, and there are joint, cross-collaborative meetings to help ensure everything is running smoothly.
The result is a kind of radical transparency that comes from 360 degree team feedback. It encourages a culture of learning and allows individuals to really master their crafts.
Ultimately, what you’re looking for is a structure that supports better agility and increases speed of delivery, without impact quality.
The time spent on managing the teams themselves, the better. You end up with a team that can operate independently, while still hitting their KPIs.
The end goal, besides a better product, is employee satisfaction.
When you embrace change management, you want a system that focuses on continuous process improvement. In a way, it’s the CICD of the management world. There is no end state, just constant betterment.
The next article in this DevOps blog series will be focus on communication.