Talk: Agile, DevOps and Compliance by Guy Herbert, Atlassian

Lauri Palokangas (00:04):

Welcome to DevOps Sauna. My name is Lauri and I am the Chief Marketing Officer of Eficode.

Lauri Palokangas (00:12):

Not too long ago, we held a hugely popular two-day DevOps 2020 event. We had awesome speakers from around the world, telling stories about DevOps tools and culture for over a thousand people online. Since then, we have made these recordings available at the Eficode website, and due to the popularity of these speeches, we have now made them also available in our podcast.

Lauri Palokangas (00:36):

You can find the links to the video recording and to the materials referred in the speeches in the show notes. We're also keen to feature topics that you find interesting in the area of DevOps in this podcast. Do let us hear about you in our Twitter, Facebook, or LinkedIn pages.

Lauri Palokangas (00:53):

In this episode, we listen to Guy Herbert from Atlassian. Guy is a risk futurist, and will lead participants through the Agile and DevOps development processes, and the interactions with compliance during that process. He also talks how they can use technology and process to improve their organization's development speed, as well as hitting their compliance objectives.

Lauri Palokangas (01:16):

Guy's topic of the speech is Agile DevOps and Compliance. Let's go.

Guy Herbert  (01:22):

Thank you for the introduction.

Guy Herbert  (01:24):

The world is not changing. The world is changing, but that's not new. What is new is the rate and breadth of change. Hey, I was expecting to fly to Helsinki for this presentation. Instead, here I am in my home office in Sydney, Australia with a webcam and a coffee, being very grateful for convenient time zones.

Guy Herbert  (01:44):

Customer expectations and regulatory requirements are changing all the time. Our challenge is to meet that change in a way that makes our organization stronger. As a risk and compliance person, which I feel is a natural fit because I worry all the time and I trust no one, this is hard. It is easier to say no than to suggest a better way. But that does not help you, and actually increases your risk in the long run.

Guy Herbert  (02:10):

Some of the things that I'll talk about today are not going to be new to you, but the way that you think about them will change. I'm going to presume that most of you don't work in sales. Me neither. But I had to sell these ideas to our auditors, and if my experience has anything to go by, you'll have to sell them to your risk and compliance teams and your auditors. Let's go on a journey of discovery.

Guy Herbert  (02:40):

I joined Atlassian almost seven years ago. We had no compliance obligations at the time. I described it as a pretty sweet gig for a compliance person, but the person who hired me knew that this would change. He told me three things. If the controls I was going to suggest would slow us down, I needed to find a new job. Atlassian is a [do-ocracy 00:03:02]. There's no point in telling people what to do, I actually had to get in there and do it with them. And thirdly, good luck with that.

Guy Herbert  (03:15):

Now, I used to work for an investment bank, and prior to that, a large retail bank, managing a team of risk professionals. So I know the way that controls have traditionally been designed. And I knew that this was not going to work for our environment. To give you an idea of our rate of change. We push a release to our regulated production systems every hour. I said, we had no compliance obligations. This obviously changed. I know that you'll have something like this, or possibly worse, depending on the industry you're in.

Guy Herbert  (03:49):

Interestingly, our cloud products, so JIRA, Confluence in the cloud, Bitbucket Cloud, are subject to SOC 2 and ISO 27001 compliance obligations. We use 27001 as a proxy for GDPR. We are one of the few organizations that actually have their products under SOC's controls. Most of the other cloud providers don't really do that. Their revenue streams are through systems that are not part of their product set that they sell to the public.

Guy Herbert  (04:23):

Of course, there's more obligations coming down the pipeline all the time, both for you and for us. At the moment, we're looking at FedRAMP and HIPAA, but there's always something coming down the pipe for us.

Guy Herbert  (04:35):

People often ask me what makes Atlassian successful. And for me, it really comes down to our values. And these aren't something that we just sort of like, a nice poster on the wall. These are values that we really live every day. They came about by a group of people within the organization going, "All right, if we wanted to recreate Atlassian on Mars, who are the people we'd take? What values did they espouse?" Atlassian is a great place to work, there's no doubt about that, but these are qualities that pretty much anybody can replicate. As I say, don't kid yourself that somewhere is perfect. We have our days when things don't go well. We have, some of the times, we don't really live the values all the time, but we really try. It's these values allow me to come and talk to you, or sit in my home office and talk to you. It's also one of the reasons why I really feel is that the controls that we have in place work to enable our compliance environment.

