Transcript: DevOps Decrypted Ep. 7 - Value Streams and Vulnerabilities

Romy Greenfield:
Happy year, everybody. And welcome to DevOps Decrypted. This is episode seven, value streams and vulnerabilities. I'm your host Romy Greenfield. And joining me today, I have Jobin and Matt. Say hi guys.

Matt Saunders:
Hi guys.

Jobin Kuruvilla:
Hello. Happy New Year.

Romy Greenfield:
Happy New Year to everyone.

Matt Saunders:
Happy New Year. Happy third 20 20.

Romy Greenfield:
Yeah. Again.

Romy Greenfield:
I can't contain my excitement.

Jobin Kuruvilla:
Locked up in a room, yeah.

Romy Greenfield:
Cool. So today we've got an exciting topic for you. We're going to talk about the Log4j vulnerability that took over the internet for a good while and made so many good memes. I think there is actually a site with lots of memes, all related to the Log4j vulnerability. If you haven't seen it, please go. It's great.

Matt Saunders:
I wonder if the meme sites feel vulnerable to the Log4j exploit? No, sorry. I'm getting way too met, way too early in the year, way too early in the podcast for those sort of thoughts.

Romy Greenfield:
Do you guys think there is still cause for concern over the Log4j vulnerability, do you think people have got over it now, patched everything that they possibly can?

Jobin Kuruvilla:
I don't know if I'll call the whole thing exciting or not because it came at the very, very wrong time, just before the start of holidays, I believe.

Romy Greenfield:
Yeah. Log4j waits for no one.

Jobin Kuruvilla:
Oh yeah. Yeah.

Matt Saunders:
Timing was terrible. Yeah. When you're mobilizing people to go off and fix things, but that's the way it goes sometimes. These things don't happen in ideal cadence. We used to talk about things like we're going to do a code freeze over Christmas and New Year because that's the way that did things prior to DevOps happening and people getting comfortable with 10 releases a day. And I think anyone in that position, where you have something drop like that, where you people have gone off on holiday and they're standing down, getting ready for Christmas or whatever celebrations you're having over that at time. And you're not allowed to touch systems and yet wait a minute, what's this? Yeah. A horrible, horrible exploit.

Matt Saunders:
Which just got worse the more you looked at it. So to come back to your question Romy, should we still be scared of it? Yeah. So I love security and I really hate security because finding out about things like, oh, you've been hacked is a really... is going to be a really bad day for someone. Finding out that there's something going on that could be just dormant. It's still there or maybe you don't even know it's there, you haven't fixed it, you don't realize you need to fix it. That's horrible, that's scary. There should be a Halloween episode, really, shouldn't it?

Romy Greenfield:
It really should. You're just doing the classic script of a horror movie right now. You don't know it's there, you don't know what damage it's doing.

Matt Saunders:
Exactly.

Romy Greenfield:
You don't even know you have a problem.

Jobin Kuruvilla:
But this particular one, the vulnerability that we are talking about that one is at site. I mean the newer versions of Log4, it resolves that problem so as long as you upgraded, your application to include the new versions of Log4j everything is good and back to normal you're going back to the holidays. But you're right, we don't know what else is there right. There could be other vulnerabilities hidden somewhere in our cord system. The biggest problem that we have seen over the last few years is we've started using third party softwares right. Whether it is Log4j or something else there's all... I was wondering, do you know any Java application that doesn't use a Log4j? Very unlikely. So everybody is using it and you don't know what else is in this. Maybe tomorrow or something new comes in and that fear always going to be there right.

Matt Saunders:
Yeah. And so just to expand on what I meant. You're absolutely right, that there's going to be another one. I'm still scared that we haven't found all of the places where this thing is. Because it's a library that's just so widely used. I was doing a bit of research in classic maps on style, do some research 10 minutes before the podcast recording was going to go ahead and I suddenly realized, "Oh my God. I've got a Minecraft server that I run for my kids," and that's going to have a Log4j in it. And it's not just that, if you're in a DevOps environment, you're thinking about all the software that you run, oh yeah. You might be running something on the slide for your family to enjoy and you need to make sure that's patched.

Matt Saunders:
But just the thought that's a vulnerability of this scale and fairly unprecedented stuff where you can do remote execution from something that seems to be benign, like a logging engine, is maybe unprecedented. And, it's that aspect that really scares me. Let alone the stuff that Jobin's been talking about, which is like, what's the next one going to be. How widespread is that going to be that we can't actually really imagine what it would be like. So yeah, I'm going to.

Jobin Kuruvilla:
But I think-

Matt Saunders:
October 31st because it's scary. Go on Jobin.

Jobin Kuruvilla:
I think it also talks about the importance of DevOps, doesn't it? Because if you are a company who has got your DevOps process figured out, it would've been much, much easier for you to know [inaudible 00:06:05] this one and roll it out into production, right. You have your CA you have your CD, appropriate branching strategies. So you make sure you cut a branch, fits the Log for the version. Push it into a master and then push it into production. What were your DevOps processes if you had it figured out it would've been much, much easier for you to fix it into production.

