Delivery with Pega Empowering your business to implement change

DELIVERY WITH PEGA

Douglas Kra, Senior Vice President

Global Customer Success – International

Ken Hirschkind, Vice President

Global Consulting Strategy and Business Services

Paul East, Director

Global Consulting Methodology

Kate Lepore, Senior Director

Consulting Product Marketing

Foreword by Alan Trefler, Founder, Chairman, & CEO

Editing and production by:

Colleen Pearce and Hope Goslin

All trademarks are the property of their respective owners.

Scrum Alliance® and the corresponding logo are service marks of Scrum Alliance, Inc. and are used with

permission.

© June 2018 by Pegasystems Inc. v2.0

2

Contents

Foreword – Alan Trefler .............................................................................................................. 3

Pega’s vision for rapid implementation .................................................................................... 4

Adopt co-production ............................................................................................................... 6

Focus on customer journeys .................................................................................................. 7

Build with an Agile delivery methodology ............................................................................. 9

Leverage our platform to accelerate the development process and improve quality.…10

Visualize your solutions with DCO ....................................................................................... 11

Leverage an effective and efficient testing process ........................................................... 14

Establish a formal governance process ............................................................................... 16

Summary .................................................................................................................................... 17

Glossary ...................................................................................................................................... 18

3

Foreword – Alan Trefler

There’s a lot of hype in the market today about low-code development, digital transformation, and the latest emerging technology. And, quite frankly, there has been for many years. It’s easy to get caught up in the promise of these capabilities. However, if your decisions are based on a wave of hype, you can easily end up with unmet expectations and oversimplifications in your business – a major disservice to your organization.

As Founder and CEO of Pegasystems, I spend an enormous amount of time talking with our clients and prospects and hear many similar themes. Many of you are grappling with the legacy of previous software decisions and the organizational rigor-mortis those decisions have created. I also hear many of the same business concerns: our market is being disrupted; we need to go faster; and we need to reduce the total cost of ownership. At Pega, our value proposition is not based on hype. We understand what it means to be real, to be able to drive change, drive technology, and drive your business agenda in ways that are going to be very special now and into the future.

In this eBook, Delivery with Pega, we describe our vision of how to best deploy a Pega solution in very tangible ways, and how you can achieve meaningful change. We also show you what real digital transformation is about and the ways in which we approach it. We don’t try to solve all your challenges at once. We manage them one customer journey at a time, end to end, collectively delivering real outcomes rapidly and iteratively.

The decision about which journey to implement first depends on what is important to your business and the relative effort to build and deploy. You should pick the journeys that lead to rapid deployments and build excitement about the potential of what can be accomplished.

Our journey-centric approach allows you to build your application how you want it to work. You’ll create more relevant customer conversations on the front end that are connected to streamlined processes on the back end, meanwhile insulating your application and flow of work from operational silos and back-end systems.

Our results speak for themselves. You can quickly build better applications that are designed in a way that welcomes ongoing enhancements.

This vision is real. It’s based on technology available today and proven in thousands of production use cases, across almost every industry around the globe. With our delivery approach, you build for today and future proof for tomorrow.

Alan

4

Pega’s vision for rapid implementation

Today, software decisions are incredibly important for your future – your business will be driven, controlled, propelled, or held back by the software it uses. And not only is your software choice critical, so too is how you implement it. In order to keep up with accelerating demands, you need to build at the speed of your business – collaboratively, continuously, and for change.

Most organizations plan for an application life of around five years, but in reality, most stay in production for at least 10-15 years. That means any shortcuts you take today will become the technical debt you inherit tomorrow. The Pega Platform™ and application portfolio enable you to radically transform how you build and evolve your business applications so that what you do today sets you up for long-term success. Our delivery vision fulfills this transformation across three dimensions:

1. Quality and relevance – Applications are built to be high quality and functionally correct, based on direct contribution from business people and the power of Pega AI.

2. Speed – Applications are built in weeks rather than months and can be deployed into production one customer journey at a time.

3. Agility – We promote change in both development and design, allowing our clients to rapidly meet the ever-changing needs of the business.

To achieve these outcomes, we recommend you follow industry-standard Scrum, coupled with our best practices that are optimized for the Pega Platform. These key attributes form the broad strategies to drive your successful transformation with Pega technology:

