PegaWorld iNspire 2023: Citizen Development is not what you think it is: Establishing an Innovation Factory for Low Code Development

The US Bureau of Labor Statistics projects that the developer shortage will grow to 1.2 million by 2026. Low-code tools are essential to bridging this gap, by improving developer productivity while also democratizing development so that more people can participate in software development efforts: citizen developers.

Citizen development is essential to meeting the software demands of today’s enterprise. But what is citizen development exactly? How are organizations to fulfill its promise without the peril of shadow IT? And how should they think about maturing their operating models?

In this presentation, we will describe a vision for how organizations can scale low-code development by leveraging citizen developers in squads, as members of fusion teams, and as SMEs on highly complex and critical IT projects. Sharing research, industry best practices, and the experience of actual Pega clients, this presentation will describe what an innovation factory looks like in practice, discuss the role of citizen developers in squads and fusion teams, and propose a path to maturity that allows organizations to start today in order to see incredible results tomorrow.

Transcript:

- So what we're gonna talk to about today is gonna be citizen development. And really, where I want to begin is, what is a citizen developer, right? If you're anything like me, when I first started learning about citizen development, there is no shortage of opinion. Everybody absolutely understands what a citizen developer is, but everybody disagrees, right? So let's talk about citizen development. I wanna start with this definition. I love this definition. I think it's an incredible definition. Everybody should know this definition because everybody has a very strong reaction to it, right? Look at this definition and tell me how it makes you feel. Do you see any issues with this? Does this make you feel comfortable or uncomfortable? OMG, guys! Really? Like, you know, you know just because something is not actively forbidden doesn't mean that it's sanctioned, doesn't mean it's supported. It doesn't mean it's not shadow IT, right? So, I love this definition because you show it on the screen, you get people to read it, and you can hear the toes curl, right? Causes people anxiety. But that's not the only reason why I love this definition. I also love it because it claims that it's not a title or a targeted role. And increasingly, this is not even the case, right? Increasingly, organizations are, if they're not hiring citizen developers, they're building the idea of a citizen developer into job descriptions. And then this, "They report to a business unit or function other than IT." At Pega, we have a citizen development program, right? We have highly skilled CLSAs. We have who are working business units, and they're creating low-code applications, those are citizen developers, despite their expertise. We also have individuals within our IT department who are not professional coders, but they're nonetheless building applications to help IT operationally in low-code. Those would be citizen developers, even though they are in IT. So the idea of citizen development is fuzzy. It's a little fuzzy, which is why I really like this definition. I actually like this definition from the Project Management Institute. And if you're not familiar with the Project Management Institute and you have not explored the handbook, highly recommend it. I'll say that in front that I agree with about 80% of what's in there. There's some things that like we disagree with. But it's a really strong starting point for anybody interested in investing and starting a citizen development program. A citizen developer is simply someone who can build applications without coding knowledge, but usually with the support of IT. That is important. To go further, often in a squad or a fusion team, right? So if you take this definition really seriously, can you tell I'm a philosopher? I like definitions. A citizen developer could look like one of these things, right? A citizen developer could be an individual contributor. When people think citizen development, they often think about this. They think about the maker, right? The individual who's creating applications maybe for themselves, maybe with a couple of buddies, right, to solve an individual problem. Great. And yeah, that's a citizen developer, sure. As long as they're working on a platform that sanctions and supported by IT, right? Otherwise, they're not a solution. They're maybe part of the problem, right? Bless them for trying to solve a problem, but still, we would consider that shadow IT. Here we're talking about individual contributors who are using a platform that's sanctioned and supported. We also see citizen developers in squads, taking on more complex problems as a member of a team. A great example of this, and I'll talk a little bit about this later, Navy Federal Credit Union. What they have is they have a citizen development pod in 80% of their business units. A pod consists of a project manager, a citizen developer, and a business analyst. And that team works collaboratively to build applications on behalf of their business unit. Those are citizen developers. They're working in a squad. And by virtue of that fact, they're more technically skilled and they're able to take on higher levels of complexity, but still remaining within App Studio. We'll talk about the technological pieces of it. And of course, citizen developers provide a tremendous value as a member of the fusion team. Being able to complete 50, 60, 80% of a project, but have that project completed and validated by a professional developer, right? So, citizen developer, it's a broad category. We see a citizen developer's appearing within an organization in these three ways. So what? So what? Okay, so I'm gonna make your tools curl in a different way, right? So we all understand that enterprise backlogs are long. There's a lot more work for engineers within departments to do than they can possibly take on. And the fact of the matter is, this issue is not getting better. It's getting worse. Backlogs are not staying the same, they are growing. 84% of organizations struggle to meet demand for new applications from the business. This shows us the other side of the problem, right? The fact of the matter is business use operation, they understand increasingly what technology is capable of. And as a function of that, they're making increasing demands from IT to automate applications. And IT just doesn't have enough capacity. Not just because they don't have capacity because we're in the middle of a developer shortage, and that developer shortage is not going away, right? 91% of organizations say the demand for automation from business teams has increased over the last two years. And 50% of enterprise purchases today fall under the umbrella of "Shadow IT," right? Just mention like, is.. Okay, this is the wrong room to ask this question. Does anybody question the value of low-code today? Right? The question, "Why low-code," is kind of a ludicrous thing at this point. It's not new, it's been around for a while. Organizations are obviously seeing value. The question is no longer, "Why low-code," the question is, "How?" It's a function of prudence. What is the right condition under which to use low-code? And in that situation, what is the right modality, the right operating model to build and support low-code application development. We know, for example, and, you know, those of you who've been with Pega for a while, we know for a fact that Pega is able to really improve developer productivity in a significant way. This is from research we did with Gartner. Sorry, with Forrester. If you have not read this most recent TEI study, I strongly recommend it. Time needed to develop a process before Pega, six months. Now down to, after three years of investment, eight weeks on average, right? Resources develop a project, a process, from 15 FTE down to six. And we see this story heard over and over and over again from the perspective of the professional developer. This helps with IT backlogs a little, but the fact of the matter is there's still way too much opportunity there. More need, more demand than we have the capacity to deliver against. So we're able to do more to execute against that backlog more, but there's still a lot of opportunities for automation that we know about, that we just don't have the capacity to deliver. So we've gotta cut... We, obviously, I have to say, you know, if you're not tall enough, what's the expression if you're not past this line, what's the... If you're like an amusement park, rollercoaster, if you're not this tall, you can't ride the ride, right? If you're not this complex or critical enough, you can't ride the ride. You cannot have your automation request granted 'cause IT has to make decisions, they've gotta cut it off somewhere. The greatest tragedy about this though, is the fact that, well, first of all, we know that that's just the tip of the iceberg. That there are tons of processes that are manual, kludgy, error-prone within an organization today that IT and others just don't know about. And because of that, we see absolutely shadow IT. We have see individual departments licensing unsanctioned tools in order to just get their work done. But the greatest tragedy beyond that is the fact that business units, when they hear no enough, they stop looking for answers. They stop even asking IT for those requests. They become resigned to those error-prone manual processes. This is just the way things are, right? And that is a tragedy. It's an absolute tragedy. So, we understand what citizen developers are. Great. We know why it matters. Because in the absence of citizen development, in the absence of democratizing access to low-code tools in a sanctioned and well-governed way, we just have no ability to execute against our backlog, we have no pathway to execute against requests from the business. So how do I do it? Okay, how many of you saw the main stage yesterday or today on the, you know, the big, huge autonomous enterprise thing? You saw the terms Low-code Innovation Factory. How many of you saw that? How many of you knew what that was? All right. So the idea of a Low-code Innovation Factory is this, essentially, imagine a world, right, in which individual users from everywhere in the business are able to deliver their requests centrally. So you've got unified intake, "I have a need for automation." Here. We're able to, by virtue of the fact that we have a unified intake and an ability to sort of assess the complexity and criticality of those applications, we're now able to assign those applications to the right group. You don't wanna assign a simple application to a very expensive development team, right? You don't want to take a highly critical, complex customer-facing application, and give it to a citizen developer, right? So it's about managing risk, it's about managing complexity. It's also about managing cost, right? That citizen developer is gonna be far less costly than a professional developer. And of course, because we're using a single platform, Pega, we're able to take, not only assign and deliver these things quickly, we're able to deploy them in a unified fashion, continuously optimizing for reuse. And over time, through process mining and other things, looking for opportunities to automate those processes even further in support of this vision of the autonomous enterprise using artificial intelligence. So if you ask, "What is a Low-code Innovation Factory?" It is this. It's the ability to intake requests from the business, assign them to the right team, the right modality, and to do it all in a unified way. Of course, this has a lot of benefits to IT, to those professional developers, because honestly, they don't like it, dealing with those mundane things. They would rather deal with the, like gnarly challenging things, the things that actually require their expertise. Those are the challenges that they really want to dig their teeth into. And of course, low-code helps them. One of the greatest ways that I believe it helps professional developers here, is the fact that... A study I was reading recently. Developers who use low-code tools are far more likely to work a 40-hour work week. And by virtue of that fact, are far more likely to be retained by the organization that hired them, right? So, high quality experience for professional developers. This idea of fusion teams, you know, take those lower complexity, moderate complexity applications, and give them to citizen developers as much as possible while augmenting those citizen development capabilities with professional developers to add more complex functionality, but most importantly, to mitigate risk, right? If the application that's being built is important, importance comes with a risk. And you've gotta have the right people on that team in order to understand and mitigate it. And if at all it takes is one person from IT to sit on that team to mitigate risk from a fusion team, but that's gonna, again, significantly decrease your cost of delivery. And then lastly, this idea of citizen development, right? So as you can see from this diagram between fusion team citizen development and IT-led development, we were able to cover the full spectrum of automation use cases. And there are a lot of, sort of, benefits to this. A lot of benefits. Not the least of which is the fact that, how do I... Yeah, all right. This little space in here, where we talk about fusion teams, right? If you understand this idea of the low-code continuum, and many people do, and the analysts talk about this. I'm not making this up. This is not a Pega thing, right? But if you sort of think about it as a continuum, and you say, "Okay, what kind of technology, low-code technology am I gonna give to my citizen developers?" And what am I gonna give to my professional developers? Of course, I'm gonna give them Pega," right? You now have, by virtue of the fact that you've given your citizen developers and your professional developers different tools, different low-code tools, you essentially render this murky middle. Impossible to execute against. These use cases that are not complex or critical enough for IT-led development, but too complex and too critical for citizen developers to take on. So the fact that you have a unified platform means that this now becomes possible. Fusion teams become possible in a way that they wouldn't be otherwise. The other benefit of this, and I'll talk about this repetition, repetition, right, is we're able to provide our clients with great guidance, right? You may have heard some people say, "Begin your low-code journey with citizen development. Begin there and mature up into IT-led development." Why? Because these are the simplest use cases. This is gonna be the best place for you to be in. That is an, kind of an irresponsible sort of approach because responsible citizen development, assuming that the citizen developers are actually building applications that are valuable and important, the hope is that they are. That's gonna introduce risk, right? And with risk comes the need for governance. And if you start here, without having maturity here, you're not gonna have the governance and the systems necessary to see these people not only develop safely, but also to flourish, to have the reusable components that they need in order to be successful. So we're able to, sort of, look at organizations, and say, "Look, you've got a COE. You're really effective in IT-led development here." How do we then mature you down into citizen development as sort of a destination rather than a starting point. And then, of course, because we're using a single platform for all of this stuff, we make possible this idea of graduation. The fact that you can have a citizen developer create a small app that's solving a very important problem for them in their immediate department. But then, as that application grows in complexity and criticality as other departments say, "You know what, that's really cool. I have the same need. Can we add on to that application? Can you meet my use cases?" Now there's a pathway for that application to graduate to IT ownership as that application grows in complexity and criticality over time without the need to significantly refactor and certainly without the need to re-platform, which is what would absolutely be the case otherwise. So this idea of graduation becomes important as well. Key to this Low-code Innovation Factory concept is this idea of intake. How many of you're familiar with Pega App Factory? Have you played around with it, seen it, visited the Innovation Hub booth? It's a couple of hands. Your homework is to visit the Innovation Hub and to visit the Pega App Factory booth. This is hand-managing a really important problem, right? The challenge is how do we identify automation needs within the business. Invite people to contribute their needs and their requests, and assign those tasks to the right development modality. So what Pega App Factory does is it provides that exactly that kind of unified intake to ensure that the right projects are assigned to the right teams, not only to mitigate risk, but in order to essentially manage cost, right? Tune the resource mix so that it accords with what is necessary in order to complete that job. We also, through Pega App Factory, allow for automated compliance with custom guardrails. What does that mean? Well, it means, if you use Pega App Factory, you are now able to deploy an environment to a citizen developer using a template that essentially locks down their environment so they have a safe playground. They have access to all of the tools that they need in order to be successful, and none of the tools that would introduce a risk. The most basic thing is use a template for a citizen developer who's maybe not super experienced, give them only access to App Studio and not give them access to Dev Studio. So we're able to enforce that. And because you're able to automate the enforcement of these guardrails, what it means is that IT doesn't have to be hands-on. They don't need to be papa bear, papa bear governance, right? You don't have to have papa bear governance. But they're able to essentially trust that it whatever is created by these citizen developers because it is gonna be safe. Within Pega App Factory as well, we have the ability to provide coaching. So as a citizen developer says, "Look, I wanna build an application." The COE or a practice manager says, "Yeah, looks great. You have the necessary training?" "Oh yeah, yeah, I've taken the low-code maker mission on Pega Academy." "Okay, great. Perfect." "Do you feel comfortable with Pega right now? Do you have much experience?" "No, not really, but I'm sure I could figure it out." "Well, okay, you know what we're gonna do? We're gonna assign you a coach," right? Somebody who's more seasoned. Could be a more seasoned citizen developer, someone who understands what it is. Could be someone from IT. But the point is, the coach is not a hands-on keyboard collaborator, otherwise it would be a fusion team. And we're not talking about fusion teams, we're talking about citizen development. So lightweight governance allows for coaching, which is lightweight, not hands-on keyboard. Citizen developer says, "How do I do a thing?" Coach says, "Ah, you know how you do a thing? Watch this two minute video," right? "Read this documentation, or you might wanna consider this, that, or the other thing," right? So they're directing them to the right resources, but they're not actively collaborating, which again, is important because IT resources are costly. So how do we balance the need for IT resources according to the use case. Pre-approved application templates, of course, right? So if you have an individual who wants to build a, let's just say an approvals app. Now with App Factory, instead of just deploying a raw environment, blank slate, "Okay, have fun, good luck," we're able to say, "Okay, look, you're building approvals app, here's an approvals app." You're 80% done. Now you just need to have to configure it. And that lastly, we're able to tailor DevOps pipelines according to individual project needs. So if the nature of the project is such that you trust a citizen developer to deploy changes to their application without the need for a lot of extensive testing, you can actually give that citizen developer the ability to push those changes directly to production. If you do not want them to do that, you don't have to let them do that either. So you can completely tailor your DevOps pipeline according to the use case, according to the application, according to the user, according to any other sort of factors. So Pega App Factory, it's a very lightweight application available via the marketplace. No charge to anybody, comes with your existing pay license, but is incredibly powerful. And our clients are using it with great success. It's important to underscore, again, repetition, repetition, repetition. What we're talking about is IT and business collaboration across the entire continuum, right? What we do not wanna do is exacerbate existing tensions between business and IT, right? So what we wanna do, but we wanna balance that relationship and establish a relationship of trust. So if you're talking about citizen development, the role of IT is to function as a coach. As governors, and as coach, to make sure that those individual makers or citizen development squads are successful as possible. When you're talking about fusion teams, now you are talking about active collaboration between business and IT. But again, tuning those resources according to the needs of the application, right? So if you can get 80% of that application completed by citizen developers and 20% by professional developers, you've saved a significant amount of money, and you've also been able to accelerate development because those citizen developers are ready to go, right? And then lastly, IT development. Is IT development, where the citizen developer is not necessarily hands-on keyboard, but continues to function as a subject matter expert. Talking about graduation, I'll use an example. So at Pega, the very first application that we built as part of our own internal citizen development program was to manage marketing workflows. So we had an individual, they were responsible for running email campaigns, and they were just bombarded with requests by email, right? Outlook is terrible for project management. So what they did is they built a simple app. Simple workflow app. You know, put your request in here, I'll respond, and we'll like, do the thing. And it like, helped that person. But then other people within the marketing department said, "You know what? That's really handy. I hate using email for this stuff too. Why don't we extend that application to meet my needs?" And then more and more and more. After a certain point, it becomes so critical to the organization because so much of your marketing workflow or so many of your marketing workflows rely on this application. It's no longer appropriate for a citizen developer, a developer to own that application by virtue of this criticality and complexity. And so we have now graduated that application up to IT ownership, and it's now responsible for all of our marketing workflows within Pega. And I think it's a great story, but it's like, just one example of many. So we've got two G's. Governance, it's important. Baby bear governance, not papa bear governance, 'cause papa bear governance will push people away into the arms of like unsanctioned tools. Not mama bear governance, 'cause if you don't have enough governance, you just have shadow IT all over the place. It's baby bear governance, right? Graduation. And lastly, you've heard a lot about this generative AI, right? And I think this is really gonna help citizen developers feel more comfortable in the tool. It's gonna accelerate their ability to build. And it's gonna establish, I think, increasing amounts of trust between citizen developers within the business and the IT professionals with whom they are partnering, right? Story time. How do I scale low-code development across the continuum? I mentioned at first, I strongly recommend that PMI handbook. Project managers in the room? Yeah? If you're a PMI member, you already have access to the handbook. If you're not, it's worth buying, like it's a really strong thing. One thing that I disagree with, however, well, okay, this low-code maturity model, there's a lot of words. Ignore the words. The idea is more important. The low-code maturity model that they provide, I think is very, very strong. But what they don't identify, what they don't mention is the fact that there's a huge chasm between discovering experimentations, kind of grassroots efforts within departments, even using sanctioned tools, right? You're working collaboratively with IT, but you're like, you're just sort of experimenting, trying to demonstrate value. PMI sort of recommends that you sort of discover and you experiment. And as a result of this, you're able to generate use cases and you're able to, sort of, show leadership within your organization. "Look at the success we've seen. We should do more of it." In reality, this is a really hard thing to do. And it's a really hard chasm for organizations to cross. Where organizations that we work with have seen the greatest success in the shortest amount of time is by effectively bypassing discovery and experimentation, garnering the transformational leadership support necessary in order to fund, expand, and support this effective low-code strategy across the entire continuum. And I'm gonna use some examples. I'm looking for our Deutsche Bahn. Anyone here from Deutsche Bahn? All right, Deutsche Bahn friends, good to see you. And thank you. So Deutsche Bahn is one of these organizations that we're working with that's really leading the way. Where they began, you know, lack of central capacity to handle automation requests. Yes, right? This is sort of an issue. But what they also found was that development times were long and they were error-prone, largely as a function of issues around knowledge transfer management, right? We all know this, right? Business says, "I need a thing done." You go to IT, you say, "Okay, I'm gonna describe the thing." IT's like, "Yeah, I got it." Come back six months later. "Here you go, I did your thing. Congratulations." "Thanks, I'm gonna walk away. That's not exactly what I had in mind. That's not actually solving the problem. There's been a miscommunication there." So as a result, you've gotta go back and forth, back and forth, back and forth, just wasting time, trying to get the application completed. By leveraging citizen developers, they've been able to reduce the time necessary to develop, they've reduced the amount of communication issues involved, reduced the number of errors. But more than that, they understand. Deutsche Bahn understands that those individuals within business units who are citizen developers don't only understand the process, but they also understand the people, right? They understand the people. They're able to ask the right questions of the right people to say, "Is this application meeting your needs?" And because they've engaged with the right people all along, the chances of that application becoming widely adopted significantly increase. Way, way, way more than if IT were simply to deliver an application, say, "Hey, I solved your problems. Use it." You may have heard if you were in the panel discussion. Derek Burnin Couturier was on a panel and he talked about the slider. Very abstract, we sort of described it. This is the effectively the slider. Idea, very similar to the diagram of the Low-code Innovation Factory that I showed earlier. But you can see that they are looking at the automation use case, and they are tuning the resource mix between citizen development and professional developers in order to optimize for cost, speed, and effective knowledge management. Did I get that right? I got it right. Okay, good. Keep me honest. Keep me honest. Okay, so this is great. Navy Federal Credit Union. Anyone from Navy Federal in the room today? All right, no one to keep me honest here. I'll do my best to represent. 'Cause I think Navy Federal Credit Union is another organization that is really leading the way. Really, through this pod-based approach, right? So I talked about the definition of citizen development, low-code tools, frequently as a member of a squad pod. I mentioned their model, citizen developer, business analyst, and project manager. They currently have a citizen development squad in 80% of their business units. And these citizen development squads are able to take on automation requests from the business that would otherwise not surface to IT. Keys to their success, recipe of their success, thinking through governance first and establishing a, they call it the ACE, the Automation Center of Excellence Playbook. Establishing that from the beginning was really important. Their pod model I mentioned. But what I really like, and I think a best practice here is around training, right? At first when they engaged in training, they would take their citizen development pod, give them a project and say, "Good luck. Get it done." But training on the job without the effective support really takes a long time. So what they've done is they've really put a lot of time and effort into their training program. Every new pod today goes through a common training consisting of two weeks of in-class, which is basically the amount of time necessary to get your Business Architect certification. And then they work for three to four weeks for a standard project. The other thing I wanna mention from a success perspective, yeah, yeah, yeah. We can talk about like, they've got 35 applications, they're saving 300,000 hours or the equivalent of 150 FTE a year. 80% of the departments have a pod. But this cultural change is something that I think is really important, because what the pod is doing is it's not just automating processes as they are because you've got that business analyst, they're actually interrogating, "Is this process optimized today, or is it really super kludgy? Are there ways for us to improve the process, because we do not wanna automate bad processes. So let's optimize, understand that process, and use this as an opportunity to make it better prior to automating it." What's great about this is not only the fact that we have optimized processes going in first, Navy Federal is, if you've attended any of their sessions, they're also one of our early adopters for Pega Process Mining to sort of continue that optimization process. But this idea of a culture of continuous improvement. If you have a pod in your organization and they're actively working with your business unit to understand your automation requests, and you know that they're always asking questions about, "Well, how can we improve this process prior to automating it?" Now you get everybody within that business unit thinking about, "Well, how do I optimize my process as it is today? How do I improve it?" So it's really established a strong culture of continuous improvement. Something that was not anticipated, but is definitely the case. The last example that I want to sort of talk about is Ford. We have many, many, many examples. Again, standard intake. I talked about Pega App Factory. They're using Pega App Factory. They talk about governance, they talk about balanced governance. I like the idea of a baby bear governance, but it's the same thing, right? Making sure that the amount of governance and support that you're providing citizen developers is appropriate. It's not too much, it's not too little. It's just great. Investing heavily in reuse. To make sure that your citizen developers have access to features, integrations, functionality that is maybe not native to Pega App Studio, because it is unique to your organization, making those available. And they were able to actually accelerate this because many of the reusable components that they already built for themselves within IT, could then be surfaced and made available to citizen developers depending on how those things are built. That's not always the case across clients. But fortunately, at Ford, they were able to do a lot of that. And you'll see in their model, their low-code/no-code governance model, it's pretty small. But, you know, it looks remarkably similar to that Innovation Factory slide that I showed at the outset, right? Ideas, common intake, assigning use cases to citizen developers, fusion teams, IT-led, and then having a Center of Excellence, providing reasonable components, coaching, guidance. When Ford was figuring out their program, they talked to everybody. And I encourage you all to talk to everybody. They talked to Gartner, they talked to Forrester, they talked to Carter, they talked to Carter, they talked to the Project Management Institute, and they talked to us. And what I love, like when they said, "You know, we could have just talked to Pega." "Because really, our guidance resonates so strongly with what they've done and with the success that they're seeing." I would disagree in this sense, it is not Pega that is coming up with this stuff, It is not Pega that is forcing it down everybody's throats, all right? What we are doing at Pega is nothing, if not extracting those best practices from organizations like Navy Federal, like Ford, like Deutsche Bahn, in order to surface them, synthesize them, and make them available to the broader community, the community of all of you. So we're learning a lot from our clients and we're grateful. To summarize some of our big learnings as a result of this. Executive sponsorship is so, so important. You do not want to start your citizen development journey within individual departments, and hoping and praying that you are gonna demonstrate enough success to garner the attention and support of leadership. You really need to get that leadership first, and those leaders need to have a transformation mindset. Because this requires investment. It requires transformative change. I used to think that the notion of transformative change was kind of, sort of ludicrous. You know, brought to you by the Department of Redundancy department. But it's not. Transformative change. Standardized intake, of course, using Pega App Factory. Process optimization, thinking about it throughout the process, beginning, middle, end, and ongoing. Training, making sure that you have a strong training program in place, and then continuously optimize for reuse. What I'm gonna do in our last few minutes is just talk about some of the things that we've been doing to support citizen developers. And all of these things are a direct response to client feedback, feedback from clients like yourselves, what do we need in order to make these organizations successful. So the first thing that we did is we released a Low-code Maker mission. Because we heard that for a new citizen developer from a business, they don't necessarily need to start an eight-hour course. They don't necessarily need to learn a lot about the technical detail about Pega. They just need to know how to build an app. Like, let's get them started. So in less than two hours, someone who has no experience with Pega can now take the Low-code Maker mission on Pega Academy. They can build an application using the community edition of our platform. And at a bare minimum, you wanna make sure that all of your citizen developers, prior to giving them an environment, have at least gone through this. Oh, and by the way, the language, it's written for a business person. It's not super technical, it's even friendly. App Factory templates. I talked about the importance of templates for ensuring that your citizen developers have access to all the things that they need and not access to the things that are gonna introduce risk. The other advantage of templates is the fact that you can jumpstart their progress. So I mentioned, the sort of approvals workflow. Give them an app. You're 80% done. Configure the app. Because, you know, your citizen developer, your business user doesn't wanna build an app. They wanna automate a process, right? They wanna improve their lives and the lives of those around them. So the question is, how do we accelerate their journey and get them to see value? This is one thing. We've also heard that our documentation... This is before the sort of Pega Study Buddy. Have you ever tried the Pega Study Buddy? Have you seen this, powered by ChatGPT? You can sort of ask a question, "How do I calculate a field with a decision table," and it'll generate a response. But these videos were also highly requested by our clients. The question was, 'cause citizen developers, they don't wanna read and parse documentation. They have got a question, "How do I do a thing, and I just wanna see in two minutes." Click, click, click. "Where do I need to click to do the thing?" And that's what we've done. These videos now we have, I think 23, and the repository is growing in response to client requests. But these are two-minute long. There's no music, there's no voiceover, which means that doesn't matter what your language is, doesn't matter where you're from, you understand where to click. So these are a huge advantage, the current line of Pega community. And I believe that we'll end up seeing them in product within the AI-assisted development panel in App Studio very soon as well. Also, in response to request from our clients, we've launched a community practice, right? We have a number of communities of practice at Pega. We have a community practice for CLSAs, for BAs, for decisioning, for RPA, and now for citizen development. Our community practice model really consists of two parts. We've got asynchronous communication via a LinkedIn group on LinkedIn, but we also have regular event series. We've just kicked this off. This, what I'm showing you, this already happened. It's available on-demand. But these are fun, these are good for citizen developers. How do we inspire citizen developers to do more, and assure them that the work that they're doing is not intimidating, and assure them that what they're doing is in fact important. So what we did in our last session, just to give you an example, is we had three individuals. Jim McSweeny is one of the people who runs our own internal citizen development program. So he talked about our use of Pega App Factory and how we actually govern our program. Zach and Andreas, they're both citizen developers at Pega. And so they were able to share with our broader community what they did, what their experience was like. It's a lot of fun. So expect more like this in the future. If you are working with citizen developers, if you're interested in citizen development, if you are a citizen developer, I highly recommend getting involved in the community through the events and in the LinkedIn group. And that's it for me for right now. I think we've got five minutes for questions. Any questions based on what I've said, or bad jokes involving animals? Yeah.

