6 - Structuring Yourself for Success

Despite the opening quote, which I love and which so many organizations seem to ignore, I think a bad organizational structure can have a huge impact on how successful you are in your IT organization.

In our legacy organizations, most teams have been structured according to functional boundaries: the business analysis team, the project management office, the testing center of excellence, the development team, and the operations team. You could probably name a few more in your organization. However, this is not ideal, in part due to Conway’s law, which says that your application architecture will reflect your organizational structure, most famously shortened to “If you have four groups working on a compiler, you’ll get a four-pass compiler.”1

The advent of Agile taught us about the power of colocation and how cross-functional teams can perform faster and more flexibly. In Agile, the ideal team has everyone in the team that needs to contribute to the success of a piece of work, from business analysis all the way to releasing it to production and supporting it in production. This sounds great, but I will be honest: I have never seen this in action. I work in large organizations where this is just not easily feasible—you would have to hire an exhibition hall to get all the people required into one room. However, there are ways to define organizational structures that get pretty close to the ideal cross-functional team, and they are achievable for just about any organization, no matter what size.

Lean and Agile thinking has also taught us the value of persistent teams. In the project-driven world, we run projects, which are finite by definition and for a specific purpose. As a result, in legacy organizations, once a project is completed, the team disbands, and the team members get assigned to new projects. In these new projects, the new team members have to learn the new context and have an upskilling time before they are as productive as they were before. We can avoid this delay by utilizing persistent teams who support a product or service, a change that might best be shortened from “building teams around work” to “bringing work to existing teams.”

This change in approach requires a few organizational changes, the most difficult being that funding is often tied to projects. So, how can we get from funding projects to funding teams? There is no easy answer, unfortunately; and finding any answer tends to be difficult and context specific. A few pointers to help you with this task:

I don’t think you will solve this problem quickly, but finding a few initial workarounds to start moving in this direction should be something on your to-do list. Measure the longevity of teams as one of your transformation metrics. Make it easy for the teams to stay together and become more productive together without losing context and becoming yet another silo.

Figure 6.1 shows the organizational structure that I recommend to clients as a good starting point to structuring their teams. I call it the “burger organization chart” due to the resemblance to a stylized burger. For the rest of the chapter, I walk you through the layers of the burger and explain from the bottom up how they work together successfully.

Figure 6.1: Organizational structure starting point: This layered organizational structure works well in larger organizations

There is a lot of controversy about whether or not having a DevOps team is the right thing to do. Some of the discussions are pretty evangelistic, and I personally prefer to look at results to make decisions, not at idealistic views of the world. If you attend the DevOps Enterprise Summit or other Agile or DevOps conferences, you will notice that organizations that made progress in their transformation efforts more often than not use a DevOps shared service, a DevOps team, or something similar. In the 2016 State of DevOps Report from Puppet Labs, you will also see a lot of people self-identifying as part of a DevOps team; the proportion has increased from 2015 to 2016.2 Roman Wilsenach calls the creation of a DevOps team an antipattern;3 so, to avoid any confusion by the term “DevOps team,” I just call it the platform team (feel free to call it the DevOps team in your organization—I won’t be offended by the term). The platform team owns your development and run platform for your applications. In the end-state world, this development and run platform will act like an in-house-platform service provider that provides all your teams with self-service capabilities to support their delivery of solutions.*

Within this platform team, you will need to have people with skills across the whole set of DevOps capabilities. This means the team needs to cover infrastructure, configuration management, quality engineering, application deployment, monitoring, and release management, among others. As you can see, this is a team of cross-skilled experts, and I would expect some of your best engineers to be part of this team. Many organizations dealing with large legacy systems have structured themselves around technologies (e.g., a Windows team, a UNIX team, an Oracle team). The new platform team will still require some specialized skills for those technologies, but the focus will be a lot more on automation skills and the ability to redefine processes and architectures for the new world. As a result, you should not have technology-specific platform teams.