• Adopt co-production

• Implement with a journey-centric approach

• Build with an Agile methodology

• Leverage our platform to accelerate the development process and improve quality

• Visualize your solutions with DCO

• Leverage an effective and efficient testing process

• Establish a formal governance process

Delivering the Pega vision

To execute at the project level, start by empowering your teams with our structured approach to ensure

a rapid, successful journey-centric implementation. This applies equally when using Pega Consulting, our

partner(s), or your own in-house resources. When fully adopted, you change who, what, and how you

drive rapid delivery to create unprecedented outcomes for your business.

5

Pega Delivery Methodology

Each project travels along a simple development life cycle. The phases include a defined set of activities, which closely align to standard Scrum practices, and optimize Pega’s unique capabilities. Whether you are new or experienced in implementing Pega, start the project lifecycle in the prepare phase, with the following activities accomplished:

Prepare • Define customer journey(s) as case types. • Identify data and sources. • Identify personas (distinct user roles). • Enable co-production resources. • Provision environments. • Identify what Day-1 Go Live will be

Build

• Deliver “Journey(s) at a time”. • Focus on out of the box. • Drive Minimum Loveable Product (MLP). • DCO with frequent Show and Tells. • Drive guardrails compliance and multi-level governance. • Validate Performance (PDC)

Go live

• Harden release. • Industry/client specific testing. • Transition to business.

The Pega Community website under Pega Project Delivery Lifecycle includes more detail and useful tools

on each phase, plus documentation on how to build your Pega application.

6

Adopt co-production

Pega’s mission is to change the way the world builds software. Our model-driven platform enables business people to contribute to a project by building pieces of the application using business-friendly metaphors. No programming experience required! Our experiential delivery model empowers your business with visual tools to co-design and implement high-impact processes and journeys with the development team.

It may be tempting to outsource development for faster implementation, or have business users “just” sit in meetings to explain their business problems to IT. But delegating development doesn’t yield the same quality application as including the people who best understand your business on the project team.

Think about it. Your business people understand your needs better than anyone else. This includes the policies, procedures, and rules that govern your business as well as the systems you use. Imagine if you could harness this knowledge and leverage it into a project development team. With Pega, it’s possible.

Select a minimum of three people and enroll them in role-based training. Start with the following roles:

• Business architect (BA) – The BA drives working sessions to gather and analyze requirements. Pick someone that works in the business but shows an acumen for technology. This individual should be familiar with process automation, flow charts, and process diagrams.

• Product owner (PO) – The PO sets priorities and manages the backlog of what to build. Select someone decisive and empowered with the authority to make important business decisions. The combination of these traits greatly influences your project velocity.

• System architect (SA) – The SA designs and builds components of the application. Choose someone with programming skills that thrives in a fast-paced role, loves to build, but isn’t tied to building lines of code.

For all of three roles, look for people who have the aptitude to learn and are excited for something new.

More details on the responsibilities and ideal background for all project roles is posted to community.pega.com. Formal role-based training for an SA or BA is typically just a two-week commitment in a classroom or online. Course descriptions and registration are available at academy.pega.com. Once you dedicate employees to these roles, you will find that there is a direct correlation between the investment and value you receive. Start the project directly after training to cement their knowledge through experiential learning.

When the project starts, newly trained resources work shoulder to shoulder with certified and experienced Pega practitioners on specific tasks like building correspondence, reporting, and testing, becoming productive week one. Over the course of the first six months, they gain valuable experience building rules, processes, and screens. In a very short period, your newly trained business staff are enabled on Pega technology and contributing to project velocity.

For testing the application, leverage your business users. They understand exactly what the system needs to do. They can change what is already built if it isn’t quite right. This is part of a test and learn cycle. As they learn more about Pega technology, they will better understand how to apply this capability to solve problems in the business. The best people for these opportunities are people who understand the business and Pega technology.

Generally, about 80 percent of the work in building a Pega application can be completed by business people, and just 20 percent, such as interfaces, requires more traditional IT skills.

Best practice tips: The best candidates for co-production are business people who are

frustrated with their current systems and have a strong desire to change them.

7

Focus on customer journeys

Most enterprises today are not starting with a “greenfield” or a blank slate. Your technology environment is more like a “brownfield,” created on top of or co-existing with legacy software applications and systems. Any new software architecture must account for what already exists.