Guy Herbert  (05:39):

With that background, I'd like you to think about three things: You're trying to move fast, and you need the risk and compliance people to help make compliance easy to understand and to do. You need to know what the guide rails are, what you can and cannot change. The risk people need to know what you're doing. The third thing is: You need to be able to deliver fast without having to insert a whole bunch of compliance steps into your change process that really slows you down.

Guy Herbert  (06:10):

With all this going on in our environment, in our organizations, we need to be adaptable. We need Agility. I think this is different. There's oftentimes I talk to people about Agile and they automatically switch into what I call Agile compliance, which is, we do retros, we do stand ups, we have epics, and sprints, and all those sort of things, but they're not living the concept of Agility. For me that is, we need frequent, small changes, delivered fast to seed feedback and course correct. Why? You want to know if the change is working and if you headed in the right direction.

Guy Herbert  (06:53):

Now, the great part about this from, my perspective, is that it decreases the risk associated with change. Both the risk in change and the risk of change. There is so much risk associated with large, infrequent change. And being able to do these small changes really helps, because it also helps you build the change muscle, you practice making change, and so it becomes easier to do.

Guy Herbert  (07:20):

The controls that we implement need to work at this pace of change. If I tried to roll out traditional change control structures, this would have really slowed us down and impacted on our ability to deliver out to our customers. I had to find a better way.

Guy Herbert  (07:39):

The teams that I support, I support about five teams within Atlassian, because I'm not the only risk and compliance person in the organization, thank goodness, they're doing so many things. They're delivering service to their customers, supporting internal teams, making sure that every customer is delighted every day. Okay, maybe a step too far, but that's what they're aiming for. But you get the idea. Risk and compliance is not the thing they wake up wanting to deliver. As a risk and compliance person, I need to make it easy for them to meet our obligations and still get their work done. As an aside, I do wake up wanting to deliver risk and compliance. Well, that's all well and good, but exactly how does Atlassian make it easy for teams to meet multiple compliance obligations and still get work done?

Guy Herbert  (08:28):

The risk and compliance team at Atlassian starts with our compliance obligations. So, as I said, these were SOCs, was one of the ones we started with, but then there's others. We then map these to a set of control objectives. We started with SOCs and did that mapping, and this is done really within the risk and compliance team first. We then take these control objectives out to the teams, and we work with them to understand how they meet those control objectives.

Guy Herbert  (08:57):

Now, this was actually one of the fun parts of my jobs because I came from the risk and compliance background and I really understood the compliance obligations, the control objectives. I'd go out and I'd start these interesting conversation. So this is me: "What controls do you have in place for change management?" And the people I'm talking to, they're like, "Huh?" I go, "All right. I'm speaking risk and compliance again. All right, how do you ensure that you ship quality code to customers?" Then people go, "Oh, that's easy. We do peer review and we do build testing." These then form the set of control activities that the team perform. We do this for all of the control objectives, and we go through these one by one with the teams. And these are then owned by the team. So these control activities that the team is performing, they are owned by the teams. They're not owned by risk and compliance.

Guy Herbert  (09:55):

Now the control objective in the middle, yes that's the benefits of going out and doing this with the teams is twofold. We know that what they're doing is going to meet the objective. We assess the design of the control when we're doing that. But we also get to take the best processes from one space to another. Some teams, we'd go and talk to them, and they had really great processes. Then when we go to the next team and they'd be like, "We got nothing." I'd be like, "Okay well, how about we talk to this team over here? They've got some good ideas," or, "Actually let's work it out together." Being able to bring the right practice, and this isn't about best practice, it's the right practice, to the team is something that they felt really added value.

Guy Herbert  (10:42):

Now, we did this for our first compliance obligation, SOCs. Then we had to do it for SOC 2. We did the mapping first, compliance obligation to control objective. What we realized was that there was about an 80% overlap. We did not have to create any new control objectives for that 80% that was already done. This minimized the impact on the teams, as we only had to ask them for information on the new 20% control objectives. That really lightened the load on people when they had to do SOC 2.

Guy Herbert  (11:17):

Now, there were some teams that weren't in-scope for SOCs, but we're now in scope for SOC two. They went through all of the control objectives. But because we'd already done this work with a lot of the other teams, there was a set of controls that they could ride off. So it made their life a lot easier. Now, when we did ISO 27001, was even less. It was only about 10% additional on top of the control objectives that we were already running.

Guy Herbert  (11:48):

