Scaled Agile Framework – Adam Sandman, Inflectra

This is Textron TV. Hey guys. Thanks for the throw.

We're here with Adam Sandman. Who's CEO for in Fletcher? And we're talking about the current state of application development in the sense that we want to have everything.

We want applications that are secure. We want them to scale. We want them to be high quality and we want to build fast and we want no compromise on any of those issues Adam.

Welcome the show. Thanks so much Mike. Thanks for having me on the show today.

So we've been talking about this issue pretty much for the last year intently. I mean it's been around for a while but forever in a day now, we've kind of been trying to say how do we kind of develop applications quickly and sometimes people would compromise on one thing or another different in the name of speed and I guess that we got to a point now where we can actually do all these things that we need where the application is high quality. It's delivered quickly.

It's secure and we're not going back to fix it all the time or is that just wishful thinking? Well, I think it's it's a combination of the two. We're always getting further along that Continuum.

I when we started doing software development, you know before agile requirements were to find out front people wouldn't see the software for maybe six months to a year after it was developed and maybe tested fully and that point what they usually found was the software didn't meet their needs for functional standpoint. gov roll out where things were released and they never really gone through the rigor of testing or user feedback. And so we've got well, I'll definitely a lot further along than we were maybe five ten years ago and I've been doing this for about we're good as 20 years both pre agile and sort of after the agile Manifesto.

We're much better. We're now looking at doing with ship left. We're moving to do security testing performance testing what during development we're not waiting till the end people that are testing automatically, you know, while the app is being developed.

We're not waiting till the end. So I think we're definitely a lot for the long on the speed and the quality side. And we haven't really grappled I think risks is one of the new areas that we're starting to see more focus on because people will be focusing on what they've measured or what they know to they think to be the issue.

And what happens is something that's unforeseen will trip them up in the cyber world. The classic was that everyone was focusing on the perimeter firewalls email phishing securing the the perimeter of century of your application of your Castle the moat, but then there was a back door or your source code was being developed and people were not matching the quality of the software of the software being developed and someone injected you solo wins into the software itself through the supply chain of all the components malware so they completely got around all the security. So that was a risk that known as seen and now of course everyone is addressing that and then the risk, I think it was the last year in Australia Optus had a data breach where they had people steal test data, which was actually production data.

That's sort of being semi sanitized again something that wasn't being looked at and so we're always chasing I think the last war and so therefore risks and risk management. Based approaches are a way to think about the things before they happen. So we're not always playing catch up because it's an asymmetrical unfortunately environment.

It's easy to be a hacker easy to break something and find the vulnerability. You're defending, you know, 99% You just need one percent to fail. So I think risks the risk part of what you state.

I think is the area where the most immature but certainly quality and speed we're getting much better at balancing those two and not just making things fast and breaking things fast. Are a certain framework certainly gain more traction than others in this space because there are multiple ways to skin this cat but you're starting to see people kind of shift in One Direction or are there multiple directions? Yeah.

Definitely. I think like when we've been agile first came out you had the scrum versus kanban versus extreme programming and a whole bunch of other methodologies that people don't remember like dstm and things. So in the same way that when ago first came out everyone was trying to add on different ways.

And and now we've kind of evolved towards this scrum plus extreme programming hybrid that's become effectively than normal for most agile teams when it comes to scaling agile and dealing with the complexity of large scale development and the risk management that goes with that again, there are many methodologies like Nexus safe. So come of scrum safe, but I think safe has become the one that people that gravity to gravitating towards it's the most built out framework and it definitely has the most I think discreet pieces that help someone pieces together with the others. You'll let more on your own the child.

I think with safe right now is a lot of people If they look at it and go it's so much and it seems so complicated and I have they're struggling of how to apply it what's important and what's important for them for the scale? They're operating at and the way they're operating and I think people they do one of the two things the other throw their hands have been say it's too complicated or they or they say I want to do every single piece of this to the letter and now you're not agile, you're basically like rational unified process Mark 2 and I think between those two extremes is that people need to find a way to find what's valuable in a framework say safe and the different levels of safe and understand. How does it apply to how they develop software where can they benefit and what parts frankly should they just not bother with it doesn't make sense for them.