Jobin Kuruvilla:
Remember those days when we had to wait for maybe a week, maybe six weeks before you can get the approval to push something into production. What happens then, you find a vulnerable day, but you still cannot push it into production because it takes so long for the delivery cycle. And you know the vulnerability is there, that's scarier, isn't it?

Matt Saunders:
Yeah. Yeah. And for all. Yeah. It's massively scary. And I'm relieved that if you look at contemporary implementations of CI, build systems, they're doing things like analyzing or they can do things like analyzing that whole third party supply chain that you mentioned a couple of minutes ago, Jobin. And knowing that if you're using this, so and so dependency, then that's using something else's dependency, which is using something else's dependency and underneath it somewhere, there's a Log4j. And highlighting that maybe either the version of Log4j that you've pinned in your system is too old and is vulnerable or some third party library, further up the stack or further down the turtles, the production minded of us is also vulnerable.

Matt Saunders:
And yeah. So seeing the work that's been done, I would say relatively recently, so the last two or three years around understanding that open source software and open source libraries are great and fundamentally underpinning all the stuff that we run and let that be the overriding thing here, because I don't want anyone to think that I'm bashing open source software because it's one of the greatest creations in the entire universe. But the fact that prophecacy of it and the amount of it there is out there and the amount of abstractions that are being used means that you can't possibly know every single thing that you're running. Every single.

Jobin Kuruvilla:
Yeah. It's even worse than the world of containerization right. Because right earlier you had to worry about only the individual pieces of software that you're pulling in. Now you're using, starting from a base image, you don't even really know what cycle is on the base image right. It's okay if you're starting from the base image of

Romy Greenfield:
Yeah. And I guess if there's an image that's really popular, you put your trust in the fact that so many other people have trusted it but how many of those people have actually dug into what is in it and have actually checked.

Jobin Kuruvilla:
Same thing right. Nobody does it, but that makes the vulnerability scanning, again more and more important in today's world, right?

Romy Greenfield:
Yeah.

Matt Saunders:
Yeah. I think it's great that that containerization has always had this kind of all year, but you don't really know what's going in your image. It's great. You can pull down doca.com/jboss or whatever. Sorry, I sounded like someone from three decades ago, you can pull down something what's in it. So that would, it would be even more terrifying if there hadn't then been a subset of the industry, which is now innovating in that area. People like Sneak and Encor, those people who are putting together systems that basically they built business cases around or business models around the fact that people don't know what's going into their images.

Matt Saunders:
We've seen the uptake of container technology in general, slow down because of this sort of stuff. And now there's a mitigation for it. And finally those birds coming home to roost, it's brilliant. That tech is now saving our skins because we are getting more extracted. Things are getting... it's not simple. Software is feignishly complicated and with massive amounts of dependencies. We're now in a position where we absolutely need these tools to find these sort of things. And this is the payoff for them when something like this hits.

Jobin Kuruvilla:
Yeah. But if you ask and can we completely stop it, probably not. But can we identify it and probably fix it sooner we can, we can right. Absolutely.

Romy Greenfield:
Yeah. And I guess it is preparing yourself to be able to update things easily, not having things so hard coded that if you try and update one dependency, it's going to take you months and everything's going to fall over. Is there anything else that you guys think people could put in place if something similar to this happened in again, to make their lives easier and protect themselves for the future?

Matt Saunders:
So that's a great question Romy, and I would say there's a psychological aspect here or even like an organizational typography aspect here. Not typography type, that's fonts. An organizational responsibility here where you can run your organization in a way where you put controls in, you put tests in so that you don't have funding tests or you don't have software released with vulnerabilities. Is that a realistic expectation? I think it's a good opportunity for organizations to look and see, basically debunk that. You can go a certain degree, you can go a certain way along the road of a hundred percent no vulnerabilities. But you can't get there.

Matt Saunders:
Do you stop out when you are at 99% known vulnerabilities because there's all the ones that you don't know about, of course. Things that keep me awake at night and furthermore, do you go to the extent of saying, well, we're probably going to actually end up releasing software with vulnerabilities in it. We better damn well be in a position so that when we find those vulnerabilities, we can fix them quickly, as you say, Jobin. And further, we are not going to be hacked. You're probably going to get hacked at some point, if you're running any sort of system that's in any sort of widespread use and attracts attention. Especially if there's money concerned.

Matt Saunders:
Can you put in everything you need to mitigate that actually happening. God forbid that it does. And adjust the lens a little bit, just to make sure that you're not setting yourself unable expectations or worse putting in some system that you think going to protect you from all this stuff. And even with the best one in the world, it doesn't quite do it for you because something new and unprecedented happens like the Log4j thing.

Romy Greenfield:
Yeah. And I suppose if you put all your eggs in one basket and that doesn't work, then you've got one single point of failure. So maybe protecting yourself by putting various different systems that might pick up on something in place.

Matt Saunders:
Yeah. Yeah. You have multiple gates. Multiple things doing the same thing so you don't have single points of failure. But much more importantly and with my classic DevOps hat on, the ability to react quickly, the ability to fix it fast without politics, without dogma and just eyes on the prize, get the new release out patch the thing, destroy the service that we might have been hacked or that you're worried about, recreate them. All those good old DevOps practices come back and start to help you win again.