What it meant was that the teams could concentrate on the control objectives that they had to perform. We effectively created an obstruction layer between the controls that the teams had to perform and the compliance obligations. When the team changes, they can reassign the control activities to the people that now do that. Your team does not need to know which compliance obligation your control activity is fulfilling. But if you want to find out, you can. You can go on to look at it and trace it through. I think being able to give people that visibility and that traceability is really important, because otherwise you disempower the people out in the teams. Now, people will say, "Okay, what do you do this with?" All right, we use JIRA, so we put all this in JIRA. And because it's in JIRA for us, everybody can see all of it all the time. It makes life really easy.

Guy Herbert  (12:47):

What does this look like in our world? We have a great set of data for all our compliance management. For example, a Control Activity Library. This is a big library of the control activities that the teams are performing. We can then trace these back to the compliance obligations that they support. It really helps people, because when we're meeting with them, we discuss a common language that we're all using. These are written in the words of the teams that are performing the control.

Guy Herbert  (13:17):

Now, remember when I said, I trust no one. We want to know that we're going to meet our compliance obligations. We test to make sure that the control activities are being performed. We record all of the testing results and the findings in the same place. We also record the work to fix anything. If we test to see if a control activity's being performed and we find it's not, then there's remediation activity that needs to happen. For us, that's really easy. It's all in the same place.

Guy Herbert  (13:50):

If somebody needs to get an exception to a policy, standard, or obligation, we record it in the same place. It's all captured in one place. That's really important because it's a central place where everybody can see it. But it also means that everybody has to have access to that. Previous places where I've worked, the risk tool is where this stuff gets recorded, and the only people who had access to it with the risk people. It doesn't work.

Guy Herbert  (14:17):

We also give our internal and external auditors access to the same information. They can then use the information to reduce the amount of time that they spend with the teams. The auditors can see what the control activity is. They can see what's already been tested. They can see the information that's being collected. Now, there's all these rules around independence, et cetera, for auditors. Our internal testing teams, they're not independent enough, but what the internal and external auditors were able to do was reuse the information so that they didn't have to annoy the teams as much.

Guy Herbert  (14:59):

Communication is really important. It is hard to make sure that everyone knows what needs to get done and what absolutely can't be done. In a slow moving environment, there's lots of time to check this information, to find the right person. But you need to move fast. You need to let people have access to the information at any anytime in a form that helps them. Hey, we make Confluence, so we use Confluence to store most of this information.

Guy Herbert  (15:24):

Policies and procedures that you have to follow: We had a bit of a discussion with our auditors about the fact that anyone could change these, because we're an open company. I talked about our values. One of our values is open company, no BS. Anybody can change these. Our auditors were completely freaked out. It's always nice to freak out an auditor every now and then. But we said, if anyone changes, then we would know. We can tell that they didn't really believe us, until one of their team accidentally changed something that we didn't think they should have changed. And we pinged them on it.

Guy Herbert  (15:57):

Second thing: Agile teams do a sprint. Once you've done your sprint, you run a retro, and you learn from it. Then you can change, not only what you're doing, but how you're doing. This idea alone is enough to drive most compliance people to drink heavily. But it's really important from a compliance perspective. If your organization is relying on a control being performed to meet a compliance obligation, and the team finds that the process is getting in the way of them being successful, then there is the possibility they will change that process. This could mean that the control is now not operating.

Guy Herbert  (16:37):

By getting the teams to own the control and understand the linkage to the control objectives, they're better placed to be able to re-engineer that process, to deliver better outcomes, and still meet the control objectives. Successful Agile teams deliver change fast. You need to help them deliver the right change. Giving them the context that they're operating in is really important. This is not just about the compliance obligations, but that's really important from my perspective, it's also about the environment, the reasons why they do something, the reasons for the change. Let your people have the information to be able to make the right decision.

Guy Herbert  (17:14):

You need the awareness. The risk and compliance teams want to know what people are changing, when they should be getting involved. If you've got a risk and compliance person embedded in every one of your teams, all I can say is, Lord save you. We use JIRA to hold our control activities. This means that if a team wants to change a process, then they can see if that is going to impact your control activity. By following the links, they can see if it will impact a compliance obligation. We can get that awareness without having to be in the teams all the time.

Guy Herbert  (17:47):

Now, about DevOps. Let's talk about how we achieve hourly releases to production. I'm going to assume a wide range of knowledge on the DevOps world. So for some of you, this is going to feel like I'm stating the obvious, but please stay with me.

