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

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.

let's ask the obvious first question on the way to involvement:

Are Ops part of the Scrum team or not?

We have made the testers part of the team. After all, the whole idea behind Scrum is independently organized multidisciplinary teams. So what will it be? Ops in the team or outside of it?

Are they only part of the medical staff that performs surgery on its patient? If, for example, we were to compare them to a football team, do they travel to competitions? Are they that necessary? Are they part of getting things done, end to end, or only a side addition?

Of course they are an important part! Of course they are part of getting things done.

But unsurprisingly, the answer to the particular question of whether they are part of the Scrum or not is that it depends. Some organizations just want to get started and establish this whole concept of DevOps. This requires specific attention and skills which you may want to separate from the Scrum team. There is a lot of work to be done even without being connected. In larger organizations as well, we might find groups that have a lot of other things to do, not just in the context of what is currently happening in development. But even in these cases the staff should work in ways that enable speed, quality, working in small portions and preliminary feedback; and in general to be connected to what is happening outside and which should affect its own work.

There are actually large organizations in which the Ops staff are in the team and are full partners in every respect, including backlog and everything else, for the simple reason that there are frequent transfers and many siloes, and the most effective way to handle these issues is to create continuous cooperation around issues that constantly occupy the team. Many environments, changes, adjustments, tests, etc.

But between you and me, it doesn’t really matter if Ops are in the Scrum team or out of it, it's all in the mind. In their mind they must be part of the team. Their thinking should be geared towards this, "it's mine", "I'm part of this team", "what happens there is important for me", "I am part of this activity," and hence my attention is very much directed to everything that happens in this team’s area.

What about planning activities? Building the backlog? Do Ops participate? Of course they do.

If only for the reason that everything goes to Ops eventually. When building the backlog it is important that Ops work closely with the PO in order to understand the backlog, to see what we need to prepare for, what we need to produce, what we should make and enable, whether we should prepare certain customer environments, is specific production data required, are there performance or security considerations, standards, tools? What’s the situation in the client environments? Or anything else that should be taken into account. Backlog is not just what the customer expects to see, it is also a multitude of additional considerations which will enable everything to come together afterwards.

And please: involvement is not just in documents, because a document does not convey the gist of the matter and does not always clarify the degree to which its various elements and their importance are internalized. There are certain questions which only dialogue can inspire. So as Ops, go and talk to the relevant people. The grooming process makes it possible and easy.

What about release planning, are Ops involved? Of course they are.

We can and should know what is planned to come first and what later. We must understand that things will come in small portions rather than a big bang and this affects the way we will work, what we’ll produce and what we’ll do. We can also control what comes in and how by our very presence there, by giving and receiving feedback and being a full partner in the decision-making process.

DOD: Think about the end from the start!

In general, when it comes to planning, we should adopt an approach that considers the end from the start. How will it look at the end? In every level. From the backlog, through planning the release and down to the smallest unit in development. Even at the level of coding standards, scripts that will be used, necessary documentation, the way code is released and more. This preventive aspect is one of the most crucial components needed to prevent breakdowns and unnecessary costs at the end.

This needs to be the Ops mindset.

It is important to understand that every member of an Agile organization wears a certain hat in our everyday life, some wear the QA hat and are interested in quality, pushing it forward... this does not mean that others are not doing so as well, but it does mean that this is what testers are really, truly interested in, what they live and die for. We as Ops, in one of the hats we wear, push forward the importance of considering the end from the start.

What about execution – the team’s planning meetings, the daily Scrum meeting? As before, of course Ops are there! (I guess you get the picture by now)

First of all, we join the team’s planning meeting, this is where we connect to the actual implementation of all those matters we previously deemed necessary. It is important to understand how they, the team, interpret the requirements in the backlog for themselves and how they translate it into action items. There will always be gaps when it comes to the way a developer actually thinks about the code he or she needs to write. Changes will appear there as well, and for good reason.

When it comes to the daily Scrum meeting, of course we as Ops should be there. Let's go ahead and agree on something here: there will probably be gaps between planning and execution. I sit with developer teams and every day there are questions, there are debates, discussions, the thought that things will not change is a terrible illusion, because they absolutely will. Join the team’s daily meeting, hear what they have to say. Listen to their feedback and see if there are improvements you can suggest. I promise you there will be. 

Our listening mode is not only meant to ensure that nothing has broken along the way or to see if we need to somehow change our plans. They might have certain needs that have suddenly arisen which we can accommodate, respond in a way that enables them to move forward fast... After all, we wear a type of hat that is mindful of these matters.

What about SOS [Scrum of Scrums]? – Of course we’re there, as in all previous instances.