We were working with an insurance company for which we were able to create a service catalog of this platform team across about a dozen different technology stacks (over forty services, such as application deployment and application compilation). For each service, we could then evaluate progress over time by looking at speed, reliability, and cost. This has proven very powerful to communicate some of the more technical improvements to business stakeholders.

The challenge I sometimes see with these platform teams is that they perceive themselves as “guardian” of DevOps rather than a service provider, and make it difficult for teams to adopt the platform. It is common to underestimate the level of change management required to make the adoption a success. When the platform is not able to support the teams in a way that makes life easier for teams, then those teams will look for alternatives to the common platform by creating their own custom solutions. A collaborative and flexible approach is required by the platform team to work with the teams they are providing the service for. Their platform should make doing the right thing easier than doing the wrong thing. It is also helpful to have some technical coaches in this team that have the capacity to sit with the teams when problems arise. Alternatively, you can rotate people between feature teams and the platform team or you can loan platform team members to feature teams, as this will help to break down cultural silos that might otherwise appear.

The platform team will evolve over time. When you initially form it, there will likely be many activities that require manual tasks, which means this team will be quite large; but it will shrink as more automation is introduced. To be able to introduce more and more automation over time, you will have to create sufficient capacity in the team to make the required improvements; otherwise, the old saying will become true: “We are too busy to help ourselves improve.”

The accountabilities of the platform team include the following across development, test, and production environments:

You can see that it will take a while until you have a fully automated delivery platform, and managing the ongoing evolution of the platform team is a crucial aspect of your transformation. I am skeptical that this can be done as a big-bang project, as I have never seen anyone who could find a way around the number of unknowns and the speed of change in tools and technologies that can be leveraged. A structured roadmap and continuous improvement will create the best delivery platform for your organization.

One more tip from personal experience: the platform team needs to have change-management capability. Technical people tend to assume that once the right tools are in place, everyone will just follow the “right” process. This method usually fails. You need someone who is able to create trainings, run workshops, and deal with the users of the platform to understand the “experience” on the platform. I had a client who, after a workshop, said that they didn’t need help with their DevOps transformation, because they had all the tools installed and it was just a matter of getting people to use those tools. Of course, the same client called again a few months later to discuss why their transformation had come off the rails. Take my advice and staff change-management people on the platform team. The engineers will love it, too, as they will get help with some of the required documentation they would otherwise have to do themselves.

The “meat” of the burger is the Agile teams—where most of the work is being done. For this book, I will ignore the fact that some of the delivery teams will be Waterfall project teams that continue to work in a traditional way (there is a lot of literature out there telling you how to deliver well with traditional teams). Instead, I will highlight the Agile-focused delivery teams, as this route requires changes to your organization.

Let’s start by discussing the composition of these teams. A lot has been said about cross-skilled teams and bringing operations people into the teams to achieve DevOps, in effect adding more and more people with specialist skills to an ever-increasing team. For me, just bringing more and more people into the same team is all too simplistic, as it does not scale well in complex environments where many different skills across Dev and Ops are required to achieve an outcome. Rather than bloating the team by adding people, we need to focus teams on building the product and, in this process, consuming services from other teams that are nondifferentiating, like application deployments. The Agile teams should have a product owner, business analysts, a Scrum master, developers, quality engineers, and testers in the proportions that are required to design, build, and test the system. Over time, each team member should build skills across multiple dimensions, aiming for a T-shaped skill profile.† We will let the platform team deal with how the application gets deployed and how the environment needs to look for the application to run well. The Agile teams will collaborate with the platform team, but they don’t need to have a full-time DevOps engineer in their team; when more support is required, a DevOps engineer can be loaned to the Agile team as required, full-time or part-time.

Furthermore, in most organizations there will be an external testing team to support later phases of testing. The accountability of the Agile teams is really to get the system into a state that it is as close to releasable as possible. For this to be efficient, the Agile team will use definitions of ready to determine when a user story can be used for delivery and has sufficient detail to become part of the sprint backlog. It uses a definition of done to determine when all activities that can be completed during a sprint/iteration are completed. Typical definitions of ready include the following: story has been sized, wireframes have been agreed, acceptance criteria and test cases have been defined. Definitions of done should, at minimum, include the following: code has been developed, functionality has been documented, story has been tested at unit and application level, and product owner or delegate has seen and accepted the story.