Jobin Kuruvilla:
Yeah. Yeah. I think I'd like the message be prepared to be hacked, right?

Matt Saunders:
Yeah. Come on, bring it on.

Romy Greenfield:
It's a scary world we live in.

Matt Saunders:
It is. It is .

Jobin Kuruvilla:
It is.

Romy Greenfield:
We can talk about the one thing DevOps engineers aren't doing today that they probably should be getting rid of any Log4j vulnerabilities. That's one thing they should be doing.

Matt Saunders:
Oh no. Now the DevOps have been painted as the janitors of the system. This is no good. So yeah. So once you finish being busy, upgrading every single Log4j, you've got on every single dependency then and it's time to rest. It was the seventh day... No. In seriousness. Yeah. I thought about this for a while when we proposed this as a topic a couple of weeks ago, what's the one thing. And I would say the one thing DevOps engineers can do better is, well actually I'm going to pick apart DevOps engineer first because that's a term that I don't much like. I think it causes a load of problems while solving a load.

Matt Saunders:
But let's put that aside. That's another topic for a future podcast. Let's just say people are working in DevOps, people who are doing DevOpsy type things. And the one thing I would say, I would go heavily cultural with this is that thing that you are doing, who are you doing it for? Why are you doing it? Pick up the phone, go and speak to the person you're doing it for. Talk to them. Is it working for them, does it actually make sense, could we make it better. If it's something you're doing over and over again, could we write a system to do it? Do we lose a load of nuance by putting it in a system or does it really need you to do it for them?

Matt Saunders:
Speak to them like work out, are you actually helping them to deliver their best work or is what you are doing actually just a waste of time. It probably isn't, you're probably doing it for a very valid reason and maybe you have a chat and you speak to the person whoever you're communicating with every now and again, and everyone's happy in which case, well, you can just pass the time and talk about the counties of England or something like that.

Jobin Kuruvilla:
But isn't that value stream management, right? Isn't that what we call value stream management?. So basically what you want to do is understand where the value is and reduce the waste.

Matt Saunders:
Yeah, yeah, absolutely. And maybe there's an implication that, oh, you're not doing that. You're not working out where the waste is and where the value is. I find myself accidentally auto piloting through many, many situations where you're doing something, you've done it before, you're doing it again for somebody, it looks kind of the same. Maybe it's setting up some infrastructure, maybe it's setting up a VPC and some subnets. Maybe it's provisioning an application onto Kubernetes cluster. Especially that stuff you do over and over again. You looking like you're adding the value in the same way every single time.

Matt Saunders:
When I was listening to The Idealcast over the weekend podcast from Gene Kim and he was talking to John Willis. So basically two massive heavy hitters in the DevOps world. People who, what we just look up to as being like the gods of this industry. And they're talking about the differences between physical manufacturing, so the likes of Toyota building cars and the value stream that's delivered there. And the difference between that and the knowledge work that we do. So we are delivering software, we're delivering solutions for people and adding value in ways that change a lot faster and a lot more readily than the old physical world.

Matt Saunders:
Toyota changed their processes because this is a massive trivialization, the move over from doing petrol to electric cars, big change obviously. We are making changes like that all of the time because we're using software and there's much shorter lead times to changing things. And so the long of the short of that is that the way that we do things gets out of date very, very quickly, just as soon as you establish a process. And so, yeah, I find myself doing something for the seven for eighth time, maybe. Not obvious stuff that I could have automated, but maybe a process that's partly technical and partly process driven.

Matt Saunders:
And then going, "Well, hang on, actually. Yeah. Is this actually right? Is this still the best we can do?" And so there you go. That's why that's my one thing I think DevOps engineers can do and it's not technical thing.

Jobin Kuruvilla:
Okay. I can probably go with a technical thing then, okay.

Matt Saunders:
I hope so.

Jobin Kuruvilla:
I think a lot of the times what I've seen is, you take your pipeline, there are different stages within your pipeline. There is one simple thing that you can do somewhere in one of the stages, which could drastically reduce the time the pipeline actually takes to build, right. You probably wouldn't even think, or this is such a small change, it reduced my time from maybe eight minutes to two minutes, right. I have seen this happen so many times. It could be very many different things. I'll give you very simple example, take cloning for example, right you have this massive key repository, which has got years of history behind it. So somebody comes in, a DevOps engineer, comes in, pulls the cord down, starts building on it and creates the artifact and deploys it, that's all great.

Jobin Kuruvilla:
But the cloning probably takes 30 minutes because the repository is so huge. And maybe it is pulling from Europe somewhere and you are sitting in North America or in India right. And it could be taking eight minutes instead of three minutes, that's okay. But just by changing that cloning process to a shallow clone instead of cloning the entire repository, that could bring down the time for the actual clone to maybe a minute or less, right. So small improvements like that could potentially bring down the actual build time from eight minutes to two minutes. Think about the build time over the period of time, over a week, over a month. You're bringing build times from 3,000 hours back to 300 hours.

