Coaches are experienced as makers in one way or another. They might have extensive experience as a trained Pega developer, or they might have gained experience over time as a citizen developer in the App Factory program. It is essential that coaches understand the goals of the App Factory program and their role in it — technical capability alone does not make a successful coach.

Keys to success

Whatever their background, coaches must understand how to advance the goals of the program to be successful.

The first goal of the program is to enable new makers to create andmaintain apps that provide value. Coaches advise — they should not be “hands-on-keyboards” themselves. It is vital that the makers develop their own applications. Only in this way can makers iteratively improve their applications and maintain them over time. Enablement ensures that makers become capable of working more independently with experience. Eventually, a skilled maker is likely to become an effective coach.

As part of this goal, it is very important that coaches work with makers to develop their application in App Studio, ensuring that citizen developers get a development experience that is designed specifically for their capabilities and needs. Doing so enables makers to work independently over time with ease. It also ensures that the applications are of high quality and remain within Pega’s application guardrails.

Another goal of the program is to ensure that makers use existing solutions rather than each maker reinventing the wheel. Coaches support this goal by knowing (or by being able to easily discover) what resources are already available in the enterprise to help makers manage common use cases and leverage those resources. The shared reuse layer provides many of these resources. Others might be available through Pega Exchange or other sources.

Services provided to makers

Coaches provide guidance to makers as needed at every stage of development. They also provide important feedback to the App Factory program and the practice committee on how to better enable makers to be successful.

Makers should be encouraged to approach development in an agile way. At the start, coaches should help makers think about defining their minimal viable product (MVP) — the simplest initial version of an application that they could release that would be valuable to their users. This MVP is what makers should try to implement and release first. They can then iterate to improve or expand the application in cycles of development, release, and feedback from their users. An agile approach prevents makers from getting bogged down by trying to include “everything” in their first release. It also ensures that makers are successful quickly, and then allows them to further build on that success over time.

At the beginning of a brand-new application, the coach can help the maker think through basic design patterns for their application — what are the use cases, data, and processes that must be implemented, and how might these be implemented through case types, the data designer, and the case designer in App Studio? Coaches can show the maker how to use the App Studio tools to begin creating and testing the end user experience of the application.

During development, coaches should identify when users should make use of existing assets and integrations available from the shared reuse layer. Doing so ensures that makers are making the best use of their time and effort. Ideally, the program should provide solutions to common maker use cases so that makers can focus on what is unique to their application.

As makers iterate on their initial application and add additional features and improvements, coaches help them to understand any upgrade implications that need to be considered and managed. For example, when adding a new field that is always expected to get a value, a maker needs to decide what to do about providing a value for the new field in cases that already exist. Helping makers think through upgrade implications ensures that each iteration rolls out to production smoothly and without any damage to existing functionality.

Coaches also help makers understand the Dev Ops aspects of the App Factory program. What are the processes and reviews necessary to release or upgrade an application? How do end users request and receive access to the application? How can makers be expected to support the production application when support is needed by end users?

Services provided to the program

In addition to supporting makers, coaches improve the App Factory program, the shared reuse layer, and the community of practice.

Where coaches identify a common maker use case for which there is no existing solution, they should work with the practice committee to describe the use case clearly so that the practice committee can provide a common solution to all makers in the future.

Coaches must provide feedback about any common misunderstandings, difficulties, or suggested improvements for the App Factory program and its practices to the practice committee to help with the continuous improvement of the program. This information must also be used to improve and expand the program FAQ so that makers can get the benefit from the answers to questions of previous makers, and not wait for individual coaches to get answers to many questions.

Managing workload

Because coaching is usually a part-time role for people with other responsibilities, and makers need very different amounts of support at different times, coaches can become stretched thin at times and makers can become frustrated that they sometimes cannot get coaching time whenever they need it. Each coach-maker pair should decide on the approach they want to follow for requesting and providing coaching support.

The following list details some of the approaches that have worked well for this relationship:

• Collaboration spaces – An excellent way for coaches to provide support. Spaces allow for online asynchronous chat and support various resources, including screenshots, links, and attachments. Spaces are especially helpful when makers and coaches are not collocated or working at the same time. Coaches can provide answers to maker questions as soon as they log in to the space, and those answers remain available in the future to other makers who might have the same question.
• Office hours – Setting aside certain hours of the week for makers to drop by if they need help enables makers and coaches to plan their time and align their expectations.
• Enterprise ticketing/service request system – A ticketing system can easily accommodate maker requests for help when they need it and can set SLAs on coach response time. Doing so gives makers and coaches freedom from scheduling coaching hours and still align expectations.