Who is a citizen developer?
With the growing popularity of low-code platforms, the demand for developers continues to increase as well. Many companies are trying to fulfill the business need for new functionalities, by ensuring proper availability of human resources. The idea of training non-technical employees, so that they can participate in application development, has become quite a hot topic. That is where citizen development comes into play – it’s an application development process which we had the opportunity to try out and we would now like to share with you our thoughts and observations. In my opinion, a particularly perfect product for this type of project approach is PEGA.
The basic question here is – who is a citizen developer? Don’t worry, I won’t leave you hanging without an answer: it is a non-IT-trained user with vast business knowledge who can quickly learn to build applications with the use of low-code/no-code platforms. To put it simply, it’s a person who is not a professional developer, but who shows some talent in the matter.
Citizen development – why is it worth trying?
The idea behind citizen development is to bring business and IT together. This is not just some utopian thought, but a purposeful set of actions, intended to bring about various benefits.
Let’s have a closer look at some of the advantages:
- constant collaboration between development and business;
- immediate business reaction to changes in the application;
- an increase in team productivity;
- fixing logical errors at the stage of writing the code;
- lower development costs;
- more time for pro developers to focus on complex tasks (simpler tasks can be implemented by citizen developers);
- obtaining valuable members of the IT team, without the need to hire external contractors;
- a friendly audience during demos 😉
Where to start and how to use resources efficiently?
The first steps might be tough, but let me assure you that it’s worth trying. The first challenge for non-IT people tends to be the new environment. They have to get out of their comfort zone and try to learn coding! PEGA is a beginner-friendly platform – it’s pretty easy to create basic processes, even after just a few hours of learning. With the proper supervision of a professional developer, you can improve your skills very quickly! The citizen developers are not the only ones who have some learning to do – PEGA developers must get familiar with the business needs and functionalities that are going to be implemented. That’s why a proper introduction between PEGA and citizen developers is needed, before the so-called Citizen Development With a Little Help from My Friends (aka the pros) journey can begin.
It’s important to build a partnership between different departments within the company, but you also need to remember that a team should not be too large, so that all team members can get involved and share their skills. In our case, the team consisted of: 1 PEGA pro developer, 2 citizen developers, and some observers/stakeholders (free joiners). Now that’s what you call the perfect combination of business and IT skills! Let’s highlight the most important starting points:
For PEGA developers:
- familiarize yourself with the business background for the project, i.e., the business needs and plans for the application that is going to be created;
- get to know the citizen development team, as well as the advantages and strengths of your new colleagues;
- find out how you can help them, right from the beginning;
- prepare or collect materials and training resources for citizen developers.
For citizen developers:
- establish access to the environment;
- get an overview of the PEGA Platform; complete trainings within the PEGA Academy (the CSA course);
- learn about PEGA’s capabilities, key features, the App and Dev studio experience; watch „how to” videos and read useful articles; benefit from the assistance of a PEGA developer (ongoing support).
The (initial) design – a real-life example
You have the team ready, you’ve obtained the basic information and performed the technical introduction. What’s next…? There is no need to further read up on theory or wait any longer – you can start your app development right now! When building applications, we applied one of PEGA’s defined approaches, i.e., the Microjourney. It consists of a “series of interactions between a customer and an organization, that occur as the customer pursues a specific goal”. The quote provides a definition of journey, but to achieve the relevant goal faster and to better understand the needs of the business team, we split the work into smaller parts. Of course, we remained focused on the stable production release, but that is the whole journey. The microjourney consists in delivering smaller parts in relatively short time – for example:
- Creating a new channel;
- Creating a new case type;
- Creating and reusing a component in a few places;
- Creating a new customer type (persona).
To summarize the approach, I will quote the Pega Academy again: “A microjourney is a business transaction that results in an intermediate or final outcome.“ And this journey is implemented as a case type with defined data, security, and channel. By building an application, while applying the concept of a microjourney:
- we have a clear scope of current work, which allows us to speed up the development;
- it’s easy to test the application, due to small and well defined modules; and we achieve business goals with the highest priority.
Now, let’s dive into the details of the initial design of the PEGA case type which we built together:
- data gathering and design thinking:
At the beginning, we needed to collect the requirements and create the backlog, i.e., a list of the tasks (topics) which we would like to implement, organized in order of priority. Then, we needed to think a little bit more about the data structure we wanted to achieve and about what the whole process was going to look like. It could have be drawn outside of PEGA, even on a piece of paper (however, as an IT company, we obviously used more advanced tools – such as Miro Board and MS Excel 😊).
- translation of business requirements – user stories translated to PEGA case types
The next step was to move our business process into PEGA. We needed to take our “piece of paper” which contained a model of the process and create something similar in PEGA. We started from a simple case type, but – before we realized – it grew into a much more complex design. Below is a step-by-step breakdown of what this process looked like for us:
- defining stages and simple steps;
- adding logic related to approvals;
- adding notifications (sending emails);
- assignment extension – creating a screen flow for the fulfillment form;
- adding logic based on the output of the user action;
- implementing alternative solutions for case closure;
- building integrations with external systems;
- (…) more and more complex enhancements!
And, in the end, our piece of paper became a quite complex PEGA case type:
Case type created as a result of a collaboration between citizen and PEGA developers
Building an application
The example described above looks easy and… that’s partially true! It’s not so hard to accomplish the goal, but it requires a good plan and some preparation (as well as, of course, a well-functioning and cooperative team). I’ve already mentioned IT and non-IT collaboration, but let’s focus on the background – what does it really mean to have a good plan?
– Discuss the work plan and meetings
“Let’s have a meeting to discuss how the number of meetings we have is making it hard to get our work done”. I really like this joke – it perfectly sums up the corporate nature of the IT industry. But the terrifying truth is that… some meetings are necessary. It’s a bit like what the joke says – sometimes we need to have a meeting, to avoid further unnecessary meetings in the future. We need to plan our work, set up consultation slots and regular catch-ups to monitor progress – especially since the goal is to lead and teach less experienced developers who are to act as independently as possible. At the very beginning, assistance might be needed every day – but, at the end of the project, it may turn out that a pro developer will only need to provide their support once a week or only at key stages, such as code reviews or more complex tasks.
– Create a development backlog and a short-term work plan. Prioritize tasks.
In addition to the above, a good plan and prioritization of tasks significantly improve the quality of work and allows you to avoid chaos.
– Divide tasks between the PEGA developer and the citizen developers
A very important point. Initially, all tasks will probably be assigned to a pro developer. However, a distinction should be made between those tasks which they must complete themselves and those which can be delegated to citizen developers – to complete after appropriate training or with partial support from a pro developer. Over time, citizen developers will become able to take on more and more responsibilities.
– Schedule meetings for learning PEGA, backlog refinement, and discussing development issues, as well as regular status calls
You should always remember to update the meeting schedule, depending on your needs and acquired skills.
Regular work and meetings
Initial design of the case type should be done by a PEGA developer. At the beginning, citizen developers should only handle less complicated tasks, such as the UI design with time, they can move on to more and more advanced technical problems. One may ask: how to find time for learning, while maintaining the proper development speed? It’s all about establishing the perfect collaboration between the citizen developers and the PEGA developers, so that a low-code application can be successfully built. This goal can be achieved through:
- Regular meetings to speed up development:
- obtaining and expanding the PEGA knowledge (presentations of chosen topics related to current work or future requirements);
- performing demos of recently developed features (from both sides – PEGA and citizen developers);
- allocating time for citizen developers to present their ideas and low-code skills;
- showcasing how to reuse enterprise components and PEGA OOTB features.
- Specialized training and written materials, in addition to regular meetings for citizen developers.
By following this approach, we were able to save a lot of time and to improve the skills of the entire team. The application was growing fast and, as a result, we achieved our goal: the go-live of an attractive piece of code! The diagram below illustrates the scope of our work – from the first simple case type, all the way to a quite complex application which successfully passed the code-review.
Progress in development – regular updates and new features added to the application
When is the help of a senior developer needed?
The key element of the entire idea is the role of a professional developer. The support of an experienced individual is necessary for the application to be of good quality and in order to complete the process relatively quickly. The main responsibilities and necessary skills of a senior/lead developer include the following:
- Recognizing the possibility to reuse the OOTB tools;
- Creating (or helping to create) reusable components;
- Having knowledge of enterprise components and knowing how to use them;
- Performing more complex integrations with external systems;
- Reviewing new features implemented by citizen developers;
- Helping with reported issues, such as:
- the design of the user portals, defining landing pages;
- validation;
- refresh strategy;
- cleaning and updating data, based on the action performed;
- security settings (access groups, roles, personas, etc.).
- Code review;
- Reviewing and updating the documentation;
- Access configuration;
- Deployments;
- Tests supervision;
- …and last, but not least:
- The presentation of how the PEGA Platform works.
What can be done by citizen developers?
The business teams and citizen developers are useful resources, as well – it’s good to know how to use them in the most effective and efficient way. In our case, the less experienced team members performed many different tasks, such as:
– Implementation of the new steps in the process;
– Data preparation for Data Types;
– Preparation of packages for deployments;
– Tests execution;
– Support and fixes for the current application;
– Customization of the UI;
– Customization of the landing pages and user portals;
– Simple validation creation;
– Defining the decision tables;
– Creation of data transforms, when-rules, properties, simple data pages, and reports;
– Modification of the existing flows, for example: new decision shapes, changes in the routing etc.
Even after citizen developers become independent, it is good to have a more experienced person available for code review and supervision in every project.
The benefits & risks of citizen development – a few examples
Conclusion
“Everything that has a beginning has an end”. If we supplemented this quote from “The Matrix” with a few additional conditions on how to reach the “ending”, it could serve as a good summary of our journey. Of course, the ultimate goal was to build a quality product, within the best possible timeframe. By consistently following the approach we had chosen, we managed to incur many benefits which will certainly pay off in the future. And that’s why… I also thought of a different quote 😊 You’ve probably already noticed that I am a big film buff – so this time I’ll quote the TV series “Dark”: “The beginning is the end, and the end is the beginning”. The professional PEGA developer must think holistically; as they begin working on a project, they must already have an action plan in place, in order to achieve the final goal. The go-live marked the end of the current project, but it was just the beginning for citizen developers within the PEGA world. They learned a lot of new technical skills; they are now more confident in app development and able to work on increasingly difficult tasks, with less and less support. Perhaps some of them will soon pursue their code creation as their true calling, obtain PEGA certifications, and, at some point, begin to create their own teams where they will supervise other citizen developers. And so on, and so forth. I guess what I’m trying to say is that not only did we create a cool product, but we also increased team skills and versatility. Our achievements can be split into two categories:
From the perspective of the product, we achieved the following:
- A quality application with a possibility to expand on it in the future;
- Reusability based on implemented components;
- Great business agility;
- Good traceability of the work progress.
From the perspective of the team, we achieved:
- Personal development – obtaining technical skills and broadening business knowledge;
- More confidence;
- A perfect balance between business teams and IT departments;
- Increased productivity, thanks to leveraging citizen developers.
What’s the plan for the future?
- Implementation of other processes;
- Increasing the complexity of the current case;
- Increasing involvement and input provided by business teams;
- Encouraging other departments within the company to follow a similar path.
Did everything go smoothly and in accordance with our expectations? I would be lying if I said that it did. We obviously ran into some trouble – some examples include:
- The need for citizen developers to focus on their daily work (before the launch of our project and the development of the application, they had to deal with tasks that PEGA is now supposed to perform instead);
- The need to focus on problems longer than initially expected, to fully explain them and allow the team to deal with similar future issues on their own.
Despite the above, we managed to build, test, and deploy the application. The first impressions of the managers who decided to invest their team’s time and budget are very positive; in fact, several more case types are already planned to be built. I think that’s the best answer to the question whether going in this direction was worth it.
You may ask: what about the PEGA developer? Did they waste their time? Could they have used this time to focus on more ambitious tasks, in more difficult projects? Since that developer is me, I can answer without any hesitation: not only did I broaden my business knowledge and improve my soft skills, but I also learned a lot of new technical stuff. Teaching others always requires absolutely mastering the material; the students tend to ask questions which the teacher would never ask themselves and you are also forced to solve the technical challenges which occur in the process. I can definitely say that this was not only an interesting adventure, but also a great learning opportunity.