Guy Herbert  (18:00):

For compliance change management, we required two key controls. A lot of the compliance work that you'll talk about really boils down to this. These two key controls are: All changes are reviewed and approved by somebody other than the person making the changes. And secondly: All changes are successfully tested before going to production. That's really it.

Guy Herbert  (18:27):

In the past, we would have a dev team, a test team, lots of approval gates, and then a deployment team who were all segregated from the production team, and sign off from each of these groups before code is transitioned from one of these to another.

Guy Herbert  (18:44):

If you get back to the basics and rethink your control, it just needs someone other than the person who made the change, that reviews and approves the change, and a set of tests that your change has passed. We make and sell Bitbucket, So of course we have all of our code in Bitbucket. This is our git repository. You'll have an equivalent tool in your environment.

Guy Herbert  (19:06):

We allow any developer in the company access to the code. Any one of them can fork the code from the main branch. I don't care. Now, you won't often get that from a risk and compliance person, but it really doesn't ... I'd let anybody branch the code. You want to merge it back to master? Now I care. This is where we have our controls built in. We have mandatory peer review for all code being merged back to master. Some repos have two mandatory reviewers. We enforce it so that you can't push to master. You have to raise a pull request.

Guy Herbert  (19:46):

The system makes sure that you cannot review your own changes. It's just one of those things that the repositories do. You can't review your own pull requests, just not allowed. This is where we took the culture we worked with. When I initially started having these conversations with people, I said, "Okay, so if we enforced peer review, what would happen?" And they were like, "Well, we already do peer review. It's how we ensure that we shift quality code." It was already in place, we just system-enforced it.

Guy Herbert  (20:24):

Now, there are a couple of other controls. If anyone changes the code after the review, then the system backs out the approval. And this is for any level of change. The reason why was, we were thinking about this going, "Okay well, what happens if it's a really small change?" Well, even a really small change could have an impact on your production environment. It had to back it out completely. We also enforce merge text to make sure that all the mergers have been successful. So, that's around the peer review piece.

Guy Herbert  (20:56):

The next one is the green build piece. Once the code has been merged to master, the build tool then runs the automated test to ensure that we have successfully passed testing and got a green build. Now, the actual tests are defined by the development team. Of course, these are stored in a code repository, which is subject to peer review controls. The build testing is system enforced. If you have a team that doesn't really care about the code, they can design a set of tests where it's always going to pass, but these people, they own the code. They have a vested interest in making sure that it actually works. Having good automated tests is really important.

Guy Herbert  (21:38):

The other thing that's really important is the question about how good is your peer review. If you're relying on peer review as your key change management control for code approval, you need to know that it works. How good is your peer review in your organization? What training do you give your teams? Would they say no to a team member if they felt they could not review the code, that the code was not right, if they wanted another set of eyes on it? You will need to train your teams to do good reviews. This is more about the culture. Get the people that know the code to review the code. The teams know who these people are, get them engaged in looking at the code. Remind them that their name is on the review. If you review the code and say, "This is okay." That's your name attached to that review. Nobody wants to be the person that said that the change was okay and then it all turns out to be bad.

Guy Herbert  (22:35):

I would also recommend, and this is going to sound strange coming from risk and compliance person, I would also recommend against having a checklist of things to review that you attach to the change. Two reasons for this: One is we find that it stops the reviewers thinking. A set of guidelines to help people remember the things that they should review during a change. Great. Really believe in that. Okay. But having it, they'll stop people thinking, they'll just tick it off. Don't think. The second reason is: Teams, at some point, will not do the checklist all the time. You're going to fail your audit. Nobody wants to fail their audit.

Guy Herbert  (23:19):

We often get asked the question from our auditors about segregation of duties, and whether this control is really a good control. Won't the developers just approve each other controls because they're friends? In the audit world is called collusion, collusion breaks any segregation of duties control. So it's not a reason not to do this. I know it sounds a bit circular. Is it a good control? When we talked to our auditors about this, we explained that it's actually a better control than what they were used to. In the past, they had a sign-off from a change approval or advisory board that was there for all the changes packaged up for the period. What's the hardest signature to get for a change approval board? I always found it was the first one, because the question that everybody asks is who else has signed this off? The developers that know the change and know the code are the ones reviewing and approving it. They're more likely to know if something is not right or the change does not do what it's meant to do. Does this mean the end of the change approval board and change advisory board? Not really. It does mean that they can become more strategic and help improve change management practices, because they actually get more time to think about the big picture.