Likewise, your business already has many channels – web, call center, social, etc. – that typically operate as silos, both internally and as experienced by your customers, making it impossible to deliver an effective and seamless customer experience. Many of your existing processes were designed around these brownfields and silos, not today’s digital and omni-channel environment.

When you’re building an application or starting a digital transformation, a common, well-intentioned error is to focus solely on front-end experiences, such as a call center desktop or channel-specific app. We know this approach doesn’t work as it only addresses a small part of the overall customer experience. The improvement happens in a silo and doesn’t deliver a consistent user experience across all the internal channels your users work with (e.g., a slick newly deployed mobile app).

Another tendency is to build up from existing brownfield systems. The data in your brownfield is typically product oriented, not customer centric. This makes it challenging to collect data and architecturally too difficult to build out.

Both approaches – fixating on a specific channel or building up existing brownfield systems – are fundamentally flawed. Instead, Pega advocates taking a customer journey-centric delivery approach. Journeys stretch end-to-end across your enterprise, from the moment a customer engages to the time the work is completed and the promise fulfilled.

Think of a customer journey as starting with the “outcome,” then working backwards to define the process, necessary data, personas, integrations and, lastly, the stimulus that starts the journey. Examples of outcomes that would be meaningful to your customer include:

• Signing up for a new home mortgage.

• Repairing fraudulent activity on your account.

• Updating an insurance policy to reflect a change in family circumstances.

Sample customer journey: Mortgage loan

8

Pega combines this journey-centric approach with Rapid Delivery principals and our revolutionary technology that lets business and IT turn designs into applications … without writing code.

Rather than attempting to do everything at once, start by building out one end-to-end journey within a specific channel. For example, you might begin a policy change journey by streamlining the process to add a new driver to an auto policy via the call center channel. You’ll see results quickly and will have a strong foundation to build off, making it easy to extend to a new channel such as the mobile app, or add additional functional capabilities such as an address change.

For each journey (also referred to as a case type), map out the distinct stages of the case. This describes the work that needs to be completed throughout the journey. Regarding the policy change example, the case would flow through stages such as changing account details and calculating a new premium. You can easily tailor the supporting processes to particular situations using our patented Situational Layer Cake capability. This allows you to execute your journey within different contexts, like customer segments, products, or location/jurisdiction specializations.

This case type approach is unique to Pega as it blends your ideal customer experience and processes with your existing brownfield systems. That means you are not limited by what currently exists when building the best customer journey.

Pega’s customer-centric, journey-at-a-time approach enables you to create a perfect representation of a case, expose this capability across all your channels, and map the data back into your “brownfield” environment. To us, this is what real CRM and digital process automation is about.

Situational Layer Cake

9

Build with an Agile delivery methodology

In the previous section, we described case types and stages. Enterprise scale applications will often

require 20 or more case types to fully achieve the desired capabilities. Many case types are already built

into our applications – some can be implemented right out of the box, while others may need

configuration to meet your specific requirements.

Pega uses a highly structured review process to map our apps against your requirements and identify the necessary changes. By prioritizing these requirements into a series of project phases we can identify where to focus first. The prioritization creates a backlog of case types that will be slotted into a series of releases, each targeted to go live in a matter of weeks. This allows for faster production and real-time cycle improvements.

This approach is the foundation for practicing an Agile delivery methodology. The Pega Platform and applications are built to allow you to take full advantage of Scrum, creating value much faster.

You may know the term MVP or Minimum Viable Product; however, we espouse building a Minimum Loveable Product or MLP. An MLP is the minimum set of functionalities needed to go to production to add significant business value. There are many benefits to building out an app using this approach:

• Start realizing business benefit faster. • Gain organizational support when the business sees something real. • Learn from the first release to improve future releases.

The idea of MLP is to start small, prove value, and iterate. Too often, teams focus on a discrete project, not the lifecycle of how an application begins, grows, and matures. The iterative MLP approach also sets your application up for reuse. Quite frequently, case types can be used across multiple channels through our “mash-up” or API capabilities, which accelerate development.

Focus early releases on leveraging out-of-the-box case types and defer larger specializations to subsequent phases. This enables rapid realization of benefits and actively engages your business with the solution as soon as possible.

