In the last episode of the ContinuousX Podcast, hosts Mike Fitzurka and Rick Stewart of TD SYNNEX Public Sector were joined by Cliff Berg, one of the coauthors of Agile 2: The Next Iteration of Agile, for a discussion about Agile software development, and why a new approach to Agile was needed.
In the second part of their discussion, the hosts shift gears to discuss the relationship between Agile and DevSecOps. During their discussion, Cliff shares his view of DevOps as a risk management strategy that enables developers to create applications and software quickly while reducing or eliminating the risk of things not working or being vectors for cyberattacks. He also explains how DevOps can transform and streamline government processes and operations.
Click the “PLAY” button below to watch their conversation, or scroll down the page to read the transcript.
Transcript: ContinuousX Podcast (Season 2, Episode 10) on Agile 2: The Next Iteration of Agile
Rick Stewart: Welcome back to another episode of our ContinuousX podcast where we try to “Solve for X in the SDLC Equation.” And we’re back with coauthor of Agile 2: The Next Iteration of Agile, Cliff Berg.
Michael Fitzurka: Hey Cliff, I would like to ask about the public sector in more specific detail, where we find that those agencies are usually more risk averse, and they value stability over agility. And that’s why we see a resonance more with DevSecOps approaches than Agile Management.
Agile management is really difficult. It doesn’t quite mesh with the way the government procures and does business. But DevOps, that shares guiding principles with Agile. And also, I’ve always seen that when they’re talking about DevOps, there’s an assumption that, oh yeah, you’re doing something Agile. You’re short iterations, you’re doing something there, right? But let’s talk about your pipelines and your continuous integration.
So, when you looked at Agile 2, what is Agile 2’s relationship to DevOps? And can Agile 2 maybe help transform government operations more proficiently?
Cliff Berg: Yeah, well, there are several… Thanks, Michael… There are a couple of questions embedded in that. It’s a multifaceted issue. First, I’d like to point out there really is no definitive definition of DevOps.
Jean Kim has been a really good spokesman for DevOps. He wrote the first book, actually an article, “The Three Ways,” that distilled the essence of DevOps in his opinion. And it strongly resonated. It stood the test of time. I think he really did kind of nail it.
But DevOps really emerged as just a collection of techniques during the 2000s, that the companies that were trying to do things on internet scale, and they were leveraging commodity virtualization, and cloud services which were enabled by commodity virtualization, in order to do things, we couldn’t do before, like dynamically provision test resources. So that made things possible that didn’t used to be possible. DevOps is as an answer for how do we deploy changes constantly, like all day long, at huge scale, hundreds of millions of users and be confident that it works. That’s key, be confident that it works.
So, DevOps is fundamentally, fundamentally a risk management strategy. It’s fundamentally a risk management strategy, and it’s not often viewed that way. It’s viewed in terms of speed, but really, it’s about going fast and making sure things work.
But the missing piece that usually gets forgotten about, except in very experienced teams… Actually, Google hasn’t forgotten about this. I’ll tell you in a minute… but in order for that to work, you have to manage the test coverage of everything. Because, if you have… like in the government sector… If you have an ongoing ATO, authority to operate, where you have permission you can constantly release new versions of something. You have, for that to be really feasible, you have to have high confidence that your tests cover all the risks… your tests cover all the risks. So, how do you know? How do you know?! So, if you look at, well, is their metric for that? No, there’s not. Because if you look at a common metric that DevOps teams often use is code coverage, but code coverage is a very low-level proxy for test coverage, and it doesn’t have any bearing on system-level behavior. You really need to manage your test coverage at all levels of the system, including, and especially, the integration level.
There are famous failure cases recently, with Boeing in particular, about failing to do real integration tests and having disasters. So, managing that test coverage… and if there’s no number, then you need practices. You need practices that give you sufficient assurance that you’re keeping the test coverage where it needs to be. Like having test experts review the test specs to see that the cover edge cases and things like that. You need practices involved. So, if you can have a way of assuring yourself that you’re well managing the test covered, you can have that high assurance that you can constantly deploy things and your risks are covered.
You mentioned about, how government can do it. Recently, I’ve been talking to a really interesting fellow. His name is Dr. Dan Rasky, and he was a co-founder of the NASA Space Portal Office. And if it weren’t for him, SpaceX wouldn’t exist today. It was his office when SpaceX had spent their last dollar, where Elon Musk was sleeping on Larry Page’s sofa, and their third launch attempt on the Falcon 1 failed, but they had enough spare parts to cobble together a fourth vehicle. And they knew what had gone wrong in the third launch.
So, there was a chance they could make it work, and they put another vehicle together. They basically threw out all their procedures, because they had to do it in record time, and no one was being paid. And so, there were no controls or anything like that. They just basically, like a bunch of people in a garage, put that rocket back together and launched at the Kwajalein Atoll in the Pacific. And thank God it worked. And because of that proof that they actually could put the vehicle in orbit, the Space Portal Office was able to get SpaceX awarded… I think, $200 million? No, I forget the number, but a significant contract to develop the next capability, which ended up being the Falcon 9.
I think it was Gwynne Shotwell, who actually was involved in closing that, but it was the Space Portal Office that that created the structure. And the structure that they created was more of a partnership. And Dan Rasky feels that you really need to, instead of just paying people to do something, you really need to have more of a partnership. The vendor has to have money at stake, money at risk. But then they also need to have very significant benefit when things work. Because if things don’t work, they don’t get paid under that model, or they get paid less. But if things work, they get paid very well. So, it’s s a win-win; it’s lucrative.
And also, the vendor usually keeps intellectual property, to some degree. It’s all part of the arrangement. But the basic idea is more of a partnership, rather than just work for hire. And I think that might be a repeatable model, and I’ve been looking at what you do with subcontractors. SpaceX is also an interesting study from that regard. And I think it’s scales. I mean, that’s certainly scaled in that case. We definitely need to be creative.
I worked for Mark Schwartz many years ago, who was, at one time, the CIO of Immigration. And I actually reported directly to him for about six months, because his plan was to bring in a section chief to oversee a group of three transformation consultants. But he didn’t have a person, so we would meet with him. And he was talking about DevOps from day one. And, I said to him, I think your biggest achievement is the way you tailored procurement and procurement roles. And he said, yes, I think so. And there were some things that got in the way of what he tried to do. I think that always having to choose a low-cost vendor, I think got in the way. But his basic idea was to have more of a partnership, where the government actually played a role in managing the work. They played a collaborative role in managing the work. And so, they would hire teams, bring in a bunch of teams, and there was a renewal every six months. So, instead of a sole award to one vendor to build a bunch of requirements out and build a bunch of requirements, there was an award to provide capabilities and then collectively worked toward building operational… toward building systems. And the actual system requirements were fluid. So, it was more like a partnership.
So, there are many ways to approach that, but I think that whole partnership idea might be central to it. And if you go back to Skunk Works, it was like that too. I mean, with the original Skunk Works they used to invite the government to every test, even if they thought the test was gonna fail. They invited the government. This is how we’re building it. This is how we do it. This is how we’re making the sausage. And it was very transparent. So, I think that’s probably the core of what we need, all that transparency and partnership arrangement.
