PegaWorld iNspire 2024: Innovation (As Usual) Factory: From Pegathon to Production

What's a pegathon? Anybody know what's a hackathon? Who's participated in a hackathon? A couple of wow. Okay, so a hackathon. And it is where you bring folks together to solve for some problems. And it's usually kind of a one day event, and you kind of put them into a space, a safe space and say, go try, go experiment, go do something right. We took a spin on it. So we did it specifically with Pega.

So we wanted you to bring in your business problems. But Pega had to be the solution to the problem. And there was a reason we were doing that, right? We are a Pega shop. We have been for about eight years now, but Pega is still not as well known as we wanted it to be, and we had some other problems we were trying to solve too, and we're going to go into that. So the whole foundation of this is what is a Pega fan. Why would you do it? How can you be successful doing it? And then what are the results if you do it well, which I think we've done.

So the topics for today we're going to talk about the logistics okay. The planning. Why do you do this. How do you get it together. Right. So the things to do before you begin who should attend. What is success okay. If you've been in a hackathon, did you actually see your thing? Make it to production?

Did it ever go live? Did you use it? So what's success then? We'll talk about the actual prep, how we actually got the attendance at the event. We'll talk about what use cases are, and then we'll talk about actually running the event, what you do and you know what the outcomes are going to be from there. So let's talk first about planning. Probably the most critical part of it was getting it together up front. Okay. The first thing that we did is we started talking about what Pega was doing in our space, how we were making a difference.

Right ? We had a track record of success. Pega had solved some big problems for us, but we had a lot of little problems that needed solving too. So we wanted to talk about the big ones, get them out there, talk about what we had done, and then talk about how we were going to position this. The next thing, we have an enterprise value proposition like everybody does. Okay. And we had to solve for some things that exist in our enterprise. Anybody heard of limited budgets? Y'all dealing with that?

No. It's new right. What about it. Backlogs that are longer than teams. Right. And things that just keep getting added to the bottom of the list constantly and they're not getting solved for then we might have had a few legacy IT limitations. Y'all don't have that either, do you? Right. Um, we have a lot of tech debt.

We're an insurance company. We're on old stuff, right? A lot of our stuff is really old. Uh, anybody heard of life? 70. Do you know when it was invented? Yeah, you could guess. So we've got all this legacy stuff, we've got limited budgets, we've got more ask and more backlog than we can deal with, and we needed a way to solve for it. The other thing that we got up front was an executive CHAMPVA.

So for our first Pega thon, Sheila Anderson, our CIO, was our best champion, if that makes sense. She got out there, she shouted it from the rafters. She actually helped us kick it off. This year. My VP kind of stepped into that role and was the champion for us this year. But it's important because not only was she messaging it the day of, she was helping us message it ahead of time. So to the other spaces across digital services to her business peers. So to the other VP's in the business side of the house and she was important to getting it set up. Now it's interesting.

I kind of threw my teams a curve ball because I wanted to include folks that maybe you wouldn't normally include. So the first thing I'll tell you, obviously my Pega COE COE team was very active in it. Okay. But more importantly than that, I have a wonderful Pega account team wave at me. Yes, there and there and they partner with me in this. They were feet on the ground with me every step of the way. Beyond that, I have a fantastic partner in Coforge who will also wave now, who were with me every step of the way. And when I say it's important that they were there when we were setting up our teams that would participate in the event, it's important to understand that we had a Pega LSA embedded in every team. You're going to find out why that's important.

Okay. But I had feet on the ground, sitting side by side in my teams making it successful. And that's a critical component. So having the right people kind of administering and guiding is critical. The next one people forget about, because when you think about a hackathon, you're typically talking about this IT work you're going to do. But my next priority category was my business stakeholders. I need my product owners. Wave at me, guys, I've got a couple in the room with me today. I needed my operational leads.

I got some of you in the room with me today. Right? Because we needed the people that knew what the problems were. Yeah, I got one in the back. You can wave to Colin, but I needed the people who understood the business problems to understand that we could offer solutions. So they had to be key stakeholders. The other thing that we did very differently in Knox fought me on it. Oh, he did for a little bit, but I included non Pega teams. So I put in teams that were IT teams in legacy platforms.