The team you identify to co-produce will also benefit from this approach. By experiencing the full lifecycle of a release, they will learn to support and develop applications faster.

One challenge in adopting an Agile delivery methodology is that some stakeholders won’t agree to a phased delivery. They “need” everything in the first release. Because everything is lumped together and there’s no belief that the application will evolve over time, delivery can take months, or even years. And when it goes live, the requirements are often out of date and do not meet the business need.

A second challenge is that IT departments become too rigid in their attempts to control a project’s timeline, cost, and scope, leading to trade-offs, and reduced quality. In Agile, you address both.

You manage your team size (typically five to seven resources), which influences cost and velocity. Your business product owner manages the scope of individual sprints (usually in two- or three-week long intervals) and prioritizes the order that functionality is delivered. With these variables, you can maximize your productivity and value. This ensures that the most important capabilities and objectives come first. Additionally, through co-production, your business gains the capability to independently drive change.

Best practice tips: The ideal approach is to deliver an MLP in a matter of weeks that reflects

the long-term program direction. The long-term program direction should be captured in the

Pega Platform in the form of case types slotted towards future phases.

10

Leverage our Pega Platform to accelerate the development process

and improve quality

Using Agile is a key component to accelerate the build process. However, there are two other factors in a

project lifecycle that can dramatically add duration and delay value realization. The traditional,

documentation-heavy requirements gathering process adds time and often misses or improperly

characterizes business needs. This adds significant time to a project lifecycle.

Secondly, the traditional testing process that happens towards the end (or after) the build phase of a

project often leads to re-work and frequently misses the mark from a quality perspective. Our approach

to building applications, when combined with our technology, dramatically reduces these risks and cuts

significant time from the process.

11

Visualize your solutions with DCO

Part of the reason that software takes too long and costs too much to build is that every system is built twice – once in documentation and then again as working software. What if your business users could directly capture their business requirements into the system, throughout the project life cycle, build iteratively and rapidly, and review the progress frequently? Their real-time feedback would ensure the solution quality and relevance. This rapid development and fast feedback cycle ensures your application is right. The following Pega tools enable you to visualize and realize your desired solution.

Use Directly Capture Objectives (DCO)

DCO is the process, technology, and mindset where both business and technical developers collaboratively capture business objectives, specifications, enhance or re-engineer the work flow as part of the application definition. Project teams capture forensic evidence such as screen prints from existing systems, data requirements, and whatever else describes the case into the Pega Platform. This all becomes organized in Agile Studio. DCO is an on-going process that eliminates the need for translating requirements into code. With Pega, the software writes the software. Removing the need for traditional programming vastly improves your speed of building and changing your application.

Leverage Agile Studio, our simple yet powerful tool built into the Pega Platform, to manage activities and tasks while you “do DCO.” You can visually compare what is available out of the box and enter feedback about a feature gap in the form of textual requirements, visual screen captures, or videos. These become the details of user stories – short, simple descriptions of a feature told from the perspective of the customer, which are easily prioritized into an Agile release. This is far faster and more powerful than having to write a full description of what should change and cross reference it to existing documentation. DCO keeps the capture of business process, the implementation and the documentation all in sync.

Use DCO to capture requirements directly into the Pega Platform, essentially starting the

development process during requirements gathering sessions. Use the auto-documentation

capabilities to produce documentation from Pega directly further saving time and effort in the build

process.

Execute frequent show and tell sessions

Experience shows that direct, early feedback from various stake holder groups confirms that the team is building the right capabilities. It enables much easier course correction in the build cycle rather than in a traditional test process, or worse, after go live. By building the DCO “mindset” into the team and leveraging the capabilities of the Pega model, teams gain confidence and can show progress frequently, with minimal impact to the schedule. It also starts to educate the organization about the changes that are coming.

Pega recommends that teams execute frequent “show and tell” sessions and build this cadence into each sprint. This frequency varies based on the type of project, but the show and tell sessions should happen, at minimum, once every two weeks. There should be virtually no extra work for the team (except the actual show and tell session itself). By showing work in process in the Pega model, teams can execute process flows and show cases progressing from stage to stage in their lifecycle. This means that your business architect can show your product owner a set of screens that can be navigated to follow the business process. This is enough to have a sensible discussion about the overall process based on working software, rather than everyone’s interpretation of a document. Changes from this discussion can be made to the draft process (often in real time) and refined until everyone is happy with the results. This