Guy Herbert  (24:35):

For our teams, we get them to have a set of ideals, sort of like a code of conduct almost. We'd articulate this as: I will not merge/promote until my change meets the bar. At a minimum, that means we are confident we can detect breaking changes through automated means before they go out to production. We have automated means to measure that things are working as expected, and we'll be alerted when they're not working as expected in staging and production. If we release a breaking change, the impact would be mitigated within SLO, service-level objectives, and without causing a major incident. This change is resilient to failures in its dependencies. We understand the load expectations on our service and its dependencies, and the change in load can be safely managed. You build it, you track it. For any change you're accountable for it, ensuring it passes the bar. The minimum set. You have foot credibility for the work as well as full responsibility for safely shepherding it to production. The last one is: Approving is co-authoring. For any change you approve, you're responsible for understanding the change and agreeing that it passes the bar. You should consider the change co-authored by to you. Okay, so that's about our peer review.

Guy Herbert  (25:57):

Now, this is all part of our CICD pipeline. Before the build tool will build the artifact, it goes and it checks the repository settings to make sure that they are compliant, to make sure that peer review and green build are turned on for the repository. For a piece of compliant-relevant code going to production, if the settings are not correct, the build tool will not build the artifact. It doesn't even stop the process. It then does testing. If the build testing does not result in a green build, then it will not build the artifact.

Guy Herbert  (26:37):

Once the artifact is built, the build tool then cryptographically signs the artifact to say that has been built from a compliant repository, and that it's passed build testing. Now, great thing about that. I can store this anywhere. It's got a signature. Our production environment checks for that signature for anything that is going to run.

Guy Herbert  (26:58):

Now, we do have some controls over the access to the production environment, but I don't care so much about who can make a change to the environment, because it's checking to see that the code has the signature. Our auditors ask about who can move code to production. But for me, that's not something I worry about. I need to know who can change the signature check, and then our production environment, that is of course, subject to peer review and green build.

Guy Herbert  (27:26):

Two things that I'd say at this point: Get people out of the process, unless you really need them there. They're slow and they're not consistent. Now, I know it's a dreadful thing to say because we're all people, but I am a risk and compliance person. We've realized that if we wanted to hit 99.99% uptime, there was no way that we could have a person in the process. They can not respond fast enough. This also allows us to remove some of the controls from the process. Traditionally, it would need to be segregation between the development team and the team that could load the code to production. But because this is now done by a bot account that checks to see if all the requirements, peer review and green build have been met before it takes it to the next environment, we've reduced the time and delay in the pipeline.

Guy Herbert  (28:11):

The second thing is: You need to be able to evidence your controls. Sometimes auditors just need to see on a screen who has reviewed a change. So much easier to pull up a list of the commits, and show that the person reviewing it was not the same as the person raising it. Makes it really easy. It's also so much easier than trying to follow up on an approval in an email or something like that. If you have any deviations within this process, don't get it to just send an email, get it to create ticket, in whatever ticketing system you're using, because those things leave a trace. It's one of the things that I love about the development pipelines now, there's always a trace of what happened.

Guy Herbert  (28:54):

Okay, so what's that mean to our environment? This approach changes the control from being a manual control to being in an automated preventative control. This has a big impact on our audits. Some simple maths to explain this. We have 60 services that are part of our SOCs compliant environment. They're all high change, more than daily changes. They're all high risk. All of them could have a material impact on our financial statements. That means that in a traditional audit approach, we would have to do an audit sample of 60 fully-documented change approvals and tests for each of the services. 60 times 60, yep 3,600. It's really easy math.

Guy Herbert  (29:36):

But now it's an automated test or an automatic control. It means that we have a test of one. Think of the hours that this could give you a team back, not having to find and provide screenshots of emails and chats to show approvals, test plans, and results.

Guy Herbert  (29:51):

I had one of the dev managers come and ask me when the audit was happening. He'd been in a half-hour meeting with the auditors, and asked about how the control process with them. He was then thinking that they would come and back to sample test these changes. My response was, "Audit's already done." He was amazed. He'd come from a SOCs-controlled company before, and could not believe that we had made the audit so streamlined.

Guy Herbert  (30:12):