- Yeah, I got one question. We are, like very heavy on the Dev Studio side of things. What would you say like, are the main key success factors to stop moving?

- There is definitely a place for Dev Studio. The most important place for Dev Studio in this world is, Dev Studio is the place to build the blocks. Build those reusable components rather than having, putting a professional developer on Dev Studio to fill those little complexity gaps. Think, "Is the thing that I'm doing likely to be a value to somebody else." And if it is, let's rebuild it as a reusable component so that it drives value across. So when we think about reuse, one way to thinking of it is, Dev Studio's where you build the blocks and App Studio's where you consume the blocks and put the blocks together, yeah. Did that answer your question?

- [Attendee] Yep.

- By the way, I think, lease plan, there's a presentation involving lease plan later in the day. If you're interested in enterprise or modular reuse, definitely take that in. Highly recommend it. Rabobank also just had a presentation on that topic. I don't know if any of you took that in. But if you haven't, make sure that you watch it on-demand. Other questions? Yeah.

- [Attendee] One critical training that's required for citizen developers.

- Good question. So at the bare minimum, what we would want is that, sort of, Low-code Maker mission, so that they're comfortable. Every organization has different ways of supporting them. Coaching, definitely. So when they have their first project, assign a coach, so that the coach can sort of walk them through the process. Ford does something really neat. They have regular office hours. So every week, supported by staff from the COE, citizen developers can walk in and say, "I'm struggling with this issue, what's this?" I think that we have a path to train citizen developers and to mature them, really, up to the business architect level. So like, if you're working in a citizen development squad and you're willing to take on more complex things, something like a Business Architect certification or equivalent would be strong as well. But I think, for a citizen developer, the main thing is make sure that you've got the training necessary to effectively navigate App Studio. I think the Low-code Maker mission is a great start. And make sure that you have coaching to make sure that not only the gaps are filled and that they're reminded, but also to be a bit of a cheerleader, right? Citizen developers can get frustrated early on, they can get consumed with other things, and it's nice to have somebody to check in on them and say, "How are things going," right?