Jobin Kuruvilla:
That could huge, huge, right. It doesn't have to be cloning. It could be anything else, maybe pulling down a darker image from the internet versus pulling it down from your local repository right. That could save you a lot of time. So there are those small improvements that you can make within your pipeline, which could potentially save you hours over the period of time.

Matt Saunders:
That's massively valid. Yeah. And there's another aspect to it, which again came from The Idealcast which I was listening to over the weekend where I think it was actually Patrick Debois was talking about again, another godfather of DevOps, talking about how in the context of flow, having something you have to do that you have to wait for that takes more than a couple of minutes doesn't just waste some of your time but as human beings, if something's going to take more than a couple of minutes, you're going to go off and do something else. Not necessarily go off and make a tea or take the dog for a walk, but you'll out tab. You'll flick to something else. You'll go to another window, browse the news or catch up on slack or whatever.

Matt Saunders:
And what you don't realize is the horrific effect that actually has on your productivity. Because maybe you forget that you'd set this gig clone or off and you come back to it. And even if you haven't forgotten, you've just context switched half of what you were doing out your brain and it's evil... I believe it's kind of evil to say, "Well, you should just sit there waiting for it," that doesn't make for happy developers. And so the reality is yes, when you add up all those two minutes, multiply about a hundred builds over seven developers, you save a big number. My maths is not a strong point.

Matt Saunders:
But there's also that thing about flow and just being able to do a task and concentrate on it and focus on it and have things happen and get your feedback loops in a reasonable amount of time is absolutely unquantifiable. It's an unquantifiable benefit. It's huge.

Jobin Kuruvilla:
Yeah. It reminds me of all the coffee breaks that we used to take when maven is downloading the world right. You'd [inaudible 00:23:40] still and it's downloading all those dependencies into your local repository, that's going to take forever in the first time. That's when you go for a coffee.

Matt Saunders:
Right yeah, exactly. And, you look at a lot of the advancements that we've made that just look trivial. Things like going from virtual machines to doing things like running Solaris Zones 20 years ago, where you now have to wait 15 minutes for a virtual machine to start to run something new on, you can just get it, boom, there it is within two seconds. And again, when you move up into containers, having these things instantly start up having caches so you don't have to wait for maven to download the entire internet.

Matt Saunders:
Again, it just looks like us tweaking things and saying, oh, we can make this really, really fast, isn't that great. But the effect of all those things cumulatively cannot be understated.

Romy Greenfield:
Excellent. So you guys mentioned value stream management in things DevOps related people could be doing that they aren't doing. So that brings us nicely onto the fact that we've released an ebook about value stream management. Woo. So who would this ebook be good for? Who should be going and getting this ebook and having a good read?

Jobin Kuruvilla:
Value stream management, it's a loaded term. But it is something that you could be doing today every day, right. Maybe not at the company level, maybe in your team level, it's all about finding where the value lies and where the base is and spending all your energy in finding that value. Right Matt?

Matt Saunders:
Yeah. It's a bit of a cliche to say who should be looking at it, well everyone. But in this case, I think it's warranted. I would encourage anyone who's looking at what they do in a business, be it developers, operations people, networks, products, services people, marketing, et cetera. You'd be looking at what you think your job is. And oftentimes you'll find, and I don't mean this derogatory, you'll find a relatively narrow definition that we come up with where for example, developer's job is to write some code that becomes a compiled thing that someone runs somewhere and take a step back from it and look at what the actual value is. So the value you, you are delivering as a developer is a little bit masked.

Matt Saunders:
Ultimately what you are doing is part of a chain of things that result in some value being delivered to someone, whether that's an end user customer, whether that's an internal person. Perhaps you're writing a tool that lets you do holiday requests or something like that. So, it doesn't have to be necessarily an external thing. And again, there's something in it for everyone. I like it particularly value stream mapping, value stream management, because I believe it goes in hand glove with DevOps, where if you look at the more traditional definitions of DevOps, it's looking at, how do you get those feedback loops going, how do you look at how things are flowing through your system.

Matt Saunders:
And systems thinking being a bigger thing than just your little bit of your world that you're dealing with maybe in a large organization. And it's as simple as that really. Just projecting yourself slightly outside of, not necessarily outside of your comfort zone but it might be a little bit uncomfortable, but outside of the world that you are working to look at a bigger picture. And so that's why I think everyone should be interested in it.

Jobin Kuruvilla:
And it is also interesting when you start doing value stream management, you will realize that some of the minor adjustments that we make can increase value drastically, or everybody who is a developer has done this. There are small features that you spend hours and hours developing and at the end, it is only just offering very little value to the customer. But then there are some features which is like maybe an hour job, 10 minutes job, a small improvement that ma that you can make on the user interface, which then potentially improves the user experience by a huge mile right.

Jobin Kuruvilla:
So those kind of small improvements, if it increases the value by much, you should be doing that today. I think that's why value stream management is important because when teams get together and figure out where the value lies and what are the kind of things we should be prioritizing that improves that experience for the customer drastically.