This is THE place to see that everything is coming together. Bear in mind that it is highly likely for gaps between planning and execution to exist. When we move forward in working increments it is necessary to see that everything works together. Clearly these connections are a very dangerous area. For me they are a major obstacle. To see what needs to be added, monitor, test and ensure that all the elements actually work seamlessly together. In large organizations this is crucial. Don’t compromise on this. Insist it happens and insist on being there.

What about the sprint demo? Again, of course you are there! You are always there!

The sprint demo is THE place to see what it looks like in your own eyes. We planned, we executed, now we need to see. It is another opportunity to give and receive feedback. The demo is a live exercise of our readiness for production. As Ops it is our responsibility to ask questions, hear what others are asking, and to be aware of the changes that happened following execution and their implications.

More generally, the demo is also an opportunity to be proud, to present something that works. After all, we also had tasks of considerable value – everything we do as OPS has value for someone. Show it to the world!

Do not miss the demo!

Make sure the demo is public and not confined to the team. This small activity has tremendous value that affects the team’s commitment to reach a state of presenting something that really works.

And what about the sprint Retrospective?

Well, this time the answer is different. And the answer is ‘not always’. If you are part of the development team, then you participate in the Retrospective. The Retrospective is for the team. If you are not, make sure to have your own Retrospective. 

After all, you did, you experienced, you heard, you developed, you participated – you must have discovered something that needs to keep being done, or some other thing that you should stop or start doing. 

Demand a group Retrospective. If there was an SOS, you could also demand that a Retrospective be held together with the entire group which participated in the process. After all, this group worked together as a multidisciplinary monitoring team, one that thought, connected, weighed, encountered setbacks, solved, failed and eventually came through. And how did this happen? That is discussed in the Retrospective. It is best to do this after every Sprint in larger organizations or complex projects but surely more than once every version or release. After all, in a release it all comes down to Ops in the end, doesn’t it?!

Visualization.

Let's put this on the table, visualization is a tremendous force for getting things done. When I see something, I am far more likely to take it into account and get it done. Visualization has the power to lead behavioral change. Just think of all the speedometers popping up at the side of the road, indicating the driver’s speed versus what it should be. This visibility alone is enough to get people to drive slower. Visualization leads the viewer to the desired outcome (e.g. to drive slower).

So what’s Ops got to do with it? A lot. I ask that we create visualization, think visualization, and exhibit it wherever we may go. Use this tool! We will take care to generate reports that present the state we want to reach, take care to ask questions and to extract information that is needed and then visualize it. We will understand which reports are missing: logs? A particular metric that suggests a certain measure should be lower than another? Something else? Anything that leads to the desired behavior.

It is also very important to reflect the state of the customers, actively, to measure our clients. To learn what customers are experiencing, to connect developers with these occurrences, to study the customer, understand where they stand. Both for development and for QA. We are connected to production, give feedback and connect others. Put the customer in their face, after all they are lost in their own world, make the client part of it. It will only be for the better.

We are advocates for visibility and it is our duty to think about how to push it into the others’ faces and how to constantly improve it. Update it and adjust it to meet the outcomes you ultimately want for yourself (which are probably quality and stability).

DevOps visibility will be visible in all spaces, it will be clear, concise and easily digestible.

Visibility = feedback. Which feedback can we give to help development?

Because we are involved in almost every aspect of the process it is easier for us to identify what should be made visible and how. We can create visibility into cycle time (how long it takes for something to pass from demand to production, for example), or red builds (the ability to identify the point where you need to pause and stop adding additional faulty code to code which was faulty in the first place), the zero-bugs approach (visibility that allows to push for zero defects), the health of a deployment, infrastructure data, whether this represents the customer’s experience, and much more.

And how can we help development? In many ways.

By virtue of our involvement we can easily understand what the developers need.

Where are the best spots to add more fuel to the process, where visibility can be improved, where I can identify bottlenecks and how to eliminate unnecessary waste, and of course how we can push more and more for a smooth transition from code to production. If I am already involved is easy for me to do this, but only if I realize that it is my responsibility to become involved in the process, if my mindset is that it is my responsibility to ask myself these questions at all times: "How can I make their lives simpler, more effective, quicker and of higher quality?" "How can I take the feedback I hear and transform it into action and change for the better?"

And what about the testers? How do I help them?

Well, here the story is a bit more complicated.

The testers’ world is completely different from the practices we met in the traditional world.

From a testing group that sat at the end of the process, with late feedback, relatively outside of development, to testing that is present in every single step of coding.