They'd never touched Pega they didn't know what Pega was, they weren't sure Pega could do it right because they were so used to doing it their way. Um, Sean is one of my IT legacy developers who came in. Now he does some cool stuff in his space, but he's learning new things today. And we also have a Pega practice over in Northern Ireland. So we included them in it as well. And they actually flew in from Ireland. We're on on site with us, so we had a great audience of the right people in the room to make this successful. Now the thing that we did is we set up these Pega thon teams, and each team had a unique case, so it may be a little bit different from a hackathon that you might have participated in the past. We weren't all trying to solve the same problem.

We actually brought in a bunch of problems and tried to solve all of them just using different teams. All right, so what does success mean? A lot of our folks, particularly in the business, they're used to projects, right? Maybe even old waterfall stuff. We've been agile for a while. We're still perfecting it, but projects and big things take a long time, right? So one, we had to build Pega awareness about why they could do this and why they should do this. So we had to talk about Pega being low code and Pega supporting something that we call citizen development. That meant the business could do their own thing.

Right? right? We had to get the team's hands on in Pega, so we offered training and ways for them to acclimate where they weren't already accustomed to it. And then we were going to make sure that they celebrated what they did during the Pega thon. So it wasn't. I stood up and talked about this idea I had at the end of the Pega thon, and we'll talk about time frame in a minute. But at the end of the Pega thon, we spent the last hour with each of the teams actually demoing their app that they had built during the Pega thon, so they were able to share what they built. We all celebrated and cheered their success because what they had done was pretty phenomenal. So success was, I'm going to have a working prototype and I'm going to be able to share it at the end of the event.

And the cool thing was, I was going to be a business person sitting in the chair, hands on keyboard that delivered that thing. Okay, so that's kind of the the planning that we did to get the right people engaged. So let's talk about the actual prep. So the first year we did it, that was six weeks before PegaWorld. Last year we had 40 participants. We had seven use cases. The second year that was April of this year, we went up to 70 participants with eight certified use cases. Our approach was a little bit different. So now the one thing I'll tell you is that we start socializing this early.

So in January we were out beating the drums. Right. The pega.com is coming. What's a pickathon? Oh, you need to understand. Okay, let's talk about it. We actually made the tours. We went to what we call quarterly business reviews with our different pillars, the different panels of the company. And we talked about what Pega does and what Pega could do for them.

And so we talked about successes. Remember we talked early on, you know, sharing those critical successes. And we just started kind of beating the drum. We were out in the business talking to them, asking them questions about, do you have a business problem that you need us to solve? Do you have something in your backlog that's important that we haven't been able to get to? We just started planting seeds. And then we said, watch for this announcement that's coming because we may have a solution for you. We talked about the low code, the value, the ease of getting something ready quickly. Right.

And why it would be worth an investment from them. And then I've already mentioned we had a great executive sponsor. We talk it up. He talked to his peers, they talked to their business partners. So we were just messaging everywhere and it made a difference. You saw we went from 40 participants to 70. Now the lesson we learned the big thing, the reason we do this session is we want to share with you the things we learned, the things that we know we could have done better. So in the first year, if you had an idea, we took it in. So every use case that was submitted, we said , come on in, be a part of our Pega thon.

That wasn't the smartest idea okay. Because not everything can be solved by Pega in a very limited time frame. Now it can solve most everything. I will go there, but one of the things that we did the second time around, we we created a submission form and they really had to kind of document, we call it requirements. It's not requirements in the old traditional I need a project plan a mile long, but kind of some bullets. What are the things that you want to accomplish? We asked them to go ahead and identify who is going to be hands on keyboard right then. So who was going to be the owner of this application that we're going to build? We asked them to put a value statement in there.

Why do they need to do this? What's important? Why are we going to invest in this during this event? And then the other thing we asked is what's your time frame for delivery. So if this is something you need, tomorrow might not be the right fit. Right. But if it's something that we've got a few months to work on, we've got time to get it finished. So submission was important. Probably the next most important thing is what we called use case grooming.

