Welcome to the 'AI in Business' podcast.

In this show we talk about how leaders and entrepreneurs can benefit from not only the implementation of AI, but also the innovation and growth in creative thinking that comes with it. At Aimegos we have seen time and time again how this growth in creativity creates results that directly impact on your bottom line—in a very positive way.

I'm your host, Lee Hopkins.

-------------------------

AiMegos (0:0.052) Today, I'm talking with Paul Glover from a company called Burendo in the UK. And we're discussing automated agile, a product that he's got up and running. So Paul, can you give us the elevator pitch about automated agile, please?

Paul Glover (0:17.590) Yeah, so automated agile is really a way of thinking and all it really is is understanding that AI can utilize, you can utilize AI throughout the product delivery lifecycle and in doing so add productivity. But there isn't really a strong understanding of how to do that all the way through. There's individual use cases which are important, but it's about leveraging that rich context to produce great outputs. So what automated agile does is think about the whole product delivery life cycle and how you can get the most out of it utilizing AI.

AiMegos (0:52.744) Okay, cool. So then if we look at the origin story of automated agile, what challenges did you have bringing it to where it is now?

Paul Glover (1:6.338) Well, I think it's about understanding for people, I think, because it moves so quickly and that's overwhelming. what automated agile doesn't try and do is say, use this tool, use this process, use this way of thinking. What it does do is come up with a way of thinking about that to understand what drives the best performance out of AI, each of these steps, and how do we create a structure that allows you to put new tools and new processes in. And I think as a concept, that's something that You know, people are kind of thinking about that on a use case specific, you know, sense. Now you see a lot of tools out there that'll solve individual problems, but in terms of a whole workflow, you know, there are limited people out there really thinking about that and helping businesses. And that's really what this is automated agile about rather than being a product. It's more around how do we help businesses understand what the next step forward is because the floor underneath them is changing at a rapid pace.

AiMegos (2:4.734) Yeah, isn't it? Yeah, absolutely. Star Trek, Star Trek, and I'm thinking the Holodeck in particular. Is there any similarity between the Holodeck and Automated Agile?

Paul Glover (2:20.622) Yeah, the holodeck theory is something I like to talk about a lot, know, and it probably rings true with like nerds and people who've watched Star Trek, but ultimately it's all about, you know, you have an idea and then you have your products. And in between those two is a lot of friction, you know, is generally why I do for a living. And then that's, you know, what the product of your life cycle is. Whereas in a holodeck in Star Trek, you walk into a room and you say, you know, give me, you know, 1920s London, and it will. And that's really how software should be. You should be able to speak to a tool and say, this is the product I want, and it shows it you straight away. And then we'll change that and update it. So in our tests that we've done utilizing a process with automated agile at its heart, we've managed to create prototypes instead of 90 minutes, 75 minutes for one type of prototype. And what that does is put something in front of a customer and give them the opportunity to. and see whether or not they want to make any changes to it. And that's what we're trying to do. That's why we call it the Holodeck theory. It's that how do we close down that friction as much as humanly possible to make the process of customer feedback and customer improvement as immediate as possible? Because the primary measure of progress is working software, right? So it's about how do we keep those phases small? and keep the question that we're asking AI to complete as simple as possible. But yet make that forward progress more rapidly than we would be able to using traditional agile methodologies.

AiMegos (3:58.822) OK, it reminds me then because of this, you know, talking to the engine rather than, you know, prompting it by typing. It's, do you remember? You probably do. A couple of years ago and up until maybe last year, there was a big push by all of the senior tech people, you know, in Silicon Valley, saying, you know, everyone will have to learn how to prompt, write prompts and code. But there was one CEO who said, no, you won't. Within 12 months, you won't have to do any of that. The AI will do it for you. And I'm guessing that's where Automated Agile is heading, is that you don't need those technical skills. You just talk to your engine, and it creates from there. Is that right? Have I got that right?

Paul Glover (4:56.942) Well, I think I'm a business analyst originally and business analysis, I think comes from the place of anybody can do it, but you hire a business analyst because they've got the skills to do it in a way which is lean and not wasteful. And I think that's all prompt engineering is for me. I think anybody could go through 30 cycles of asking some, you know, an AI to produce something and it does, and it's not quite right. or they could make sure someone has got that precision of language that when they ask it a question, you're getting a very specific answer out of back of it. you know, AI likes people who help it help itself. So I think, yes, you know, you certainly could get the prompt engineering piece to be done by AI. And at some point in the future, there will be a level of understanding of the area. So it will help somewhat with that. You're never going to get to the point where precision of language doesn't matter. So I think.

AiMegos (5:53.172) Hmm.

Paul Glover (5:54.508) you know, maybe prompts engineering will change as a methodology, but that precision is always going to be necessary.

AiMegos (6:0.158) Yeah, yeah, I mean, certainly with the work that I do, if I write a prompt, and it could be a large prompt, if I type one up, I will then ask the LLM that I'm talking with to reshape that prompt to make it tighter and more accessible to that engine. And yeah, sometimes you just look at it and go, that's a third the size of what I typed up. it works brilliantly.

Paul Glover (6:28.236) Yeah. And there's a whole industry, isn't there, around prompt tuning where, you know, you, you, you might be at a great, create a great answer from a prompt, uh, but is it token efficient? You know, and I think once we get to that point, but, uh, you know, really what we're doing is we're trying to take work away, uh, from, uh, the product delivery life cycle to reproduce that productivity. we, you know, we're seeing maybe 30%, uh, increasing productivity off the back of this kind of methodology and thinking. Um, so, you know, when you're doing that, can that into creativity really. But you know in terms of prompt engineering definitely you can utilize AI to help you with that and that's what we think across the whole product delivery lifecycle it's just how to get the most out of it. What benefit can I get right now?

AiMegos (7:13.569) That then leads me to think about context. And I'd be interested to know why context is so critical in AI in particular, in automated agile. Why does it become smarter?

Paul Glover (7:32.972) Yeah, well, it's about making sure you ask it that very specific question again. So I think in terms of automated agile, one of the key fundamentals of it is you build a series of documentation which accurately and fully describes a product. Now that would be contrary to your traditional agile methodologies which say that you can't really think, understand what you want at the beginning of a project because who does? You want to iterate once you gather customer feedback. Well, what automated agile tries to do is it creates that 100 % understanding of where your product is right now based on the information you've got right now. So you can build that product to 100 % level and get that immediate feedback. And rather than spending weeks on your document, you want to make sure that it could be done inside the call that you're having with the customer straight away. And that's where automated agile kind of flips some of these traditional methodologies on its head where documentation might not be as important as the people and the understanding in the room. the reason for that is because of all the time that you have to spend producing that documentation. It makes it a wasteful action. Whereas when you're utilizing things like AI processes, it'll produce that documentation immediately. I you can check it immediately. And then when you're asking the AI a question in the future, it's got all of this information that it utilizes alongside what you're saying to it, to then give you that better answer. So this is where some of the prompt engineering methodologies and where you're talking, you talk about single shot prompts and stuff like that. And each of those will give you an answer and that answer might save you 30%, 40 % of the work. So what automated agile tries to do is build structures of information so that instead of that 30%, we're aiming for 60 % or 70 % by giving that additional context of what we're trying to do to the AI when it produces that answer.

AiMegos (9:32.286) So then let's bring it back from a conceptual theoretical into the real world. Could you walk us through a typical day for a team that's using automated agile?

Paul Glover (9:46.626) Yeah, so I would say there's no team using automated agile right now in anger. It's at the experim...

Paul Glover - Automated Agile