Matt Saunders:
Yeah. We're back to those small improvements again. It's massive and I think the key thing for me is understanding the context around which things to make the small improvement on is huge because once you take a step backwards and you put a lens on, all of the things that you are running and working out which ones are used regularly, which ones aren't, which ones are really being used by, by customers and where you can make their lives better without just saying, oh, just make everything for the customer. Putting some science behind that, measuring things properly, it can be really, really enlightening and motivating as well. I've been stuck in jobs in the past where I'm doing I'm doing some work and it seems like again, it's a very well defined process.

Matt Saunders:
I know why I'm doing it, but only within the lens of my own little world. And, and so, yeah, I think it's a critical thing to have management buy-in from this where you're encouraging people to look outside of their own little bits and pieces. So you can see that, well, yeah, you can make an improvement over here, but what actual real world value does it actually deliver. Does it actually benefit someone to a measurable degree further down the line or not. And-

Jobin Kuruvilla:
That's good point. So on that token, would you say that every company should be starting their digital transformation journey by doing a value stream mapping exercise and figure out where the value is?

Matt Saunders:
Yeah. Because at the end of the day, I think if you're looking at transformation, it needs to go back to the first principles. We talk about why do people do transformations and we say things like, well, it's to make sure that your Netflix are not blockbuster. And those are things that aren't really technical, they're about running businesses and working out what you are selling to people. How do you sell things to people that they want to buy that are software and continually improve them, make those customers happy. Sell to more customers, make sure they don't churn, make sure they renew those not technical things. And yet we put in all this technology sometimes without, well, sometimes losing sight of that and the ESM great technique for joining it all together.

Jobin Kuruvilla:
Can I also use this time to shamelessly plug that Adaptavist does do value stream management exercises with our customers?

Romy Greenfield:
Yes you may.

Matt Saunders:
Sure. You can plug it.

Jobin Kuruvilla:
It's a very interesting topic, very dear to my heart. Yeah. We also do something called the DevOps maturity assessment where we go to the customers and assess the current maturity of the organization in terms of DevOps processes and touching all the three golden tiers, the people, the process and the tools. But it'll be very nice to have value mapping exercise alongside it so you could actually see where the value is and how you can adjust your entire processes to bring that value out instead of spending all the time and energy and focus on producing some waste right.

Matt Saunders:
Yeah. Go along, adapters can help you with that. But we don't have to.

Romy Greenfield:
Great opportunity.

Matt Saunders:
Yeah. One of the most intriguing things I saw about value stream mapping was so... I'm not sure if we mentioned this on this podcast, but there's another podcast called Team Titans that Ryan Spilken does for Adaptavist and we talked to Steve Pereira, who is the... He labels himself the value stream guy. He works a lot in that area and dedicating his life to it. He's got a book coming out on it and everything. And one of the things that he says, which I found was absolutely profound, was that if you just get started on value stream mapping, you just start measuring things like how long does it take something to happen.

Matt Saunders:
And by something, I mean, delivering some value, so not just how long does the process take to one another box. To start measuring that most companies find that it improves just because you started measuring it and you made people aware that this is a thing. And then when you really want to improve it, then you go ahead and find Jobin.

Jobin Kuruvilla:
Not a bad idea. But going back to the ebook, obviously it touches on a lot of the points that we discussed today, right. It talks about finding value in your DevOps pipeline. It tells why value stream management is so important, the benefits of doing a value stream management, how we can unlock more value by hiring Adaptavist and so on and so forth. So great ebook right?

Matt Saunders:
Absolutely. Yeah. We both contributed to it. So we're not biased at all.

Jobin Kuruvilla:
I'm not taking all the credit.

Romy Greenfield:
Yeah. You can share it 50 50. And I think you can download it from our website as well. I think it's available now for free so please go and download it, if anyone is interested. There's lots of tools available that can help you with value stream management. And we are partnered with one company called Plandek and we've been lucky enough to have an interview with the COO, Will Lytle on value stream management. So here it is. Okay. So today we are joined by Will Lytle who is the COO, almost said CEO there, COO of Plandek. So let's find out a little bit more about Plandek. So what is Plandek?

Will Lytle:
Well. It's a pleasure to be here. Thanks for having me along. So Plandek is a SaaS analytics platform, which looks across a variety of different tools that engineering teams use, product teams use to deliver software. And so some people I think can best equate it with almost like a Google analytics for software delivery. We hook into the workflow tools such as Jira and Azure. We look at repositories and we look in your pipeline CI/CD tools to be able to do two things. One is to provide a central place where organizations from the C-suite all the way down to the team level and particularly focused on the team level, can really understand and interrogate what their end to end delivery process looks like. From ideation all the way through to deployment to production.

Will Lytle:
And the other element is that we're constantly challenging ourselves with here at Plandek is how do we cross reference data from these different tools to further enhance value that the insights can provide the teams and the organizations that use Plandek. So for example, being able to follow tickets all the way through a system like Jira and even if it's closed, you can continue to track the life cycle of that ticket as it moves through different testing processes, repositories and pipelines that eventually deployed into production. So really finding useful ways of bringing that data together, cross referencing it and finding new unique ways for teams to drill into their delivery process in ways that historically they haven't been able to or at least it's required a tremendous amount of Excel work.

