Agile and Infrastructure

Recently, I had a rather interesting discussion with some of my clients over Slack: Agile processes applied to Infrastructure. At the beginning, we did not reach a common ground, but we quickly realized that the problem was not our approaches, but our vocabulary. Agile? Infrastructure? Once we agreed on these terms, the discussion took on a completely different form. Here is a short summary.

Agile ?

Often, when we talk about Agile, we talk about agility. It is assumed that it is about being flexible in our actions and reactions. It is mainly a mix between a mindset, a culture, an approach and above all a paradigm.

Defined in the Agile Manifesto, this approach to project management is the opposite of traditional approaches such as the V Cycle or cascades. The short version is that these traditional methods lead irremediably to a tunnel effect, which can have disastrous effects on both the project and the client relationship. Conversely, the Agile approach proposes to reduce this tunnel effect as much as possible in order to allow better transparency, through an iterative and incremental process.

So the key elements are there: transparency and iteration. From this, many other concepts will derive, related to the different methods but also to the contexts of applications. Many sites and books will describe them much better than a few lines on this blog.

Infrastructure ?

An infrastructure is a set of interconnected elements that provide a framework to support the entire structure. As such, it is not just the network or system, but a collection of these elements and many more, to be considered in context. In the case of a team, we will have to talk about, for example, NetOps, DevOps, SRE, Architects, Infrastructure Engineers, … All working on the same subject, with different angles, and therefore different needs and means: their daily tasks, depending on their position and the context, will range from pure Run, to R&D applied to infrastructure.

And so ?

Okay, so let’s go back to our original discussion. Why talk about Agile and Infrastructure? We had different points of view together (I arrived during the discussion) and the central point was about the ability of “Infrastructure” teams to work in an Agile way.

One of the participants, who manages an operational team, therefore pure Run, did not see how Agile could be applied to the Run. The other, an R&D manager, was suffering from blockages from an Infrastructure Engineer who had joined his team after years of working on Run. The last one was managing a team that did both R&D and Run, and especially managing a rather junior DevOps that he was happy to model as he went along.

Depending on the interlocutor, it was more or less possible to apply the Agile approach to Infrastructure and that if someone couldn’t do it, it was simply their fault. Rather abrupt.

In fact, we must remember that in the professional world, it is our experience that models us. So you have to look at the current tasks to be performed but also at the past tasks of the people who will be working there. A person who has never worked in project mode will potentially find it more difficult to integrate into a project mode than someone who has been in it since the beginning of his or her career. And in Infrastructure, there are a lot of opportunities to work in project mode, but also a lot not to.

Making the infrastructure agile

So the real point is there: apply the Agile approach only when necessary, on the project, with people who have an approach to the subjects compatible with the two key elements.

Indeed, we could try to apply Agile methods to the Run, but this will not concern the core business rather than more related topics (documentation, debug tests, …). In the same way, a person whose experience has taught him how to look directly for the right final solution, even though he will spend a long and unmeasured amount of time on it, will not easily be able to work in incremental iterations, more time-limited.

This is the point that I sometimes have fun stygmatizing with my clients to trigger reflection. I then caricature by talking about the American approach of a startup, ready to do anything and question itself the next day with a complete turnaround; versus the French approach, much more posed, and which will only deliver once perfection is reached.

So it comes down to the fact that we can work in project mode, according to the Agile approach, with teams that are used to working iteratively and incrementally. The basics. In reality, therefore, we can come up against other problems:

• a non-compatible mindset
• a lack of method or disagreement on method
• an inability to sequence work to make it iterative and incremental

On the first two points, an Agile coach is the best way to find an answer. Indeed, the Agile coach will make sure that both the mindset of the team, but also the coaching structure allows this work in Agile. In the same way, he will often overflow on the means made available. He will then continue the work on the method, because in the Agile approach, each implementation comes with its own method and its own framework that will serve as a basis for its integration. The Agile coach will accompany you on the choice of the right approach and the right method, which will help to remove barriers.

On the difficulty of sequencing the work on the part of one of your collaborators, the work will be more on your side as a mentor of your team to accompany him or her. Although this long work requires an enormous capacity for hindsight on the part of the collaborator, who must change his way of doing things, it is your responsibility to place yourself as a benevolent coach and to find the right words to get your collaborator to put himself in the best possible frame of mind. There is always a risk of complete blockage, because it is still human, but it is up to you to persist and remain … agile. Act, Fail/Success, Iterate.

Why is it interesting to work with the Agile approach on Infrastructure?

• Deploy faster more often, which requires standardizing your work (this is one of the bases of the DevOps mentality)
• Gain in flexibility: whereas in the past, the infrastructure was relatively fixed in the long term, here the actions are only valid for a short period (before being called into question).
• Continuous feedback: the basis of the Agile approach, feedback from users/customers/employees comes in all the time, during the course of the project.
• Continuous improvement: because of the above points, you have gained the opportunity to improve continuously, with each new iteration.

In the end, you will reduce the risk of having to call into question the entire infrastructure put in place, and by extension, the major and very costly revamps that we are familiar with.

And you, do you think it is possible to work on Infrastructure topics using an Agile approach? Feel free to contact me to discuss it.