How to Continuously Involve Ops Stuff in the Agile Development Cycle (Part #1)

There are many opportunities and areas to be involved in the world of Agile development processes – from the various Agile rituals, through actually helping developers, during testing and even to help ourselves occasionally. All of these require attention and unique mental fine-tuning, both of which I will review in this article. I'll try to step into the (big) shoes of the Ops people and to discuss, from their perspective, the areas in which we join hands, on the practical level, with R&D or Dev and truly traverse into the everyday life of the Agile software development process. For the sake of simplicity, and without offense to Agile tools such as Kanban and others, in this article I will focus more on Scrum and deliberately deal with the development process of this method, simply because it is currently the most entrenched and best known practice. For the purposes of this article I will distinguish between Dev and Ops as if they are different teams, but this is done for a ‘good cause’ – in order to emphasize the connections between them. So let's see how they both go together in practical terms.

A brief moment about myself and why the people in this story are so important for me: I have been an Agile coach since around 2008, I have previously managed large QA groups and during that period I gained “a bit” of perspective into processes, and 20 years ago I was a social worker...  and during that period I gained “a bit” of perspective into people and creating change through people. Without going into too much detail, I see people and processes as connected. There is something in the everyday combination of people in processes and mindsets which I believe bears the utmost importance when one sets out to implement a process. Without this combination it will not work. If you ignore the people in the process, you’re in for a nasty fall.

So let's see how the Agile process between Dev and Ops works.

We’ll take a quick look at Agile and connect it DevOps, and then dive right into the development process. Over the past decade or so we have gradually implemented Agile in development teams. We taught them to work in small portions, to be feedback-oriented, to talk to each other a lot and often. We taught them to work together. We taught them to use tools that improve the quality, speed and responsiveness of their work. In effect we have accelerated the development process. Delivery is faster, better and more responsive. I saw it work during my years in the industry, and even if it was not implemented exactly as we wanted in every instance, it always led to acceleration – even if not by 400%, even if only by 20%, it already had a noticeable impact.

But we got stuck. Why did we get stuck? Because we did not come full circle. We made development run very fast while Ops, which is our production, remained in place. For them things were piling up, not only tasks but also mistakes and perhaps even emotions.

If we look at traditional development processes, including those in which Scrum was integrated, we will recall that we had two huge obstacles during development. One was when we wanted to reach integration points. Code consolidation points were heavy. A nightmare of connection, bugs and fixes. The second point was deployment – the actual transfer to the “customer”. When the developers raised a toast in celebration of a new version’s release, it was the Ops people’s sign that all plans are off, "because we're going to spend days and nights in the office to get a new version up".

To move forward faster and better and to avoid this whole mess, we began to include more and more integration and Ops tasks in this process. We started to combine the two, both in the procedural and practical level, and also in terms of the tools and internal approach to these issues. Thus, in 2009, the concept of DevOps was born. In short, DevOps is a set of tools that and a culture that helps organizations move faster and more smoothly from the point of demand to the point of end-customers.

Agile and DevOps are complementary. In a world that moves so fast, where we need to quickly send things to production, without compromising on quality, quickly respond and quickly change, the connection between a demand being made and its production phase (or reiteration as feedback) should be very rapid. We must remove barriers between the Dev organization, which always wants to change things, and the Ops whose interest is to remain stable at all times. One way to move fast and eliminate siloes is to place tools in various places. For example, to test earlier, to integrate more frequently and earlier, to monitor at all sorts of checkpoints and not just at the end, to create environments that communicate faster with changes and are able to reflect what is happening, to address customer environments and customer data at earlier stages and more.

But tools alone are not enough. To do it well one should also know his production line, where to place the tools. After all, no two organizations are identical, neither in the tools nor the process nor in how and where they place these tools. Where is the best place to invest at the moment? Is there an urgent need to create a log, additional automation infrastructure or something else? To answer these questions you need the people who know exactly what is happening, on the ground, and who are involved all throughout the way. This is crucial if you want to know what is happening and what needs to be done in order to actually, rather than merely theoretically, generate value; this cannot be done from above (by higher management) and disconnected from the fieldwork. We need these people to be involved, each in his or her respective field, and to know to pick up the problems and solutions at any time or place (and not at the end, slowly, after meetings, or during the post-mortem examination of a dead [or still living]  version, or other similarly sluggish methods). Reacting to events as they occur and as soon as possible, rather than later. My speed of delivery relies exactly on this - people and their involvement. This process is fueled not by the tools, but by the constant influx of actions that fuel and improve the process. The combination of mindset (which I will not discuss here) and proper involvement in the relevant parts of the process will create the ability to really move fast.

Following the Agile route, its everyday life and various practices and rituals, at the right places, feeds all these small parts of delivery into the correct tools, which in turn produce the adequate response at all times, and change it as needed. Feeding authentic integrative reality that truly fuels this production line. This is not about bandages, but truly and intentionally adopting an approach that aims to remove barriers, to keep quality high, to move quickly and respond quickly. This will happen only when we are constantly involved.

Let's look at the Agile development process - again focusing on Scrum from the Ops perspective. Let's review the places where we intervene: in which points in the process do we intervene? How do we help development? How do we help QA? And what about ourselves, Ops? How do we help ourselves? And despite our previous statement, we’ll also say a few words about the mindset.

Next in pat #2 we will review the actual areas of involvement : the team , the standup, the planning and more...