- [Attendee] Yeah, so it's basically a collaboration between, you know, the business as well as the COE. So is COE a prerequisite for this kind of government environment? Before we set up a citizen development environment, do we need to establish a COE?

- So a Center of Excellence is definitely going to help because you've gotta have someone, some part of the organization that is thinking about governance from a holistic perspective. You need some part of the organization who's gonna be building and maintaining those reusable components. We do have a model, called the Low-code Factory model. There's a nice ebook, sort of, online, and additional documentation. If you wanna just stand up a citizen development program, the very lightweight governance, we call it a sort of a community practice approach, where you have essentially a practice manager, you've got coaches, and you've got makers. And you're able to do a lot that way. But in the absence of a COE, you're not really gonna be able to maintain those reusable components. And so, you're gonna hit, I think, a ceiling, in terms of what those citizen developers are capable of today. But that is one model for getting started.

- [Attendee] Yeah. App Factory is available in marketplace, which means we can install and give us a kind of thing without any license.

- Absolutely, so Pega App Factory, it's an application, it's a marketplace component. Anyone who has a Pega license, you have it. Doesn't cost you anything. Download it, use it, play with it. Say that again?

- [Attendee] We can download with the compatible Pega platform version.

- Yes.

- Launchpad is a different version. So we can install and we can do whatever we want.