We didn't do that first time around right. We brought in some things we never should have. And that first Pega fine. So in the use case grooming process we actually said, okay, is this a workflow? Is this something that's logical and easy and something we ought to build, you know, as case management, a component of it? We ask questions like, can Constellation actually support the UI UX that's needed for this particular scenario? Is it a low code use case? Now, if it had crazy requirements and you could kind of read between the lines sometimes, right? If it had some crazy requirements, we said, yeah, probably not.

And then would it fit the Pega timeline. So we wanted to see how big the scope was. And there were some that we actually kind of countered on. We went back and said, okay, we like your idea, but this is too much to bite off first time, right? Let's talk about an MLP or so. If y'all don't know the acronym, everybody does MVP. What do we do at Pega minimum lovable product right. So an MLP and it was important that we had this whole process. We put together a team from Coforge, from Pega, from my COE to actually look and dig into each of the use cases that were submitted.

We actually had meetings and went back to them and talked to them about the questions we had, the things that we thought we were seeing between the lines, and there were some that we did defer. There were some that we said, it's not a Pega.com Don pega.com case, but we follow back up with them because what we told them is it didn't fit a Pega.com model, but it's a Pega solution. We just need to do it after the fact. It was too big for this. So some of the things we learned first time around complex integrations. So we're data sources are not available and easy to get to, but they are mandating it. That was not a low code Pega type of case. Right. right?

And something that we knew was going to require that they flip out of App Studio into Dev Studio because this is business, we're trying to make sure they stay in App Studio. We did all the grooming, we ended up with eight out of 15 cases that we said they fit the model. So let's talk about the actual Pega thon itself. So we do this in two days. And let me clarify, it is not two full days. We do this in two half days. So on day one we spend four hours. And the first part of that day, probably about 2 to 3 hours of that is a low code workshop. We actually walk them through Uplus insurance .

Y'all heard that before. So we walk them through there and they actually build using a low code model, the same thing. So we're all sitting in the chairs building it all together, right? Um, best account team ever brought a trainer on site for me to do it. I actually had a trainer that was local that could come in and do it. So we did live training with them. We were able to interact. It went really, really well. But the one thing that we did this year that was different than the last year is we spent the last hour with them planning what they were going to do the next day, so they had learned what low code meant.

And so we said, now, based on what you've learned today, go back to your use case and let's talk about what that looks like in Pega. But we kind of used a twist this year. Anybody heard of Blueprint. So we actually use Blueprint for this. So instead of them taking their, you know, their form submission, we took them to Blueprint and said, type up, you know, the description of what your app is and we let them, you know, run the Blueprint on it and then start walking through. Are these the right steps for the process? Are these the right personas, the right data elements? So we let Blueprint kind of help guide them. Now this was in April.

I had seen the latest implementation of Blueprint at Insights in March, but we weren't ready to actually be able to do it. We weren't on the right version of 23 yet, so we weren't able to actually let them import it. That is Pega.com three, right? We're going to actually let them do that next year, but we were able to use Blueprint to take that blank screen of, I don't even know what to do, where to start. We use Blueprint to actually facilitate what the build would be, and then we use the low code training that they had had to build. So it was important. That was the lesson that we had learned from last year as well. When they did the training, and we let them leave for the day and then come back tomorrow, they were like, what's Pega? You know, they had forgotten overnight they slept.

So it was important that we went ahead and kind of carved out the time and let them learn and actually apply what they learned before they left the room. What that meant is they went out that afternoon and they talked about it some more, and they thought about it, and they dreamed about it, and they came back excited the next morning and were ready to just hit the ground running. Day two. The first three hours they spend actually in their building. Now remember we had Coforge and Pega. We had Lsas embedded in every team, but they didn't drive. They guided, they coached. So the business was the one with hands on keyboard or the non Pega team from it. They were the ones with the hands on keyboard, right?

