The AgilePath catalog: EXPLORE the AgilePath and learn about agile by @GrowingAgile

AgilePath.me is designed to help you understand what there is to learn in the world of agile, and find the right path for you. We believe everyone who invests in their own agile learning and then uses that to influence, inspire and teach others is an agile coach. Join us in changing the world! If you already have a good idea of what you’d like to learn you can explore the topics on your own from our explore page, or using the search.

Retrospective Online Facilitation Techniques for Distributed Teams

The Business Agility Factor

Business Agility is not just the ability to change. It is a cultivated capability that enables an organization to respond in a timely, effective, and sustainable way when changing circumstances require it. it is the ability to adapt rapidly and cost efficiently in response to changes in the business environment. Every enterprise wants to have this ability, don’t they? To become agile a lot of things have to become more flexible. This doesn’t only ask for changes in the structure, in the IT or in behavior of an enterprise itself. it's a lot more than that.

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).

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...