Romy Greenfield:
So where did the idea come from? How did you join the company, and...

Will Lytle:
Yes. So Plandek started its infancy... It was actually born out of a software delivery company. And like many of our clients, the company that preceded Plandek had some questions around, how are we delivering software, are we even good at this, what are we bad at, what we improve and so on. And back then they were using, as many teams were back in the day, Excel spreadsheets. Downloading CSV files from Jira and pulling a bunch of data together and trying to see what they can learn from it and thinking, okay, well, there's got to be a place for a product that does all of this for you. And so that was the infancy of Plandek.

Will Lytle:
And it's grown over a couple major iterations over the last couple of years. We have a number of clients globally that use it a number of different sectors. But yeah, it was really born out of the idea that it's trying to solve and still to this day is, from a product strategy and, and engineering perspective, developed by the same people who were dying to have a tool like this in the first place. So there's a real strong feedback loop, not only from our clients, but also from our actual engineers in how they use it, the value they get out it, what they put back into the tool for our clients.

Matt Saunders:
I think that buzzword there is... Sorry, go on Jobin. Go on.

Jobin Kuruvilla:
No, that's great. I can instantly see the value in there Will, because DevOps probably is not the fancy word in town anymore, but value stream management is. And Matt, when we were talking about the transfer 2022, great place in there, probably up there on the list. So I can see how Plandek is probably helping companies adopt because one of the challenges had been you can't really see what is happening across your enter tool set. And I can see how Plandek is helping with that. Is it really your USP or are you trying to achieve something more than that or is that the main thing?

Will Lytle:
Our strategy as a small business over the years has always been really focused very deep in the SDLC process, right. Be able to cover that ideation to production space of value stream management, and to really focus our efforts on delivering insights within that space. As we look forward as a business, the next couple of years, there are two areas in where we're going to be progressing. One very imminently in a new product that we're launching in the next couple of months is going to be taking all of that data that's coming from this system on a real time basis and almost flipping things on its head.

Will Lytle:
So rather than people coming to Plandek, looking through a variety of different charting technologies and seeing how are we trending in this area, in this area. It actually is going to be a proactive stream of listen in this particular sprint, here's what you're working on. Here's what anomalies are happening in the data you. Is born from a basic fact that our customers are busy, right. The team leads, scrum masters, the teams are very busy. They don't have the luxury sometimes of taking a step back and really putting the intellectual effort into thinking about the data.

Will Lytle:
So we wanted to provide an element to the product that did the thinking for you, right. So you wake up in the morning, you have a cup of tea or you have a cup of coffee and you say, "Okay, Plandek, what do I need to worry about today, what's going wrong?" and it surfaces things that, for instance, this poll request hasn't been sorted yet, or this story has a disproportionate amount of lines changed for a normal eight point story. So it starts to flag either risks or specific alerts in what the team is working on, that's going to help you meet that end goal, whether it's a sprint or an epic or something of that nature.

Will Lytle:
It's taking all of that data that we're pulling through together and doing a lot more proactive analysis so that we can help teams navigate some of the delivery challenges that they have and really find the answers in a much faster, effective way. The second area that the product is going to develop, I think over the next couple of years, and you'll see this quite predominantly is extending broadly more broadly out across value stream management. So there's a lot of great tools in the market today that are doing more business strategy and portfolio alignment, which we'd like to bring in and include in that conversation.

Will Lytle:
There's obviously the IT operations side of things and cybersecurity side of things, which we'll have something to say about in the upcoming months. And then lastly the big question is what about value realization. What is all of this actually generating in terms of improved NPS scoring or the results on revenues or so on and so forth? So, we're not necessarily there to be a massive data lake of all information across to your business. That's not the market we're trying to target. I think for us, it's still... Our DNA is still about engineering delivery within the context of value stream management. But what we want to be able to do is to be able to tie the strategy with the realization a little bit more tightly in that particular context.

Will Lytle:
So that people can kind of see some of the tight correlations that we know exist in the data, but just aren't always able to flush out. We know that for instance, looking at there is a tight correlation between cycle time and NPS scoring, we know that there's correlation between NPS scoring and revenues, right. So to be able to bring that picture together in a much more direct way, I think, increases the value that Plandek can offer to our clients organizations.

Jobin Kuruvilla:
I just want to clarify one more thing. So when you say, definitely in the morning coming with a cup of coffee, I want to see what is going wrong and where I need to pay my attention, that's really great. Obviously that brings a lot of value to the engineering teams, but just want to clarify that it also tells me over the span of six months or one year, this is what your cycle time is, this is what an average of your cycle time is. Plandek does set too, right?

Will Lytle:
Oh, a hundred percent. That is what Plandek is today, first and foremost. It is a historical trending tool that helps you analyze exactly how well you've been delivering over a period of time, what improvements you've made, where things have dropped off, why that's happened, what you can do to add some change about that. We just want to turn that on its head a little bit and have Plandek also be able to offer you more of a forward looking risk management element tool as well. You're aware of the risks that we need to be aware of and concerned about, what can we best spend our time doing this morning.