So we were just there coaching them through it last hour of the day. We stopped. They were done developing. All eight teams were able to successfully show us their prototype from beginning to end. Talk about excited when you have let your business partners come in and in three short hours basically prototype the solution to their problem and they did it themselves. And it's something they've been waiting on forever, but we couldn't get to. So it was really a lot of fun. There was cheering I mean, the best thing about it and I didn't mention it when we were talking about stakeholders because we had done the road show that I mentioned early on, I had VP's from the business unit sitting in for the hackathon. They sat there for the training.

They sat there and watched their team members build. They were as excited as the team members were, right, because they were watching their teams be successful in a space and solve problems that they didn't know were going to be able to be solved. I've got a number of VP's that have we flipped the Pega switch, if that makes sense. They are excited, they're talking about it, they're looking for opportunities. And it all came out of a little thing called a pega.com. So lots of success. Oh yeah, there was a pop up there. We did use Blueprint. So why does it matter?

Okay. In our world, we we made the mention that we all have this thing in our enterprise called limited budgets. You know, there are dollars available in most of our companies, but they're going on the big strategic things. Right? It's hard to get to what we call kind of the business backlog. You're changing your enhancing. You're making a difference in their world. But it's not that strategic lift to the crowd or flipping on something new. GenAI it's not the big things we're focusing on with the big strategic dollars.

So we call it innovation as usual. We are. Road show this year was actually titled the Art of the possible. What could we do if we tried this? So we had twice as many use cases. We had twice as many users. Yeah, twice as many people participating. What's really cool is that from that first Pega thon, two of the use cases were in production within five months of the actual event. So we had two Pega apps built at first by the business partners go to production within five months.

We've got a third that will go to production by the end of this month. From the Pega thon this year, we'll have an additional seven cases that will be in pride by the end of the year. So we will have had ten new apps come out of a Pega.com two Pega thon events. So in about a little less than two years, um, we are rolling out our app factory. So because we want to use Blueprint, we've got to finish upgrading one of our instances to 23.1.2. Once we do that, we're actually officially communicating our app factory. What that means is the Pega is not a once a year event. We're going to have Pega thons daily. So basically you can submit a request for a use case through our App factory model.

We'll go through our governance and everything and deploy it. And you'll actually be able to build year round using App Factory. The other thing that we've learned is critical is I'm going to call it fusion development, but I think there's two models of it. So there's fusion development where we're actually having to embed a developer with the team because their idea grew, it became a little bit bigger than they could manage by themselves in App Factory. Right? Um, the other thing is sometimes the fusion is just a Coach, so we keep them hands on keyboard, but we're sitting by their side, kind of guiding and leading them through it. So we're pretty engaged, but we're not doing the actual development. But I would say we've got the full range of Coach to actually embedded developers with them, and absolutely Blueprint. If you haven't gone to the kiosk yet, if you haven't experienced, try it.

I grew up in the business. I am not it by background. I've already built three. I love it. It has helped me in so many ways dealing with customers, and it's definitely going to be foundational to what we do go forward and our Pega thon and in our app factory. So let's see key takeaways the do's and the don'ts. So I have a new boss that's in the room today . I do still need my job. So when we go to the next one you don't see that bullet.

Okay, so one of the important dues is the use case. Grooming is critical, right? Remember the first year I said we took everything? Yeah, that was stupid. Okay. A couple of the items actually were described as being something that seemed reasonable. One of them was specifically requested by our CIO because we had a gap that nobody else could fill, and I had told her Pega could do anything. So we took it on. Amy now owns it.

Thank you. Amy, I'm sorry, but, um, there were some things that we took in that we shouldn't have. Right? We've learned that, but we did deliver them. Do use Blueprint. Use it for your visioning, man. Use it all the time. You've seen enough over the last couple of days. If you haven't been using it, use it.

But we found that that made a huge difference in the success of year two as compared to year one. And then make sure that someone who is non Pega is the one building the app, because otherwise you kind of defeat the purpose of it. OK meaning you want to grow the enterprise, you want to do it the right way, and the best way to do that is to keep them with hands on keyboard right by their side, but keep them on the keyboard. So don't don't accept just any idea, even if it comes from the CIO. Okay, we should have said no. It became a monster app. The app that I'm talking about. We actually replaced something that was being done in Cherwell. Everybody know what Cherwell is a ticketing system okay.

