>> Narrator: 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 Forrester.
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,
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 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 run an analysis of how developers commit times
and level of work that they were committing
and how they were working.
In the first couple months of COVID, was progressing,
they found that developers,
at least in the Pacific Time Zone,
were actually increasing their work volume,
maybe 'cause they didn't have two hour commutes,
or maybe because they work stuck away in their homes,
but for whatever reason, they were doing more work.
And it's almost like, if you've ever run a marathon,
the first mile or two in the marathon, you feel great,
you just want to run and you want to power through it,
you want to go hard.
And if you do that, by the time you get to mile 18 or 19,
you're going to 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 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 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 remotable.
One of the things I 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, the 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 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 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 bandwidth 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 is 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
and how are you seeing organizations adopt it?
>> 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 in 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 holler over theCUBE,
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 want to be spiritually co-located
and if you want to 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, okay?
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 going to do, here are our processes,
and here are our guardrails.
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, they'll get spiritually connected.
I hope that makes sense (chuckles).
>> It does, I think we all could use some of that.
But 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 at late at night
on the weekends.
So, but it's a cultural, it's a mind shift.
To your point about DevOps focused on velocity,
sprint, sprint, sprint, 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 sprint 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 going to see
that developer doing a check in at 9:00 p.m. on a Friday,
because that's what they had to do to meet the objectives.
And they're going to have to find new ways
to measure engagement and also potential burnout.
A friend of mine once had a great metric
that he called the Parking Lot Metric.
It was helpful as the parking lot at nine
and helpful was 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 turn 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
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 their kids as co-workers
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.
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 the video conference room open
at the team level all day long.
And the team members will go on mute,
so that they don't have to,
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, a presentation they did that
Microsoft's onboarded over 150,000 people
since the start of COVID.
If you don't have good remote onboarding processes,
that's going to 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 get people their badges,
to how they get their equipment.
Security is another issue that they called out.
Typically, IT security, security of developers machines,
ends at the corporate desktop.
But now since we're increasingly using our own machines,
our own hardware, security organization's going to 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 and embracing low code tools.
In fact, we see about 50% of firms
are using low code tools right now,
we predict it's going to be 75% by the end of next year.
So, figuring out how your DevOps processes
support an organization that might be using Mendix
or OutSystems, or 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 back end 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.
(bright upbeat music)