From a DevOps perspective, the Agile teams should be responsible not just for delivery of new functionality but also for fixing any production defects or minor changes coming from production. The teams are responsible for the application they are building and are not handing it off to some other “production team” or “fix team.” This changes the incentive for good code and maintainability of the application significantly.

This shift in end-to-end responsibility means that Agile teams should be meaningfully aligned to business processes. The best way to do this is by having one or more Agile teams supporting a value stream in your business. Large organizations will need more than one Agile team to support their business value streams, which is where the SAFe concept of release trains comes in to orchestrate and manage a group of Agile teams to support a value stream.‡ Within this group of Agile teams, the technical composition of those Agile teams requires some consideration.

Ideally, you want to have Agile feature teams that can deliver functionality independently. Those Agile feature teams have developers from all the impacted applications and can develop across system boundaries. This works better when all the developers are from the same organization and are in the same location. As you start using more than one system integrator in multiple locations, I believe this model breaks down, as it requires too much orchestration within the same Agile feature team, and the distributed nature makes it difficult to develop a common team culture across organizational boundaries.

If you are working with multiple vendors, you can use Agile feature teams successfully if you can colocate them in the same premises, as colocation usually overrides cultural differences over time. Or you might want to explore a captive model offshore. In captive models, your vendors work on your premises under your direction, which gives you more control over the work methods and culture of your delivery teams.

If you are working with only one vendor as strategic partner, then you can make a distributed, multitechnology Agile feature team successful, as there is some cohesion due to the organizational guidance between the two organizations. Having both multivendor and multitechnology in a distributed Agile feature team is extremely difficult in my experience.

Figure 6.2a: Agile team scenario 1: Agile feature teams in one location can be from multiple vendors and support multiple technologies

Figure 6.2b: Agile team scenario 2: Distributed Agile feature teams ideally consist of one vendor only

Figure 6.2c: Agile team scenario 3: Agile component teams in multi vendor, multi location scenarios

The alternative team model is to define Agile component teams along application or technology boundaries. This is the best approach for multivendor, multilocation models. It requires more cross-team orchestration, but this can be achieved through common planning and synchronization events like the PI planning and systems demo in SAFe. While this is not the ideal model, from my delivery experience, this model is far easier to manage in the multivendor, multilocation scenario.

I want to offer one last comment on team structure before we move on to test automation. Colocation versus distribution, in my experience, is a balance between flexibility/speed (having the team colocated with your business) and cost (having more members of your team offshore). You will have to decide what is more important for your organization. All things being equal, distributed teams carry higher management cost and require more time for delivery, but high-performing distributed teams still beat the average colocated team on both dimensions. Your context and your knowledge of the teams should guide you here.

Test automation initiatives are the DevOps-related capability that I see fail more often than any other initiative, yet they are a very important prerequisite for many of the things we want to achieve to maintain high-quality outcomes. In the high-level organizational structure, I put in a test automation center as a transitionary state. I believe that most organizations will need the center to have someone with a dedicated focus on making test automation work and to create the overall test automation framework. This is the scope of the test automation center, which is staffed by test architects and test automation engineers who own the test automation framework. Over time, this function and team will disperse, and test automation will be supported by the test engineers and architects within the application team. They are supported by a dynamic community of practice where the test automation framework is being maintained in an open-source fashion. Of course, organizations can choose to make this team a permanent fixture. Given that this team is much smaller in comparison to traditional testing centers of excellence, it is also a lot cheaper.

I spoke earlier about defining Lean governance processes for your organization that rely on objective measures and not subjective concepts. Naturally, this governance needs to have a “home,” which is what this governance and coaching team represents. At the beginning of the transformation, when your rate of transformational change is still high, this team is a bit larger, as it also contains your organizational coaches, your Agile coaches, and a transformation governance function, which all reduce as the rate of change reduces. Let’s talk about the different aspects of governance that are required to be covered by this team.