Will Lytle:
That I think will have a big role to play in standups, right. If you can give people a couple meaningful things to bring into a standup say, okay, where's this, where's this, where's this. You can already see how that's going to be transformational for a lot of teams.

Jobin Kuruvilla:
Awesome.

Matt Saunders:
Yeah. I can see how, the thing about not wanting to be like the massive data lake is a benefit because I guess it's not easy, but relatively straightforward to collect a whole load of data out of these tools. But the big thing is finding out the bits that are actually important. And I guess once you've got a number of people using this, you can start to see those trends right. And see really what the two or three things that are really good data driven indicators of success. Would that be kind of true, yeah?

Will Lytle:
Yeah, it is true. And I think with the data lake concept in the BI area, those are particularly well serviced areas of the market. I'm not going to plug any brands on this podcast, but we all know the big players in the BI space out there and they're particularly. So we're not necessarily interested strategically in going to that space. Again, our DNA is particularly with engineers and so we want to help them understand how those trends are looking, what they can do about it.

Will Lytle:
And then also start to bring a little bit more referenceability across our client base as well so that people can get a good indication, as and where appropriate of how do they compare to similar teams working on similar technology stacks with similar constraints, when it comes to things like your deployment frequency and your lead time and your cycle time. How do we sit against our competitors, how do we sit against the market.

Matt Saunders:
Great. Are there any particular constraints that come up frequently? Well, I don't know if you're allowed to talk about.

Will Lytle:
Yeah, yeah, yeah.

Matt Saunders:
Constraints that people maybe artificially put on themselves or have put upon them that cause particular problems that Plandek highlights?

Will Lytle:
You talking from a metrics perspective or generally just going in?

Matt Saunders:
Yeah.

Will Lytle:
Yeah. The first phase of most of our customer engagements is getting to know your own data and getting to know what you can learn about your own data. Which is kind of a cheeky answer to that question. But I'll elaborate a little bit more in the sense that clients have a pretty clear view, for the most part, of the headline metrics that they want. We want to be able to measure our lead time. We want to know how long it takes from idea to production. And it's no surprise, it's a kind of a well known, probably the most well known indicator in agile delivery. The first phase that they learn, it's not necessarily a constraint, but they learn a lot about how they deliver software and whether or not the way that they deliver software, enables them to get the most robust view of that.

Will Lytle:
And, the easiest comparison I have that in some ways is we've seen some clients where the data's quite simplified and therefore the first insights that they get are quite limited simply because they've got various streamlined workflows. And so they start to then build a case in their own minds where we don't want to add more statuses for the sake of adding statuses, but hey, if we added a couple more things that would help us understand a little bit more how do we connect and how do we collaborate between development and a QA process or how do we hand over from a design into a development process. So connecting of these dots, they're not necessarily constraints that they put themselves under. But I think a lot of teams are...

Will Lytle:
Other clients that we work with are just starting to really think about data and as such, that are starting to think about data points and all of the... Your workflow, the events in your Jira and your Azure, all of this, those represent points, events that in the day that you'd never think about like that. So in some ways it allows them because start to think about how they work in a way that enables them to get better feedback on it. We see a lot of common constraints just generally from methodology, in terms of what impact kanban has on particular statistics, what impact scrum has on particular statistics. What trade offs are what from a data perspective.

Will Lytle:
So for instance, if you're trying to optimize your lead time as a scrum organization, well, we know that one of the great benefits of scrum is that it allows you to time box and structure your delivery and internally and externally communicable bunches, right. Whereas kanban allows and optimizes the continual flow of work. But of course, part of the scrum methodology, you've got these starts and stops every, roughly two weeks, sometimes three weeks, which then adds a little bit of an additional time as things are queuing up between a design and actual development process. So you're making certain sacrifices for that.

Will Lytle:
So they're not necessarily overall constraints, but things that teams are starting to be more well aware of and thinking about actually, why do we do kanban and why do we do sprints and what is the value of doing these things and then that then starts a conversation, right. Well, how do we measure that. So I think one of the things that we see in a lot of clients is a evolution of understanding of the objectives of their agile delivery. What are we actually trying to accomplish and what are the, but what are the key results they're trying to measure. What are the outcomes that they're trying to realize as part of that continual improvement initiative.

Will Lytle:
And that's where Plandek sits, just to help them think through, articulate and then measure those key results and outcomes.

Matt Saunders:
That's awesome. Especially when you start to get into being able to judge which methodologies are going to work for you, because so often you're working teams who are working either in a scrum fashion, maybe doing sprints, maybe doing kanbans and you're like, well, why are you doing it that way. Yeah. It seemed like the right thing to do. And yeah. Actually put me some numbers around that feels really, really powerful. That's cool.

Jobin Kuruvilla:
Yeah. Now you have the data to support the thinking or maybe contradict what you're thinking right.

Will Lytle:
It's good. It really forces people to think in a slightly different way about methodology, what's useful, why it's useful and how to measure it. I think maybe just speak to one of the constraint questions you asked or one of the things that we see a lot with scrum teams is just basic execution of the scrum methodology as it relates to sprints. So basics around planning, starting a sprint, closing a sprint, and the retro helps... We think Plandek helps a lot of it. Even the feedback we do get is that Plandek helps them to rethink and restructure just the fundamentals about delivering sprint in order to become more consistent or reliable in terms of what they're delivering as part of their sprint targets for instance.

