 From around the globe, it's theCUBE with digital coverage of DevOps Virtual Forum, brought to you by Broadcom. Hi, Lisa Martin here, covering the Broadcom DevOps Virtual Forum. I'm very pleased to be joined today by a CUBE alumni, Jeffrey Hammond, the vice president and principal analyst serving CIOs at Forester. Jeffrey, nice to talk with you today. Good morning, it's good to be here. So a Virtual Forum, a great opportunity to engage with our audiences. So much has changed in the last, it's an understatement, right? Or it's an overstated thing, but it's obvious. So much has changed. When we think of DevOps, one of the things that we think of is speed, you know, enabling organizations to be able to better serve customers or adapt to changing markets like we're in now. Speaking of the need to adapt, talk to us about what you're seeing with respect to DevOps and agile in the age of COVID. What are things looking like? Yeah, I think that for most organizations, we're in a period of adjustment. When we initially started, it was essentially a sprint. You know, you run as hard as you can for as fast as you can for as long as you can and you just kind of power through it. And that's actually what the folks at GitHub saw in May when they ran an analysis of how developers commit times and a level of work that they were committing and how they were working in the first couple of months of COVID was progressing. They found that developers, at least in the Pacific time zone, were actually increasing their work volume, maybe because they didn't have to our commutes or maybe because they were stuck away in their homes, but for whatever reason, they were doing more work. And it's almost like, you know, if you've ever run a marathon the first mile or two in the marathon, you feel great and you just wanna run and you wanna power through it and you wanna go hard. And if you do that, by the time you get to mile 18 or 19, you're gonna be gassed, sucking for wind. And that's, I think, where we're starting to hit. So as we start to gear our development shops up for the reality that most of us won't be returning into an office until 2021 at the earliest and many organizations will be fundamentally changing their remote work policies. We have to make sure that the agile processes that we use and the DevOps processes and tools that we use to support these teams are essentially aligned to help developers run that marathon instead of just kind of power through. So let me give you a couple of specifics. For many organizations, they have been in an environment where they will tolerate remote work and what I would call remote work around the edges. Like developers can be remote but product managers and, you know, essentially scrum masters and all the administrators that are running the SCM repositories and the DevOps pipelines are all in the office and it's essentially centralized work. That's not where we are anymore. We're moving from remote workers at the edge to remote workers at the center of what we do. And so one of the implications of that is that we have to think about all the activities that you need to do from a DevOps perspective or from an agile perspective, they have to be remoteable. One of the things I've found with some of the organizations I talked to early on was there were things that administrators had to do that required them to go into the office to reboot the SCM server as an example or to make sure that the final approvals for production were made and so that code could be moved into the production environment. And so it actually was a little bit difficult because they had to get specific approval from the HR organizations to actually be allowed to go into the office in some states. And so one of the results of that is that while we've traditionally said, tools are important but they're not as important as culture, as structure, as organization, as process. I think we have to rethink that a little bit because to the extent that tools enable us to be more digitally organized and to achieve higher levels of digitization in our processes and be able to support the idea of remote workers in the center, they're now on an equal footing with so many of the other levers that organizations have at their disposal. I'll give you another example. For years we've said that the key to success with Agile at the team level is cross-functional co-located teams that are working together, physically co-located. It's the easiest way to show Agile success. We can't do that anymore. We can't be physically located at least for the foreseeable future. So how do you take the low hanging fruits of an Agile transformation and apply it in the time of COVID? Well, I think what you have to do is that you have to look at what physical co-location has enabled in the past and understand that it's not so much the fact that we're together looking at each other across the table. It's the fact that we're able to get into a shared mind space from a measurement perspective. We can have shared purpose. We can engage in high band with communications. It's the spiritual aspect of that physical co-location that is actually important. So one of the biggest things that organizations need to start to ask themselves is how do we achieve spiritual co-location with our Agile teams? Because we don't have the ease of physical co-location available to us anymore. Well, spiritual co-location, such an interesting kind of provocative phrase there, but something that probably was a challenge. Here we are seven, eight months in for many organizations, as you say, going from physical workspaces, co-location, being able to collaborate face-to-face to a light switch flip overnight and this undefined, indeterminate period of time where all we were living with was uncertainty. How does spiritual, when you talk about spiritual co-location in terms of collaboration and processes and technology, help us unpack that. How are you seeing organizations adopted? Yeah, it's a great question. And I think it goes to the very root of how organizations are trying to transform themselves to be more Agile and to embrace DevOps. If you go all the way back to the original Agile manifesto, there were four principles that were espoused. Individuals and interactions over processes and tools. That's still important. Individuals and interactions are at the core of software development. Processes and tools that support those individuals and those interactions are more important than ever. Working software over comprehensive documentation, working software is still more important. But when you are trying to onboard employees and they can't come into the office and they can't do the two-day training session and kind of understand how things work and they can't just haul over the cube to ask a question, you may need to invest a little bit more in documentation to help that onboarding process be successful in a remote context. Customer collaboration over contract negotiation, absolutely still important, but employee collaboration is equally as important if you wanna be spiritually co-located and if you wanna have a shared purpose. And then responding to change over following a plan. I think one of the things that's happened in a lot of organizations is we have focused so much of our DevOps effort around velocity, getting faster. We need to run as fast as we can, like that sprinter. Trying to just power through it as quickly as possible. But as we shift to the marathon way of thinking, velocity is still important, but agility becomes even more important. So when you have to create an application in three weeks to do track and trace for your employees, agility is more important than just flat out velocity. And so changing some of the ways that we think about DevOps practices is important to make sure that that agility is there. For one thing, you have to defer decisions as far down the chain to the team level as possible. So those teams have to be empowered to make decisions because you can't have a program level meeting of six or seven teams in one large hall and say, here's the lay of the land. Here's what we're gonna do. Here are our processes and here are our guard rails. Those teams have to make decisions much more quickly. The developers are actually developing code in smaller chunks of flow. They have to be able to take two hours here or 50 minutes there and do something useful. And so the tools that support us have to become tolerant of the reality of how we're working. So if they work in a way that it allows the team together to take as much autonomy as they can handle, to allow them to communicate in a way that delivers shared purpose and allows them to adapt and master new technologies, then they're in the zone and they'll get spiritually connected. Hope that makes sense. It does. I think we all could use some of that. You talked about in the beginning and I've talked to numerous companies during the pandemic on theCUBE about the productivity or rather the number of hours worked has gone way up for many roles and times that they normally late at night on the weekends. But it's a cultural, it's a mind shift to your point about DevOps focused on velocity sprints, sprints, sprints and now we have to, so that cultural shift is not an easy one for developers and even the biz folks to flip so quickly. What have you seen in terms of the velocity at which businesses are able to get more of that balance between the velocity, the sprints and the agility? I think at the core, this really comes down to management sensitivity. When everybody was in the office, you could kind of see the mental health of development teams by watching how they work. You can call it management by walking around, right? We can't do that. Managers have to be more aware of what their teams are doing because they're not gonna see that developer doing a check-in at 9 p.m. on a Friday because that's what they had to do to meet the objectives and they're gonna have to find new ways to measure engagement and also potential burnout. Friend of mine once had a great metric that he called the parking lot metric. It was how full is the parking lot at nine and how full is it at five? And that gives you an indication of how engaged your developers are. What's the digital equivalent of the parking lot metric in the time of COVID? It's commit stats, it's commit rates. It's the churn rate that we have in our code. So we have this information. We may not be collecting it, but then the next question becomes how do we use that information? Do we use that information to say, well, this team isn't delivering as at the same level of productivity as another team? Do we weaponize that data or do we use that data to identify impedances in the process? Why isn't a team working effectively? Is it because they have higher levels of family obligations and they've got kids that are at home? Is it because they're working with hardware technology? And guess what? It's not easy to get the hardware technology into their home office because it's in the lab at the corporate office or they're trying to communicate halfway around the world and they're communicating with an office lab that is also shut down and the bandwidth just doesn't enable the level of high bandwidth communications. So from a DevOps perspective, managers have to get much more sensitive to the exhaust that the DevOps tools are throwing off, but also how they're going to use that in a constructive way to prevent burnout. And then they also need to, if they're not already managing or monitoring or measuring the level of developer engagement they have, they really need to start, whether that's surveys around developer satisfaction, whether it's more regular social events where developers can kind of just get together and drink a beer and talk about what's going on in the project and monitoring who checks in and who doesn't. They have to work harder, I think, than they ever have before. Well, and you mentioned burnout and that's something that I think we've all faced in this time at varying levels and it changes and it's a real, there's a tension in the air regardless of where you are. There's a challenge, as you mentioned, people having, you know, coworkers, their kids as coworkers and fighting for bandwidth because everyone is forced in this situation. I'd love to get your perspective on some businesses that have done this, well, this adaptation. What can you share in terms of some real world examples that might inspire the audience? Yeah, I'll start with Stack Overflow. They recently published a piece in the Journal of the ACM around some of the things that they had discovered. You know, first of all, just a cultural philosophy. If one person is remote, everybody is remote and you just think that way from the executive level. Social spaces, one of the things that they talk about doing is leaving a video conference room open at a team level all day long. And the team members, you know, will go on mute, you know, so that they don't necessarily have to be there with somebody else listening to them. But if they have a question, they can just pop off mute really quickly and ask the question and if anybody else knows the answer, it's kind of like being in that virtual pod, if you will. Even here at Forrester, one of the things that we've done is we've invested in social ceremonies. We've actually moved our team meetings on my analyst team from once every two weeks to weekly. And we have built more time in for socialization just so we can see how we're doing. I think Microsoft has really made some good information available in how they've managed things like the onboarding process. I think Amanda Silver over there mentioned that a couple of weeks ago in a presentation, they did that Microsoft onboarded over 150,000 people since the start of COVID. If you don't have good remote onboarding processes, that's gonna be a disaster. Now they're not all developers, but if you think about it, everything from how you do the interviewing process to how you, you know, get people their badges to how they get their equipment, security is another issue that they called out. Typically IT security, you know, security of developers machines ends at the corporate desktop. But now, you know, since we're increasingly using our own machines, our own hardware, security organizations kind of have to extend their security policies to cover employee devices. And that's caused them to scramble a little bit. So the examples are out there. It's not a lot of like, we have to do everything completely differently, but it's a lot of subtle changes that have to be made. I'll give you another example. One of the things that we are seeing is that more and more organizations to deal with the challenges around agility with respect to delivering software embracing low-code tools. In fact, we see about 50% of firms are using low-code tools right now. We predict it's gonna be 75% by the end of next year. So figuring out how your DevOps processes support an organization that might be using Mendex or OutSystems or, you know, the Power Platform, building the front end of an application like a track and trace application really, really quickly, but then hooking it up to your backend infrastructure. Does that happen completely outside the DevOps investments that you're making and the agile processes that you're making or do you adapt your organization? Are hybrid teams now teams that not just have professional developers, but also have business users that are doing some development with a low-code tool? Those are the kinds of things that we have to be willing to entertain in order to shift the focus a little bit more toward the agility side, I think. A lot of obstacles, but also a lot of opportunities for businesses to really learn, pay attention here, pivot and grow, and hopefully some good opportunities for the developers and the business folks to just get better at what they're doing and learning to embrace spiritual co-location. Jeffrey, thank you so much for joining us on the program today. Very insightful conversation. It's my pleasure. It's an important thing. Just remember, if you're going to run that marathon, break it into 26, 10-minute runs, take a walk break in between each and you'll find that you'll get there. Digestible components, wise advice. Jeffrey Hammond, thank you so much for joining. For Jeffrey, I'm Lisa Martin. You're watching Broadcom's DevOps Virtual Forum.