It is an unspoken secret that your application architecture will be the determinant factor on how fast you are able to deliver. Architecture governance has, therefore, three main purposes:

It is important to mention that architecture governance needs to be done in close collaboration with the application teams to avoid creating an ivory tower function that is prescribing ideals that are beyond practicality.

There are many different delivery methods available to organizations these days. The method governance function makes sure that the most appropriate method is being used for each initiative. It also engages with teams to coach them in how to apply those methods and how to maintain the company’s internal definition of the methods to provide a common framework for everyone to use. I have learned from my engagements that a proliferation of terminology and practices without common framework leads to friction as you adopt and scale Agile methods.

Speed to market is our key goal, yet doing this without the right quality defeats the purpose. The delivery-quality governance function looks at measures across the SDLC to identify where quality concerns arise and how to improve the overall delivery quality without impacting speed or cost of delivery in the long run.

As mentioned before, a rigorous continuous-improvement governance function is key to the overall transformation. For each larger initiative, this function will support the definition of success measures, the baselining of those measures, and the evaluation of success afterward. It will also be the owner/manager of the continuous-improvement funding who supports the most promising improvement initiatives following a weighted shortest job first (WSJF) approach. Under a WSJF prioritization, initiatives of similar benefit are prioritized by size. The smaller they are, the higher they will be prioritized, hence making sure that feedback cycles are as fast as possible.5

You might wonder why my organizational structure does not have a project management office and why I don’t mention project managers in the team section. I am not in the camp of people who believe project managers are a thing of the past. I think there is a good reason to have project managers. In this structure of persistent teams, however, the project managers don’t really fit in. By definition, a project is something that exists for a specific period of time to achieve a specific outcome. As such, project managers will be responsible for managing the delivery of projects through the team structure indicated. There should be a lot fewer projects in this end state as the work flows toward teams as Agile work items (epics, features, or stories), which means you will have fewer project managers. But for large, complex projects, you might employ a project manager to manage delivery across the teams and to report on all the work specific to the project—something that might otherwise be difficult to get out of the delivery teams who are working more holistically on the backlog. The role of the project manager should therefore be a more active and involved role that goes beyond the management of project plans and includes active contribution to the Agile planning events as stakeholder.

First Steps for Your Organization

Identify One of Your Value Streams and the Required Teams to Support It

We have spoken about creating a value stream map before (in chapter 2). What we are looking for here is to identify value streams from a business perspective. Once you have identified the value stream, the next step is to identify the systems that support the value stream.

Looking at your backlog of work or your portfolio of initiatives, identify how much work impacts the systems supporting this value stream. On this basis, you should now be able to create a team structure supporting this value stream. It won’t be perfect, and you will have to adjust it over time; but you now have a starting point. Using the SAFe terminology, you have identified an Agile release train, and you can now go on to deliver work through this team structure to support the value stream. Over time, you will be able to shift the budgeting model to support the teams as I mentioned earlier in the chapter.

Identify the Teams That Will Be Impacted by the Move to a Platform Team

The platform team is a concept that is very transformational, and the change required is often underestimated. To help you navigate this change, I want you to identify all the teams that are currently performing functions that would ultimately be performed by the platform team or would be impacted by the platform team (e.g., infrastructure teams, testing teams, database administrators [DBAs]). Invite them to a workshop to discuss what the delivery platform at your organization should look like from a functional perspective. Once you have a level of agreement on that, discuss how the delivery platform should be supported. Hopefully the platform team emerges as something that everyone can agree on. Then agree on next steps to get closer to achieving this end-state vision.

* For an interesting discussion on possible DevOps organizational structures, you can check out Matthew Skelton’s blog post “What Team Structure Is Right for DevOps to Flourish?” The structure I represent here is close to type 4—the DevOps as a service model—in this case, for internal teams.4

† T-shaped people have a working understanding of many areas and are deeply specialized in one of them (compared to I-shaped people, who know only one area). See the appendix for details.