Firms that pursue the DevOps path to strengthen their Agile delivery models often run up against organizational barriers. Modern lifecycle management tools do help soften this path and are invaluable to a firm’s DevOps progress. Yet, DevOps implementations have human and organizational implications.
How best can firms adopting DevOps seamlessly integrate operations teams and activities into Agile models? This article discusses a framework to help organize operations in Agile environments.
Operational Agility Calls for DevOps
Those of us familiar with Agile and continuous delivery models will know that true agility is ‘end-to-end’ agility—that is, not just development agility but also ‘operational agility.’ You need to be able to code and re-code quickly, as well as deploy and re-deploy code just as quickly. In fact, the entire delivery machinery must wax and wane together, and beat to a common pulse.
That’s where DevOps comes in.
DevOps is about bringing together developers and operations. In fact, it requires all stakeholders (e.g. testers, user assistance, and analysts) to work together as a team.
Modern ‘software lifecycle management’ tools like IBM Collaborative Lifecycle Management facilitate this interaction by globally configuring software components, integrating development, test, and operations plans, and linking operations-controlled artifacts, such as configurations settings, to source code and other development artifacts.
Tools and technologies like Docker, Containers, and IBM UrbanCode Deploy have automated complex tasks like environment provisioning, configuration, deployment, and decommissioning. With these tools, routine but complex operations tasks are within reach of conventional developers.
While these tools and technologies have helped facilitate implementation of DevOps, a successful and frictionless implementation requires organizational support. It requires an organizational structure that helps create the right DevOps mindset and culture.
Organization Structure Impacts DevOps Mindsets and Culture
A traditional operations setup (still adopted by many organizations) has a common operations pool. The diagram depicts how this common pool works in an Agile development environment:
As we know, ‘sprints’ are core to any Agile development environment (more on this later). A typical ‘sprint team’ largely comprises of developers, who focus on writing the code. Slightly more evolved Agile organizations could also have testers in the sprint teams. Sprint teams work, or sprint, towards delivery goals, which are usually a few days or weeks away. They are fairly autonomous and democratic in the manner in which they schedule their daily activities.
Operations staff, who set up the hardware, and development and test environments largely remain on call and are shared between sprint teams. Their availability to sprint teams is not dependent on the dynamically varying tempo of a sprint, but on priorities set independently by departmental operations managers. Because they do not have an insider’s perspective of a sprint, they are often caught between ‘crisis’ calls that they don’t have any way to pre-validate.
Besides not having an insider’s view of sprints, operations staff are also bereft of the camaraderie and sense of loyalty that sprint team members feel after days and even weeks of sharing the same issues and working together on the same problems. Because of their ‘outsider’ and ‘temporary’ tag, operations staff do not usually feel the same intense sense of ownership that sprint teams feel for the project or product.
A developer who spends weeks and even months on a user interface is fully committed to its success and would not mind redoing portions of it, if asked. On the contrary, operations personnel temporarily deputed to a sprint is unlikely to be as charitable and could consider the time and effort spent on deploying the previous piece of code as wasted.
For instance, operations teams are often measured by ticket-resolution time (the lesser the better). They are therefore motivated by jobs that have a well-defined start and finish. Those of us who have worked in Agile environments know that sprint tasks are often ‘fuzzily scheduled’. This lack of ‘precision’ in sprint schedules is often the source of friction between sprint teams and visiting operations personnel.
This weak sense of ownership plus the tensions created by multiple teams contending for common resources are bottlenecks to quick and Agile delivery. The ‘wait states’ that you see in the above diagram between successive sprints are the effects of these bottlenecks.
As the factors responsible for these wait states are human and organizational, the interventions that are required to reduce these wait states must also be human and organizational.
It is for this reason that we need to examine the organizational aspects of DevOps.
A Quick Word About SAFe
However, before we proceed further, we need to understand the general structure of a scalable Agile delivery model. A quick recap about the Scaled Agile Framework (SAFe), a popular set of guidelines for implementing Agile in large projects, would therefore be in order. We will then attempt to superimpose our organizational framework for DevOps on SAFe.
Fundamental to SAFe (as to any Agile framework) is the sprint team, a set of people working on small pieces of code that are capable of being delivered in around two weeks. Since most products comprise of multiple components, there could be more than one piece of code being developed simultaneously. Multiple sprint teams, therefore, exist (working on the same product), which are collectively called ‘programs’. A program team may have analysts, operations staff, and user experience personnel besides developers and testers. A large firm (or project), which is what SAFe is designed for, could have multiple product development efforts going on simultaneously. Such a firm might want to group a set of products into a ‘portfolio’. The team that handles the entire set of products is called a portfolio team. Besides, members of the constituent program teams, a portfolio team could also have senior managers and representatives of business. SAFe 4.0, which is the latest version of the framework, introduces a fourth layer called a ‘value stream’ between the program and portfolio layers, which as the name suggests is a grouping of programs that add similar value. Details about SAFe 4.0 can be found on the SAFe portal.
Sprints, Programs, and Higher Levels – a Virtual Organization
SAFe does not recommend an organizational model for implementing SAFe but gives implementers the flexibility to adopt any model they think fit. Whatever the model chosen, a convenient way to encapsulate its essential organizational properties is by the multi-layer pie shown below.
The pie represents a multi-layer virtual organization. Developers and testers (in the outer layer) are spread out into separate sprint teams while program and portfolio level teams (in the inner layers) have common personnel whose services are used by multiple sprint teams, or who oversee the functioning of multiple sprint teams.
Activities in the three layers (four in SAFe 4.0) are supposed to be orchestrated to a common ‘cadence’ by what SAFe calls Agile Release Trains.
How do we introduce operations activities into this cadence? Where should they be performed–sprint, program, or portfolio (or value stream)? SAFe alludes to what it calls a DevOps role. In the second part to this series, we will examine the organizational aspects of this role in greater detail.