12

becomes input to the next level of iterative development, which proceeds in a similar way in more granular detail.

Regular “show and tells” are usually fairly short and informal; they involve the product owner, members of the team, and interested stake-holders. The following describes key roles:

Product owner (PO)

The product owner is responsible for delivering the business benefits of the project. They should see the evolving software several times per week – or even daily – depending on the project size.

Route any suggestions about the system directly to your product owner. The PO alone should decide if the suggestions should be included in the backlog (in exchange for something else since budgets are limited). This is how backlog refining works. Start with a list of your priorities. Gradually add more detail to it and replace some lower value items with higher value items as they are identified. The point of a backlog is to deliver the expected business value, not to create a fixed list of requirements that cannot change.

How you show the system to the wider audience will depend on the project. It is usually a combination of live demo’s, presentations and recorded sessions. The exact details should be laid out in the project communications plan. Regardless of how this is communicated, the feedback must be via your product owner who can determine whether to include it in the backlog or not.

Project sponsor

The project sponsor is responsible for achieving the business outcomes of your Pega application. Often, they are also the budget holder for the project and the final decision point. Your product owner is the sponsor’s representative; they have day-to-day authority to make cost/benefit decisions, drive scope control, and resolve escalations. As such, it is essential that your sponsor and product owner are aligned on the goals of the system and have a high degree of mutual trust.

Your sponsor should see what is being delivered at least once per sprint. Typically, this is a formal show and tell by the PO, with a fixed agenda, at the end of each sprint. At this point, the PO formally accepts that the user stories presented are done or notes what needs to be completed in a future sprint.

Best practice tips: Establish a regular schedule of “show and tells” for the various

stakeholders involved (e.g., Monday, Wednesday, Friday to the product owner; Friday to

everyone else) and have a clear feedback process so participants know their opinions are

being listened to and acted on.

Manage and monitor

Pega provides several tools built into our platform to help manage a project, including compliance with best practice and run time performance.

Agile Studio

Agile Studio is an integrated project management tool that enables your project team and stakeholders to collaborate on features, releases, and development tasks, all within an industry best practice Agile methodology. While you may prefer using a single enterprise defect system across all projects, we always recommend holding defect tracking within Agile Studio to maximize team velocity and eliminate the duplication of effort in a separate tool. Benefits of the Agile Studio include:

13

• Managing by customer journey, enabling the team to directly link the work back to the source requirements.

• Tracking and monitoring the work in progress, through Scrum burn-down charts. • Improving visibility of “who” is assigned “what” with one-click access to the rules created. • Minimizing bug-fix time by directly linking defects back to the source requirements.

Guardrails

Let’s face it – errors are going to happen. However, the relative cost of fixing errors throughout the lifecycle increases exponentially the later errors are detected. Pega’s Application Guardrails examine how compliant your application is with the best practices and should be viewed throughout the development process. Guardrails are the guidelines for achieving optimal performance, reusability, and maintainability in your application. On the application guardrails landing page, the “compliance score” tab provides executive-level metrics that show how complex or custom code is introduced over time, and the effect of those changes on project quality. All guardrail warnings should be reviewed by your lead system architect and either accepted with a reason noted, or fixed. The less guardrail warnings you have, the easier testing and future upgrades will be. Target scores of 98 out of 100 for each release into production.

PegaUnit

PegaUnit enables you to create a small, automated test for each subset of a journey. Unit tests can be linked together to create an ongoing set of automated regression tests. They should be executed nightly, and results should be reviewed each day. Failed unit tests should be acted on immediately. By leveraging PegaUnit, you:

• Find out immediately if something is broken. • Locate the source of issues early. • Reduce the time spent with retests. • Limit failed retests due to small changes.

Predictive Diagnostic Cloud (PDC)

With real world usage, your production system may experience degradation, unknown stability problems, or responsiveness issues. Once software is released into production, PDC monitors the performance of the application in real time and provides regular alerts to help you find and fix issues before they affect your customers’ experience. For example, PDC identifies your slowest running queries so you can investigate the root cause. PDC helps you identify problems before they start to impact the business, so review and address alerts daily and incorporate the output in your governance meetings to:

• Improve the system reliability and resiliency. • Concentrate on the prioritized performance issues from PDC.

14

Leverage an effective and efficient testing process

Testing at Pega encompasses all the traditional testing stages. However, Pega is different because of how

you can perform our tests and the speed at which you test Pega apps.

Pega allows you to accelerate testing by moving the test work closer to the business, doing several types of testing at once, and providing tools to assist with the work. Start by using business subject matter experts as testers and arm them with our tools and processes that accelerate and simplify the testing.

With Pega’s Delivery Methodology, you flip the traditional model of heavy user acceptance testing and user interface testing to a model where the majority of the effort is focused on unit testing and automated regression testing. This is known as Pega’s Continuous Test approach. Your organization may use different names to denote parts of the testing process (end to end splits into integration, system, etc.), however the following table shows the types of testing to complete and when to perform each.

Test Stage Who Performs When

Unit testing – Checks whether software

performs basic function

Project team

members Daily during sprint

End-to-end testing – Executes test scripts

to ensure system operates as expected

Business users as

project testers End of sprint

Automated regression testing – Tests new

functionality with existing software

Project

testers/developers

Early testing while UI is

changing

User acceptance testing – Independently

tests that the system supports business

objectives

Business users End of sprint

Performance testing – Uses realistic data

and interfaces to catch delays in

functionality that detract from user

experience

Performance tester After UAT

Penetration testing – Tests for security

vulnerabilities Third party End of development

Industry or customer specific testing – Unique tests for your industry or organization (e.g., proven traceability)

Independent test

team After all other testing

Testing Principles for Pega

Pega lets you build working software faster, by providing complete testing coverage in less time, for a lower cost. To gain this efficiency on your project, adopt the following principles and tools in your formal test-plan strategy. As a guideline, testing should take no more than 20% of the total time to build the software for our customer engagement applications (and up to 40% of the equivalent time for solutions built on the Pega Platform). This can represent a significant reduction compared to traditional application development testing approaches.

Test configurations versus out of the box

Packaged software is assumed to work out of the box. That is the responsibility of the vendor, and you do not need to test it. But, any configuration/customization that you make needs to be tested, with one caveat: some functionality is used repeatedly in applications, but they do not need repeat testing. For example, to set a service level agreement (SLA), you configure a rule to define the time period of the SLA

15

and the action to take. Nearly every application includes this rule. You only need to test once that the SLA is properly set to a specified duration and the action to take is the right one. Similarly, pre-configured functionality that is localized needs more testing than out-of-the-box functionality, but less than fully-custom configurations. During co-production, your Pega team will guide you on the level of customization completed in system areas, which will inform the testing level needed.

Use testers who understand the business context

Involving your business users in the development process avoids building the wrong solution. You remove the guess work by looking at what the working software does during show and tell sessions, rather than comparing it to what was documented up front – this minimizes the testing effort.

After the development process, business users should test as building happens. They should be embedded in your project teams and can participate in creating user stories. If your business architect writes a decision table, then they should write the test for it. From there, you can build out your test cases based on each user story acceptance criteria with the system architects. Collaboration between your system architects, business architects, testers, and product owner is key to rapidly defining what the system does and how the system behaves end to end.

Test against acceptance criteria

It is common to have a level of separation between the developers and testers, which can take the form of a separate organization – or even company – to perform testing so that there are checks and balances in place. In these instances, it is important to involve the test leads in the DCO sessions and to ensure that they are seeing the playback sessions along the way. This helps minimize opinion-based defects caused by testers who don’t understand how individual pieces of functionality fit together. Having testers involved upfront also prevents unnecessary inflation of the overall testing duration, effort, and costs.

Leverage continuous testing and DevOps

When it comes to DevOps, our goal is to enable our application development platform to be open and automated from end to end. You can quickly set up a pipeline that streamlines your application development process from beginning to end. Pega connects to any standard DevOps third-party tools. You can take advantage of existing hooks and services based on standards for tools, such as Jenkins, Gradle, Selenium, and Jira. Having an automated test suite in your continuous delivery DevOps pipeline ensures that features and changes you deliver to your customers are high-quality and do not introduce regressions. For more on Pega’s DevOps capability, visit: https://pdn.pega.com/devops-pega-7-platform.

Leverage automated testing capabilities