- That's correct, yeah. And an app... The question was like, I believe, yes, you can download it. And you wanna make sure that you're downloading the version of Pega App Factory that aligns to the version of the product that you have. Yeah. The other benefit of about Pega App Factory is, it is a Pega app. It is intended to be customized, right? So the kind of questions and the flow that you want to help guide people down one path of applications, "Is this a citizen development app?" "Is this a fusion team app?" All of those questions and those workflows can be and should be tailored according to the needs of you and your organization, and can be revisited and revised over time as your program grows and matures. Yeah.

- [Attendee] So other than citizen developers, are the regular professional developers are also supposed to use App Studio like that? Is Pega recommending that shift from, you know, starting with the Dev Studio, instead, you know, start with App Studio, and then probably, you know, make the citizen developers actually up to date with what's going on.

- That is our guidance.

- [Attendee] Okay.

- If you're a citizen developer, that's your home. If you're a professional developer, that's where you should start.

- [Attendee] Okay.

- Because just by starting that and minimizing your reliance on Dev Studio, which has a lot of freedom. But with freedom, comes great responsibility, right?

- Sure.

- Upgrades and things can become challenging depending on how people use their...

- [Attendee] Yeah, it can reduce that collaboration between citizen developer and professional developers if they start with App Studio.

- If you start with App Studio, right? One thing about App Studio. As we are maturing that product, we are increasingly thinking through this lens, and asking what are the things that a citizen developer, an enterprise-grade citizen developer needs to be able to do that does not also introduce a risk. So we want as that citizen developer, even that professional developer, be able to do everything that they can in App Studio.

- [Attendee] Sure.

- Give them as much autonomy as possible, up until the point where it introduces risk. Because where that risk is introduced, that's where you want to become a fusion team. Because if you can mitigate that risk with one other member who's maybe interacting in Dev Studio, that's the way to do it.

Etiqueta