Remember how I started at this side, I asked who worked in sales. To convince our auditors that this was a good compliance control took six meetings. We had to propose the control and then deal with all of the objections as to why it would not work. We actually spent a significant amount of time before those meetings thinking all the reasons they would say no, and came up with good reasons to argue against that. In the end, they agreed with us that it's a much better control, and is what they would like everybody doing. It really reduces the repetitive work that they have to do. Something that is not very interesting, even for auditors.

Guy Herbert  (30:50):

Now, I've talked a lot about compliance. And I think it's important to understand the difference between compliance and risk. Compliance means that we have some other than the pull request raiser who approves it. What about risk? If this site feels like something is really risky, you might increase the number of reviewers, or create a set of people that are required reviewers to manage that risk. But we do that for risk management, not for compliance. I think that's really important to understand the difference there. Now, there might be reasons why the risk is higher. You might have a lot of code with tech debt, where it might be a really risky change where it's going to have a huge impact if it goes wrong. You just might want to go, "All right, I want to have more eyes on this change." But you do it for risk management, not for compliance.

Guy Herbert  (31:46):

What did it mean for us? Less access management. The systems are now smart enough, they can tell that you were the person that raised the pull request. Therefore you cannot be the person to approve it. Now I don't have to have a set up and manage a group of creators, and separate them from a group of reviewers. I also don't have to manage a change approval board group or a deployment group. My access change management for role changes just got a whole heap easier. And, just as a heads up, most organizations fail at this. Ask your internal audit team about this issue. I won't be surprised if they don't have a role change audit issue every year. You do need to know who can turn off the controls. There's some access management there. We restrict the number of people can make these changes in our deployment build tool, but we don't strictly limit the number of people that can turn off the peer review settings. But they have to turn them back on to get their artifact built. And we monitor the setting's changes on the repo.

Guy Herbert  (32:51):

If somebody changes the settings, we come back to them and we say there manage, "Can you confirm that this was okay?" If there was a change while the settings were not enforced, that the manager then reviews those settings. If someone turns off the compliance checks on our build tool or the production signature check, we monitor an alert on that as well. There is some monitoring, there is some alerting that goes to the risk and compliance team within our environment. This is not easy for a lot of organizations. My advice, hold the line. When people say you can't do it, go, "Okay, let's understand why." Work with your risk and compliance team. Work with your internal auditors. Work with your external auditors.

Guy Herbert  (33:39):

As an example, when we were doing our ISO 27001 outwork, I realized that this was a new group of auditors that didn't have experience with the way we did things. I actually ended up going up to Amsterdam and had multiple meetings with them to get them to really understand the controls, and how they worked, and why they worked. My view is, reach out to them before the audit and explain what you're doing and why. See it as sales.

Guy Herbert  (34:13):

Second thing: It's easier for auditors to be able to track a ticket than it is to track email. If something's going wrong in the various platforms, we raise a ticket. For us, it's in JIRA. The great part about that is that you can see the status, the progress, the evidence, and the closure. And all of that information is in one place. It means they don't have to go to people and say, "Okay, have you got that email?" It means they don't have to try and track down Slack channels of all the conversations, et cetera. I can see all the history. I can see all of the things that happened on that. It means that that information is there, available to me.

Guy Herbert  (34:52):

Here's a trick that we tried because we were doing a lot of things with automated controls. When somebody leaves the organization, we had problems with people separating and then trying to backdate information into the HR system. Because all of our systems and our connected, we said you can't backdate in the HR system. That means that when somebody leaves our organization and the manager doesn't put the information into the HR system for a week after they left, we paid them for an extra week. It's a way of thinking differently about controls in your organization, to be able to reduce your compliance impact.

Guy Herbert  (35:34):

The last one is: Role change. We do large role changes. We have large groups of people, and we only look at changes between those groups. All of our developers in one pool. We don't segregate into slots or small change groups. And so that makes life easy.

Lauri Palokangas (35:55):

That was guy from Atlassian.

Lauri Palokangas (35:57):

You sure did miss his awesome graphics in the slides, but not to worry, you can always go online to watch all of the DevOps 2020 speeches in video. Find the link in the show notes and carry on.

Lauri Palokangas (36:10):

In the next episode, we will hear Dan Garfield, Chief Technology Evangelist from Codefresh. Dan is a technology leader and full stack engineer specialized in evangelizing containers, Kubernetes, helm, Istio, and related technologies. As the Chief Technology Evangelist, Dan leads communication, marketing, and forward thinking technology initiatives.

Lauri Palokangas (36:31):

Until then, deliver software and hold the line.