Enabling DevOps organizations
Why would you go to a retail company to buy a product, take it home and carry it all the way up to the multiple floors of your house or flat, when you can buy the same product online and get it delivered and installed where you want it, within 24 hours or even hours in some cities?
Why not take the opportunity to buy a ticket online to the local cinema and download the app on your smartphone, since you are already in your car on your way to the cinema, and can avoid the queue?
These are just two simple examples of how digital technology has changed the way we consume products and services. Software allows us to quickly adapt the way customers consume these products and services as their needs evolve. But in doing so, we are also changing customer’s expectations and requiring other behaviors of people involved in developing and maintaining software in large organizations.
To deal with these demands and continuous organizations changes, it is critical to remain one step ahead of the competition by offering new services with the right quality. The quicker the process of creating more business value, the more responsive organizations can be in changing according to their market dynamics. It is therefore critical to support a digital transformation where organizations integrate business and IT together and introduce a DevOps organization: a team-based short-cycled way of working focusing on collaboration and automation.
Four cornerstones of DevOps
In my view, DevOps organizations have the right culture, skills, competences and technology in place to deliver more business value continuously. At Atos, we define DevOps by using four cornerstones. A first cornerstone of DevOps and an alternative to traditional project management based on incremental and iterative workstreams, the Agile methodology enjoys growing adoption. I have found that when deployed correctly in organizations, the Agile methodology is adopted throughout the business and operation layers to become the DNA of the organization. As a result, the organization can benefit from continuous learning and improvement on all its assets and processes.
The second cornerstone of DevOps is Collaborate. DevOps organizations typically have empowered, cross-functional, stable and knowledgeable teams. To maximize the organization benefits, the whole teams need to be able to collaborate both amongst themselves and also with other teams.
The third cornerstone is Standardize. Standardize doesn’t mean standardized processes, since DevOps requires empowered and self-organizing teams, but it stands for standardized proven services, like cloud services based on APIs. In the more traditional approach, a software change in the technology stack impacts all layers of the stack. To deliver the change faster and with a higher level of quality, there is a need to standardize the lower technology stack layers allowing the typical DevOps-team to focus its attention to the top two layers, Application and Configuration. In this model, the impact of a change stays within the boundaries of these two layers.
The final cornerstone is Automation. To improve quality and minimize costs, automation of repetitive manual IT tasks is mandatory. There should be no manual (preparation of) deployments anymore. An automated continuous delivery/continuous integration pipeline will technically deploy software at any minute of the day and at the end of each Agile sprint to support the business perspective.
Transforming to a DevOps organization is much more than using (new) technology and tools and bringing the development and operations together. It requires building a high performing team, where the team members have a DevOps DNA and can impose this on the behavior of other people within the organization. The culture needs to change to a self-learning disciplined organization, where everyone has the drive to improve and grow so that they can do a better job tomorrow: Learn and Improve.
But when does a team perform? In the traditional way we could easily measure performance with an agreement on scope, time and budget: fixed price/fixed scope. If the scope was realized within the time and budget, the team is seen to be successful. However, in an Agile approach, the only parameters that are fixed are time (sprint duration) and budget (team-capacity). The outcome is variable. To have an objective view on the team performance, other performance indicators need to be measured, like velocity, quality, Trailing Twelve Months (TTM), and even better indicators showing increasing business value. The teams are rewarded for their performance against these parameters and we like to call this kind of contracting: fixed performance.
This means that the Agile way of working also has an impact on the contracts and the governance of organizations.
Handling all these changes in the organization while continuing the current delivery to the business is more commonly identified as the two-speed IT model of Gartner(*). In this model, while one part of the organization is focusing on the delivery of the current business (mode 1), the other part is focusing of building the future (mode 2).
Although this model is the best way to deal with these enormous organizational changes, you have to keep in mind that at one point in time you have to let go of the first mode. So, from day one you have to design your final solution and how you want to implement it. Don’t use this model as an excuse not to transform.
Product over Process
In a DevOps organization, the focus is on continuously increasing the business value. From an IT perspective, this means that the software needed to support the business has a custom focus. So, in DevOps organizations, the overall IT landscape must reflect and enable all business entities within that organization using as much standardized software components as possible. By having a DevOps team aligned to at least one business entity, the team can ensure it is focused on the products of this entity and thus producing the additional business value.
To be able to perform effectively, the expectation is that the team takes care of a part of the business domain. However, it will need to have knowledge of not only the business domain but also a very good understanding of the technology used and its functionality. In a DevOps team, the team has the knowledge, and all team members are complementary to each other.
The team will also have the competences to own and execute all Dev and Ops activities. To avoid dependencies in the executing of the team activities, each member should be able to provide knowledge and knowhow to a number of these activities. For example, a tester should be capable of performing automation activities.
These two principles mean that a team must be made of multi-skilled and rounded members rather than experts. The definition and selection of a DevOps team is one of the most important steps in building high-performance teams.
The building of teams is inspired on Bruce Tuckman’s ‘Forming Storming Norming Performing’-model. This works well when everyone in the team performs multiple activities to all parts of the product.
These high-performance teams with a clear business (product) focus and enabled with the right level of Automation and Standardization will give your organization the flexibility, speed and quality you need to keep up to your business demands and expectations.
But stay realistic and transform step by step. Use the Agile methodology to implement Agility in your organization: define a clear vision together, think big but start small, follow a sprint-wise transformation and learn and improve all the way.