Jobin Kuruvilla:
So Will, that all make sense. And I, I think there's already a good list of top players in the market with whom Plandek integrates very well. If there is a product out there that's not yet integrated with Plandek, so how easy see is it to integrate that? Does it take a long time to integrate it with Plandek or is it fairly easy?

Will Lytle:
It's a good question, quite a broad question. The way that we conceive, if it's a tool out there that fits with an existing type of data that we're dealing with, so say a new CI/CD tool, because we already have the facility to ingest process and present data related to your CI/CD processes. So if we're looking at a new tool out there, say reasonably short period of time, I feel like I'm going to get calls now from people saying, okay, great, you said you can do this in three weeks. But, it's reasonably straightforward in terms of... because the existing infrastructure is there in terms of the processing and the metrics.

Will Lytle:
If we're looking into completely new spaces, which as I said, it's something that we're doing a lot part of our strategy this year next, obviously the lead time is going to be a little bit different from that because there's a whole different conversation. It's not so much about the taxonomy of the tickets and structure of the API, it's more about actually the insights itself so what information do you need to see and then subsequent to that, part of what Plandek does... Part of the value of Plandek is that it really allows teams to customize the view. So we don't just say here's lead time, here's a chart, good luck. Know where you go.

Will Lytle:
We provide for the fundamental which you then build, you can change the issue types. You can configure it, there's a lot things you can do, which is great. But obviously that those BI functionality that presents its own different set of challenges because with every KPI we bring through, we need to think about, okay, let's take this KPI on a journey. What's the first thing you want to ask and then how would you drill into that then, what would you ask on the back of that. And then all of that starts to feed into one of the fundamental BI thing... What is the BI experience we need to be able to provide that, because again we're not trying to build a big BI tool.

Will Lytle:
But to a certain extent we want our customers, their teams, individuals, to be able to feel like they can take something off the shelf and tweak it so that it's relevant to them. Because even if you standardize all your share workflows and all your work item types guarantee, no two teams operate the exact same way. No two teams use a story or a task or a sub task the exact same way, right. Everyone has their site nuances. And so the product has to be able adopt to.

Will Lytle:
So, in terms of the integrating with brand new data sets, that's probably something we have on a roadmap, quarterly releases we do on those. But one with an existing is a bit shorter of time. But you're not going to get a firm date out of me on this. Because somebody's going to pull this up for six months from now and be like, but you said, it was normally...

Jobin Kuruvilla:
That's a great answer though, because we work with customers all the time and everybody has a different tool they're using for so it makes sense for us to know how long it going. I can see that all the major players are already integrated with Plandek, so I'm not overly concerned about that. But at the same time I had this question because there's so many players out there in the ACAC space or project management. Thank you.

Will Lytle:
Yeah, no. And we take a pretty pragmatic approach. If there's a lot of market consolidation in area, like workflow tools there's pretty high level consolidation, Jira and Azure control a big part of the market, there's all the smaller players in there as well so we look to rely on direct integrations because that simplifies things. But there's also not a huge competition. Whereas with circles, sorry... CI/CD tools, pipeline tools, there's a plethora of them, right. Between commercial and open source products, there's hundreds of them out there.

Will Lytle:
So that's where we've built APIs where you can actually push data, which allows us to minimize times which clients can come on the product much faster. So where there's more tools, we have a tendency to have a push API pattern to just bring people on board a little bit more faster and make it easier.

Jobin Kuruvilla:
Does Plandek also offer any APIs using know, inject data into Plandek.

Will Lytle:
Yeah. That's the push API. So on the CI/CD side, if you're using a tool... We have a few integrations that connect directly with some of the big name CI/CD tools in the market. But if you're using a smaller one or maybe you've customized one, we have a push API where you can send us the data directly for every deployment with a few parameters behind that and that feeds directly through to that for a lot of.

Jobin Kuruvilla:
That's perfect. Yeah. Thank you.

Romy Greenfield:
Thanks for that, Will. That was really interesting, great insights there into what Plandek does and what's coding the future. So thank you for joining us. If you are want to say, thanks.

Will Lytle:
My pleasure. Thank you for having me. Appreciate it.

Matt Saunders:
Thanks Will.

Romy Greenfield:
And then thanks from Matt and Jobin as well.

Jobin Kuruvilla:
Thanks Will.

Will Lytle:
Cheer guys. Pleasure to speak with you again.

Jobin Kuruvilla:
Thanks for it.

Romy Greenfield:
That's all for today's episode. Episode seven, value streams and vulnerabilities. Thank you very much for listening. Thanks Jobin and thanks Matt for joining us. Thank you to our guest interview, Will Lytle as well. Connect with us on socials @Adaptavist. Let us know what you think of the show. Let us know what you think about ebook and thank you all for listening and see you next time on DevOps Decrypted. Part of the Adaptavist Live podcast network.