There's a lot of controversy around agile in general after all these years and is what you described really at the root of that whole debate. It's just a question of bright sizing agile to your organization versus kind of following the precise letter of the law and viewing it as you know, I said a gospel tenants that thou shalt not violate. Well, I think that's true of agile as well.

I mean, I remember when we first started using what was the Decay manager when I started it was extreme programming and it was most of the principles of sound if you look at the principles of what the agile Manifesto talked about in testing before doing development early feedback getting feedback early in Rapid Cycles. Most of it's good. But what happened is people become dogmatic so good example, we see a lot with our customers is user stories.

If you go into the agile Manifesto and if you look at safe and scale, it's got some of the same pieces that well without shall have user stories and they shall be one or two sentences long, which is great but it doesn't say in agile. You shouldn't have any other kind of requirements, but that's what people take it as and we see a lot of customers fail because if you're working for a complex healthcare system or Aerospace or Automotive system with tons of regulatory requirements, you do need user stories for your development team, you need requirements for your legal compliance and other teams that have to work within these very complex legal and Regulatory environments that you work within if you're a bank or insurance company or automotive and I think it's Same approach and save it's like well it safe says we can do these things like having a product that's made up of what they call release trains, which I find very hard to understand the name, but the concept is a product was long lived which you can have multiple releases and it's it's a set of requirements that evolves over time. We would agree that makes sense.

So I think people get hung up a little bit on both an agile and in the scaling of agile obsessing about what's written as opposed to what was behind. What was the written the why as opposed to the what? It is clear that more responsibility is Shifting left towards the developers along with the agile framework.

What do you think is the relationship going to be between developers who Embrace agile and devops teams? How will that evolve from your perspective? Well, that's an interesting one because we've seen the same story plat with testas.

So when in the testing World test is have been radically s***, you know integrated into agile teams. And so, you know, Tesla had their own discipline before before agile, you develop software and someone tested it. So in the same way with devops teams, you've got the devops engineers who are supposedly different to the feature developers, but really the whole point available, so to allow operations and infrastructure to be the speed of development.

So I think you have to have I think developers need to understand their boss to varying degrees. If you're building a cloud native application for our customers deploying, you know, every hour that's one type of environment if you'll working and maybe a slower Pace maybe more traditional development shop where you're releasing once a month and the technology is a little bit less Cloud native. You need less devops experience as a developer, but you still need to The basics of confused integration continuous deployment, you know provisioning so infrastructure as a service I think developers have to understand this as they also now that need to understand security performance and testing whereas twenty years ago.

They didn't I think it's another skill that developers need to have as long with user design if you if you're working as a developer and trying to use it understand a user story. You have to have some degree of ux experience. That doesn't mean you are a ux specialist, but you need to have at least some understanding of user experience.

So these other functions don't go away per se it's just that everybody needs to have a better understanding of what the other member of the team is actually doing and and so they can have a meaningful conversation about I agree with that and I think I think that's very important. It doesn't mean you're not gonna have a devops expert but no one's no one is gonna have a team where every single person is AWS or as your certified to the same level because then I'll have time to put into code and vice versa. So everyone will have Specialties but you will listen to have General understanding it so like University College, we have the ge's effectively like your ge's will be your basic coding basic devops basic security performance, and then you might specialize in become a front-end developer.

You might become a server database, you know SQL sequel, you know performance data database kind of developer. We might be more of an infrastructure type developer and I think that's very very good way to think of the industry. It'll be different career possible with a common framework, of course skills that you need to have.

What do you think is the challenging getting developers to pick up some of those skill sets, you know in my experience most developers have limited exposure to cybersecurity. I think it was an elective if they had it on exposed to it at all and none of them ever really took it. So how do we kind of get them to kind of embrace it because I don't think any of them got out of bed this morning and said, let's go build an insecure application and yet somehow rather there's some sort of Hill to climb.

So what does that look like? And how do we get him up it and I think you hit the nailhead in terms of the hardest challenge is cultural and I cover the development background, you know, leave me alone. I want to code I'm gonna find them building this great application.