It's being done in share. Well, and we were ending our contract with share. Well, we were moving everything else to ServiceNow, and they were just going to put this there too. There's a slight problem. There were these things like PCI and Phi and PII that were in these things. If you've used service now, you know that you can see everything, right? You can see all the tickets. And so they couldn't do that. So we were kind of called in at the last minute to solve for this.

Um, there might be 40,000 users of this system. Okay. And so we ran into problems with security. There were things like that that became the big monsters. It wasn't integrations, it was security. AD groups, controlled access, making sure that we did protect our customers, whether it was the PII or PCI or whatever. Um, so, So, you know, I've learned that it's okay to say no and to push back, even on a big request right now, if I said no to the Pega thon, would I have said no to Pega? The answer is no. I would have gone ahead and said it's not right for today, but let me get this event done and we'll do it tomorrow because Pega was the right solution for it.

It just wasn't a Pega thon case. Don't try to do it all in one day. We intentionally do two four hour days and that is because we want them to learn. We want them to kind of brainstorm. We want them to have time to go home and digest and think, right, and maybe even talk to some business colleagues about, I think I want to do this. Does this make sense? And then come back the next day fresh and build in partnership to do it all in one day? They would be exhausted. I don't think we would have the success that we've seen the two years.

And the other thing is when I say that we celebrated successes, it did not mean that the prototype was perfect, guys. It didn't mean it flowed from A to Z. Sometimes it only went from A to J, right? They didn't get quite all the way through, or maybe they didn't finish drilling out each component of each step, right? Or maybe they didn't finish the UI build. They still had some ideas about what they wanted to do, but the point was they had something functional that they didn't have when they walked in the day before. And so it didn't matter that it was perfect. It was still really great and they were so excited. I don't know how to tell you about the atmosphere in the room.

Some of I think there's a couple of us that were there, but really their excitement, they cheered on one another. They were just so excited about it. And so, you know, what we told them is it's not going to be done tomorrow when we leave, but you're going to have a good working prototype and we're going to finish it from there. So with that being said and done, that's what a Pega thon is in our space. And it has really changed how we do business as a company. We have solved business problems that literally would still be sitting in backlog, just growing old and getting dustier. What's more exciting about that is we've got business partners talking to one another saying, hey, you need to go check out Pega. That thing that's broken right now, we can fix it. And some of the things that we fixed were pretty phenomenal.

We have a process where claims triggers this event in our policyholder services department and there needs to be a reminder set. But there wasn't a process to do that. So what they would do is they would hopefully remember to put an outlook note on their calendar. Yeah. And remember to go back. Right. If they still work for the company, what happened if they left. And so what we found is that these things were just falling apart in the middle. Well, it kind of cost us money if the policy stayed in this waiver status, right?

Yeah. So somebody out here knows what I mean by waiver. So we put it on waiver of premium. And they were just sitting on waiver of premium forever. Right. So we're solving little things like that. But they had price tags guys. There was value associated with even some of the littlest of these. So anyway at this point, I think we're going to open it up for questions.

Yeah. Anybody have any questions. Or they did say please walk up to the mic. We're recording. So um, so I'm interested in doing something like this. Right. Um, but we kind of have a rigid budgeting structure and process. So how do you get enough buy in to like do the Pega thon and And then do you have to get funding to go from a prototype to a fully developed solution, or do you, you know, does the team just sort of keep running on their own? They pretty much keep running on their own.

Like I said, we may still Coach, but the team kind of stays in place. So the business unit, the built it, owns it. We do support getting it from, you know, development into production. We do the guardrail checks. We make sure it's in compliance. We keep an inventory. You know, one of the things our CEO mandated was you got to know what's being built. Shadow IT needs to go away. Right.