The tests are the glue for my entire ability to move forward fast. They're everywhere now: From unit, to ‘accept’, regression, performance... all the time, and in each one. Not only testers develop automation. Everything changes for them: the necessary skills are more inclined towards automation, their involvement is an internal part of the process, test planning which is done constantly and changes, the tools. Everything.

From the ones holding back production they have become enablers – their role is now to move as much of our code to production as possible, rather than serve as gatekeeper. Their role is also to stand by production and find ways for as much high-quality code as possible to be produced, fast. To do this they must be more involved in everything that happens throughout the course of development.

When it comes to Ops they have several requirements – first, they will need changes, and most likely frequently, to infrastructure, environments; they need feedback in the form of monitoring, access to production in order to test something, or any other monitoring or frequent change they stumble upon.

It is also very important to reflect what is happening with the customer in the field, to receive their feedback which we will also verify, for all of us to see what is happening, actively, to measure our customers. The Ops are connected to production, deliver feedback and connect the others. This includes connecting the customers’ requirements to the constantly updated production line.

On the other hand we should understand that these testers are our best friends, they aim for quality and for this whole thing to work seamlessly later, during production... They are a tremendous source of feedback for us, connecting them to various stages of production is a gift.

And what about us? How do we help ourselves?

I think that first of all we must be prepared. This means we need to understand that there will be issues coming in from the field all the time and they will affect the way we work or have worked so far. From a group that enters the process at its end to one that also deals with prevention, feedback and understanding the work that took place before us.

We should understand that our entire day-to-day life is different. Meetings and other references are different, we are not alone and our day-to-day life is enriched by many different types of feedback from the field in which we are actively involved. It is an active and involved group, not something detached residing above and releasing versions or customer releases. At the same time, we also have our jobs to do.

We should work as a Scrum team – since this presents huge advantages in terms of our ability to manage ourselves, to learn from what we're doing, to create transparency, visibility and daily synchronization in light of feedback from the field and when facing the planned tasks ahead. Scrum is a tremendous tool in the context of teamwork and feedback.

Furthermore, we should also learn to manage our tasks and our flow. Surprises (which are good and desirable) will come in the form of feedback from the field which we will have to deal with instead of other queued tasks. In this case you can combine Kanban - but this will be the subject for another article.

Before I summarize, I would like to refer to a “small” matter known as mindset... and while it is true that there is an entire article and lecture on this, nonetheless there is one point that I believe is important to convey.

Collaboration – an approach we have to adopt.

What does this mean? It means that as Ops, I want us to talk a lot, really talk, face to face, to meet, to feel that we are in this together. Without this, it does not matter which tools we use, things will not really run as smoothly as they could and we will make costly and unnecessary mistakes.

But cooperation must also come from managers and with the full support of the company we work in. There must be an understanding that proper respect is given to the daily Scrum meetings, Retrospectives and Planning, to the time people need to devote to hold them, to the change in the day-to-day life of Ops staff which must be involved. In an Agile world there is movement, there is conversation, there are meetings.

I hold the executives responsible, not only in the messages they send, but also in their respect and behavior including their levels of sensitivity. To berate someone who needs help for his interference, or accuse him of coming without real need or to hint that he is always clueless, is not cooperation. Instead, I would expect that we help, we understand what can be done next time so it won’t happen again and to improve.

I would also suggest we consider the correct environmental infrastructure that will enable collaboration. If you think about it then it is really a self-reinforcing circle, after all, if we are really involved in the day-to-day of development, we can easily understand what they are working on today, since we heard it in the daily Scrum meeting, they are working on it anyway and so are we, it is a relatively small matter you can ask about and receive an immediate response because there is not much of a distance between us and them in regards to the goals or interests at stake. But if we will create this distance, questions become an annoyance and then managers will come in with rules for separation, escalation, discussion meetings, emotions and... the process gets stuck. Isn’t it simpler to just get closer?!

So what are our tips for ourselves, as Ops?

1. Be part of the team.

2. Be present throughout the planning process.

3. Be part of the execution and understand that there is a gap between planning and execution - always. Take care to receive a steady flow of preliminary feedback on execution – for example, during the daily Scrum meeting.

4. Do not skip the SOS.

5. Do not skip the demo and take care to present something ourselves – in addition to pride, it is also live training for what we will eventually receive and enables us to prepare.

6. Hold your own Retrospective.

7. Insist on a production line Retrospective.

8. Visibility is an extremely powerful tool! - Push for it, feed it, update it and adjust it to the outcome you ultimately want for yourself (which is probably quality and stability).

9. The testers – your best friends – need a lot from you and provide valuable information if you know how to work with them.

10. Work as a Scrum team (create your own backlog and feedback mechanisms).

11. Manage your flow wisely.

12. And if necessary, make sure you receive expert help (from a coach).