It's fun. I am going to Arrow handling or use of use of Sanitation all the boring security stuff that I made to do. So it's from a university education or how are people learn that is up to the curriculum to sort of stress that I think in a workplace where you're getting people who come out of college and starting to develop maybe for the first I'm in a commercial setting I mean leadership mentorship probably some code review sticks and carrots.

But also maybe making it more fun hackathons doing things in an organization to bring out the gamification as much as I hate that word but to do something like that like having a hackathon on security or a performance upon who can get this one page app to load the fastest we'll win something. So I think if you can bring out the competitive spirit in people that seems to work very well with the development Community. We do something every year called the test, but we take a testing competition and we found that helps people get involved in testing who will maybe in the non-testing disciplines and I think any way to make it fun and you're learning something it's not just a boring thing you have to do because someone told you that's always the best way but I do think they'll need to be some degree of quality control in terms of code reviews when you commit into a branch and you know having someone review who maybe more experience in security say and giving feedback if that isn't in place because I think it's too big of a risk.

Unfortunately now to let people do heroic efforts. As we as end users and even business Executives cheering for the wrong thing. Maybe we don't stand up and go.

Wow. That was awesome. Look at this security where this is going to be great because you know, we kind of give that the tepid golf implies why we're all screaming about this great feature.

So maybe do we the culture needs to change not just among the developers but maybe amongst us folks who consume software. I totally agree with that. Unfortunately.

It's like Insurance, you know, when s*** when you don't have a flutter you don't have a husband down you don't worry about your insurance and when it happens you do so the developers who stopped a vulnerability isn't she celebrated because it's the vulnerability that is unfortunately on the news and then you features it's in the news and I think there's also a reticence to talk about some of this stuff for security reasons. So for example, many companies, they'll publish release notes and they will publish all the new features of all the bugs. They won't necessarily publish all the security fix because if someone's not on that version that that fix may not yet be in place and so there's the legitimately a worry about celebrating About this so I think finding internal safe ways to celebrate and reward.

This is important, but obviously it is doing more difficult because some of the stuff is more sensitive, but very nature especially on the security side. So once you're best advice to folks do I just throw everybody in the room and lock the door until they all figure it out or is there some way to kind of gently nudge everybody in the right direction? Oh, that's a hard question.

I think it's leading the first leading by example having people who are in as leadership position and development actively, you know doing taking on development tasks that involve security modeling the way I think it's also understanding risk management and taking like we do a session where we literally do a brainstorm on risks and we have everyone developers test as advantages ux people come in talk about all the rest that could happen and we make it as fun. We what's the most wildest craziest thing you could think of someone could drop coffee on the machine and codes itself of vulnerability and then think about all these rate them from the most likely to the most implausible and somewhere in the middle. You'll find the things that people thought were implausible but not super implausible and then have people investigate those make a research topic.

So trying to make it fun. I mean there is that brainstorming lock in a room but having a risk framework helps a lot and that also from specific performance security having someone go off and say this for this month, you're gonna be the security Guru come back and present back to the team. We also give opportunities for growth like going to Defcon so And are we send some of our security people or people interested in security Defcon in Las Vegas and they get to see crazy stuff there like people trying to hack pacemakers and when they come back, you know much is not applicable but it does fire people up because people always want to go to the dev conference and learn about the latest, you know, react framework, but if we're not sending people to a fun security or performance testing or whatever it is conference some of that they can get jazzed up about it.

I think you're always gonna be fighting that cultural war and then I think I do think a Frameworks like safe things where risk management is being baked in a really important for a sort of structure and programmatic side of things. All right. So we're at the start of 2023.

What's your crystal ball telling you for the future of agile? I think in 2023 we're gonna see people doing the first large scale safe implementations safe, like implementations. I think we're gonna see risk management mainstreamed.

I think risk management is gonna go from being something that is niche in organizations to be something that everyone understands and everyone uses. So I would say those two aspects will be the biggest maybe unsung stories of 23, but we look back. I think it's what's going to change the industry.

All right folkshire heard in here. The only way to secure those sophomore Supply chains without compromising on their speed at which things are developed and the quality applications start with those fundamentals Adam. Thanks for being on the show.

Thanks Michael. It's a pleasure. All right back to you guys in the studio.