And this is one of the big talking points for this. You eliminate shadow it when you give them a workable process to solve a problem. They don't have to go outside the boundaries to get something else for funding. The way my contract is set up, it doesn't cost me to install another app or whatever. I've got large enough environments so that I don't have a cost in that sense. But the time is invested, I guess. You know, it's not like these employees don't have a real job. Let's be honest, okay ? They have their primary job.

They do this in addition to it. And I think where the business sponsors have bought in is that because we're saving them in efficiency and automation in lost premium that we were throwing away, right. That they see it worthwhile and investment. And like I said, I had the VP sitting in the room with us. So talk about valuable time. They were there with us. Any other questions? The application which is created by this prototype. Right.

It might not be following the, um, enterprise class structure or other design aspect for which normally like Lsas will put in place so or so later on, whether you guys would have gone and built it properly for business, keeping the scalability and the right architecture in place, or the whatever was built in prototype you put into production? Yes. So the way we do it, because we embed Lsas with the teams in the beginning, foundationally they are built according to our specs within our guardrails. Okay. If there are things that are a little bit of a reach for them, that's where our LSA will step in and help to make sure that we stay within compliance. So it's a fair call out that there is some risk there. But we built our app factory in a way that they have to stay within the guardrails. They can't get outside if the need exists to go outside for some reason, something that's not within App Studio within their control, we step in and help them with that. But yeah, what they built is what we actually end up deploying.

All right. Thank you. Yes. Excellent session, by the way. It's really good. Uh, yeah. Like, uh, my question is like, why did you choose Pega? Like, why not Java or something like that? What made you to choose Pega?

Because I want the answer. So I can talk to my supervisors or VP so that they can onboard to Pega, because we don't have a big Pega presence because of they don't understand that. So why Pega the folks that were in the room have no IT background? Okay, so if I had to do something in Java or whatever, I would have to build something at least for them to work in within some confines, right? Pega does that automatically for me. So because it's low code, because it's no code, because we've got the app factory, I can actually keep them in a sandbox that I'm governing and, you know, policing. And for that reason, it's easy for them. They don't have to be an IT person. You know, I told you I grew up in the business, I'm using it.

And Pega lets me do that so I can take developers who don't know Pega and bring them in very quickly and get them up and running. We actually didn't go out and hire Pega guys when we became a Pega shop. We took all of our existing dot net. And if you've heard of some open text processing, uh, products called case 360, execute 360. You know, that's what our skill set was at that point in time. And we literally just started teaching them Pega on the job. So the low code modules let us do that and it lets us bring in business that couldn't do it otherwise. So that's that's the messaging Y Pega Pega facilitates it where other programs just don't, you know, you have to know Java you have to know how to code. And they don't know that.

So you have everything in Cloud. Yes, we are Cloud. Okay. Got it. Yeah, we're. Fully Pega Cloud. Thank you so much. Yeah. No problem.

Any other questions? Thank you. Great session. Um. Did you. I know you said Blueprint, but did you encourage use of AI at all or is there limitations on that, or is it maybe a future thing, but just curious where you went with that? So it's a great question. I would say there is more AI coming, but we do limit it right now. So Aflac is early and adoption still getting a good, you know, keep me honest here.

Getting a good governance process in place. So I, I might have got my hand slapped a little bit in using Blueprint because we're not fully an AI shop yet. Right . We are going through. So we have gone to 23. There are some inherent AI capabilities. We've got the Pega AI addendum going through our review process right now, but I would say we're in a safe space right now because in using Blueprint, we're not putting any proprietary knowledge out anywhere. We're using industry knowledge and that kind of thing. So we're still in a pretty safe space with what we're doing right now as we bring in more AI capabilities across the enterprise.

right? So all the things that we're hearing about, you know, as we bring them in, if we choose to put them in the App Factory model, then yeah, we're going to have to be a little bit more careful. But again, I've got an LSA by their side. So we're being careful already because we want to make sure that we do stay in compliance with everything but limited AI right now outside of Blueprint itself. Any other questions? Y'all look as tired as I do. So you have successfully completed the next to last breakout session of the day. Thank you for joining us. I hope you learned a little bit and we're here if you need anything.