PegaUnit lets you create automated rule tests, so you can easily create a suite of regression tests in your development environment. Unit tests run at the data object level and are not dependent on the screen UI. That means if the screen changes, the tests will continue to work.

Because unit tests are not UI based, they cannot give full system coverage. However, they do give us an inexpensive, partial regression test set for delivery with each sprint that can be rerun as subsequent sprints are delivered. This automated unit testing capability should be run as nightly regression tests during the build process to ensure your data, flows, case types, etc., operate as expected with the test cases. This reduces the need for retesting later.

For UI testing, Pega 7.5 and above allows you to capture, run, and manage UI functional tests inside an end-user portal without requiring you to write test scripts. You may also choose to leverage third-party tools, such as Selenium, for end-to-end UI testing.

Use the tools Pega provides

In addition to PegaUnit, Pega offers several tools to help you capture defects before they become real problems. Using these will save time in testing. Please refer to the Manage and monitor section above to learn about Agile Studio, guardrails, and Predictive Diagnostic Cloud (PDC).

16

Establish a formal governance process

Our last best practice is focused on creating strong, multilevel governance to keep you on track.

Generally, projects don’t get off track because of technology or an unexpected and unforeseeable event.

Two of the biggest pitfalls are:

• Failure to control scope. • Failure to efficiently deal with obvious issues.

Both of these can be avoided by having a regular multilevel governance process – a steady cadence of meetings to identify, resolve, and escalate issues as appropriate, with an emphasis on resolution at the lowest possible level.

Typically, these are structured as:

• Project level meetings – involves your team working on the project full time (especially the product owner) for approximately 15 minutes each day. The meeting focuses on work done, work to be done, and any blockers. It does not attempt to fix problems within the session as that would take time from everyone present, but flags problems for later discussion with a smaller and relevant subset of people – usually immediately after the meeting.

• Cross-department meetings – involves your project senior staff/team leads and typically focuses on how the overall progress is tracking, especially how the Pega enablement of your team is progressing.

• Program sponsor – typically held every two to four weeks and involves your sponsor, product owner, project manager, plus any other project leads. The review focuses on any issues escalated from the previous lower level meetings and how the overall project is tracking.

• Corporate – a periodic account level meeting to review interactions between the respective companies.

There may be other governance meetings depending on the nature of your organization and the project, but the above is a minimum set to have in place.

Multilevel governance is one of the most important things to have in place for a successful

project. It can keep the project on track and help resolve issues that could otherwise waste a

lot of time and money and potentially cause the project to fail.

Best practice tips: Focus governance on the issues that can cause a project to fail. Just talking

about an issue is not enough. It must be resolved at as low a level as possible or escalated.

Also use governance to regularly review the Pega tool reports – namely PDC and guardrails.

Sample Multilevel Governance structure

17

Summary

Delivery with Pega is intended to provide tangible ways for you to realize business value sooner, through efficient and effective delivery approaches. It provides specific guidance on how to leverage the capabilities in the product and industry best practices like Agile, continuous testing, and DevOps in a structured delivery approach. As Pega products are enhanced and evolve, and the industry best practices mature, so too will our delivery vision. We welcome your feedback, inquiries, and innovative ideas to improve aspects around the people, process, and tools to use on your “journey” with Pega. When you adopt these strategies and best practices, you too can achieve results like many other Pega clients. Here are just some of the real comments from our clients’ transformations:

“We originally spent nine weeks with six developers building an app. With Pega though, we managed to get two developers to do it in a week…. That’s the kind of velocity change we can get.” EU Communications Vendor

“We've got this data, we know when customers are going to churn. We know who's going to upsell, who's going to down sell, who's price sensitive, who's not. We had no way to operationalize that data and get it to customers. We took literally one weeks’ worth of developer time to take that data and make it into this really snazzy little popup that all of a sudden agents could start using. We're trying to take the agent away from finding data, to giving them what's relevant when they need it.“ BT

“The key thing for me is that this was one of the first times we changed the way we work. This was sitting down, this was prototyping with the agents in the room. It was quite a lot of fun, you could see a few people even laughing underneath it.” BT

“Software that writes your software is pretty cool. It brings the development up to a higher level, you're doing things that are a little more focused on what you're trying to accomplish, what your outcomes are, instead of where the semi-colons go.” CSAA

“We implemented automated regression testing scripts along the way. The regression testing, which was manual would take about a week – now, it happens in two hours. These are the things that help us be agile and agility is what helps you with continual improvement.” CSAA

“It was unrealistic to hope that the airline would change its organizational model and change the ways the silos work so that they could be reorganized around the customer experience. Whatever we did we had to make it work with the organization we had. The most important realization was, this had to be omni-channel. We realized we had to lift decisioning out of the channels. We couldn't hope to try and coordinate lots of independent decisions and channels and produce a cohesive experience for customers. Then what we found was, as you try and do that you're actually introducing a much simpler way of managing what you're trying to achieve for the customer.“ British Airways

18

Glossary

Agile Studio

A Pega-built agile project management system that enables your application development teams and your stakeholders to collaborate on features, plan your releases, and execute your development tasks by using the industry best practice Scrum methodology.

Case stage

A stage in a life cycle is a high-level phase that a case can enter at run time. By using stages, you can add structure to your case types or replace legacy implementations that rely on a central, complex flow.

Case type

A case type represents work in your application that follows a life cycle, or path, to completion. By using case types, you can reuse functionality from built-on applications, manage dependencies, and automate the tasks that your team performs in real life, such as requesting approval from a manager or sending correspondence to stakeholders.

Customer journey

A series of actions required end-to-end to achieve a specific outcome. It may involve:

• A consumer, business user, or employee.

• Product(s) and segment(s).

• A single channel or omni-channel.

• Multiple case types and/or decision strategies.

• Handoffs between multiple people and have multiple paths to resolution.

Directly Capture Objectives

The Pega tools, process, and mindset for using Pega Platform as an integrated solution for capturing objectives, requirements, draft flows, draft UI, use cases, and reusing these individual components over and over through the delivery methodology.

Definition of done

A set of rules that are applicable to all user stories. In Agile Studio, a definition of done can be created for each project team and is visible during sprint planning and resolution. At a sprint review, a product owner should not accept a user story unless it meets the definition of done and the acceptance criteria on that story.

DevOps

DevOps is a culture of collaboration by development, quality, and operations to address issues in all three spaces. A continuous integration/continuous delivery pipeline is an automated process to quickly move applications from development through testing to deployment. Pega Platform includes tools to support DevOps, keeps an open platform, provides hooks and services based on standards, and supports most popular tools.

No Code/Low Code

Low-code application development platforms employ visual, declarative techniques instead of programming – however there is still the need to translate the requirements into the language of the computer. No code software translates your visual requirements into code – in real time – in the background, allowing innovation to occur in a language that both business and IT understand.

19

Product owner

The PO is the person who has final say in representing the customer's interest in the prioritization of stories in the backlog and the review of stories for acceptance as the teams implement them in sprints. In Agile Studio, users can be added as product owners to various items, including products, releases, goals, epics, backlogs, and teams.

Predictive Diagnostic Cloud

PDC is securely hosted on Pega® Cloud, to capture alerts from your test and production systems in a real-time, secure, listen-only mode. PDC then intelligently aggregates and analyzes issues over a time line to predict business impact and establish urgency of what items to address and when – it complements traditional application performance monitoring tools. It is designed to help you find and fix issues before they affect your customers’ experience.

Rule

A piece of business logic that defines how a business decision is made or how a business process is carried out.

Scrum

An Agile development methodology in which work is completed over a number of sprints (a time-boxed period in which the team implements and delivers a set of user stories and bug fixes).

Specification

A specification represents a unit of processing that is performed by one or more actors for a given case type within an application. In other words, a specification defines what an application does.

Technical debt

Typically, bugs or unaddressed refactoring work that the product or team accrues over time.

User story

A requirement that is expressed in brief, non-technical language with a set of acceptance criteria. A user story should be small enough for a team to implement in one sprint. Stories are groomed in a backlog, and when ready, pulled into a team's sprint. Once in the sprint, stories can be broken down into tasks.

© Copyright 2018 Pegasystems Inc. All rights reserved. All trademarks are the property of their respective

owners. The information contained in this press release is not a commitment, promise, or legal obligation to

deliver any material, code or functionality. The development, release and timing of any features or functionality

described remains at the sole discretion of Pegasystems. Pegasystems specifically disclaims any liability with

respect to this information.

2018-06