Posted: 4 Mar 2021 16:19 EST Last activity: 5 Apr 2021 16:04 EDT
Ask the Expert - Pega Express - The Build Phase
Join Ralph Booth @RalphBooth and Dion Lammers @DionLammers as they answer your questions in our third session of Pega Express Ask the Expert series!
Save this to your Favorites and be prepared to join us for our 3-week session March 15th - April 5th here in the Pega Collaboration Center!
Ralph has 20 years experience in Operational and Project roles. Currently, as Pega Express Director he focuses on guiding and empowering project to teams to design, build, and deliver lovable solutions.
Dion Lammers is a Partner Success Technical lead and in this role he helps partners achieve delivery excellence and improve practice capability by providing technical knowledge and delivery leadership. He is responsible for driving the adoption of Pega 8 in the developer ecosystem, drives the global CLSA Community of Practices and a speaker in ecosystem meetups. Dion has been working for Pega for 10 years of which the first 9 at Pega Consulting as Lead System Architect and later Principal System Architect,supporting a number of large Pega implementations.
Message from Ralph and Dion:
Hi Everyone, we are excited to be answering your questions about the Build phase of the Pega Express approach!
This phase is where the sprints kick in and you start configuring and testing your user stories. This is often everyone's most favorite phase as, you generate real energy and momentum, so we look forward to hearing from your and reading your Build methodology questions in the collaboration board!
We are a small team getting some development time in Pega under our feet, we have some likely basic questions that perhaps we can get some answers
Is there an out of the box method I can use to allow one member to assign a case to another member for the next stage of work? We are attempting to use the 'Transfer Assignment' step but haven't nailed down it's behavior yet
If a case is transferred to a specific user does/should it go directly to their worklist?
we are trying to end a stage by letting the current user choose who to assign the case to, and then notify the new assignee that a case has been assigned to them
Great for reaching out with your questions and that you and the team are trying to master Pega. I would urge you to create questions in the collaboration center for the things you seek assistance with as there generally you get a quicker response and this 'Ask the Expert' is more focussed around the Pega Express Delivery Approach.
I am not really sure what the starting position is but assuming that you have an assignment step in side a case and you want to be able to transfer the assignment to another operator. So you can make use of local actions as extra options inside a process. That will allow you to add a flow action to transfer the assignment to someone else.
So if you open the process in that stage: When you have the process open you can double click the assignment and in the modal window scroll down to advanced and then open local actions. Use pyTransferAssignment as an OOTB transfer flow action.
Then when you run your case and you reach the process, you can actually open the actions dropdown where you will see the transfer assignment. Clicking that brings you to this action and you can assign it to someone else.
If you just want to change the stage, then you dont need to do anything as there is an OOTB action for that available. When you transfer the assignment, after the submit then it will be immediately placed in the worklist of that operator.
Regarding the notification; there is an OOTB option to use for this. On the case, go to settings and select notifications.
Regarding the requirement to decide at the end to whom to assign the assignment to; it might be easier to use a workbasket for a team. That way anyone can pick it up without explicitly assigning to someone. Either by people taking it from the list (pull) or by using get next work (push).
@DionLammers that's a great question and Pega Express is perfect for this scenario. Once you identify your enhancements you can bring them into your next Directly Capture of Objectives (DCO) session to be elaborated and translated into user stories. Check out our Pega Express Academy Couse for more information on this.
Then get them to the definition of ready and approved by your Product Owner ready for prioritization. Once they are prioritized for a sprint, they can be quickly configured and tested, ready for production deployment.
Depending on the priority of the enhancements you may choose to go live quickly and deploy them immediately into product, or depending on your organizations release cadence they may be deployed along with other changes.
The key thing here is Pega Express creates a way of working to ensure you constantly monitor your application, identify improvements and then ensure they are quickly prioritized into production.
Just to kick off, I wanted to give an overview of the best practice around application structure.
How we manage applications and application structures has evolved a lot over the last few years. In the past, we used to create whole applications as frameworks and then build an implementation layer on top of that with all our work classes inheriting from the framework application. While there are still valid use cases for such a setup, the approach that we are taking now is one where we create smaller applications and use (business) components that can be plugged in via the build-on application feature.
When branching was introduced and started to become more widely used, developers would create branches directly in their implementation layer applications and then merge or remove those branches immediately prior to packaging the application for deployment. As automated testing becomes more prevalent on development teams, similar questions come up about which application should own those testing rulesets.
The way forward for dev teams is to use a three application approach for development:
A development application, built on top of a testing application, built on top of your production application. The dev app is where your branches go. The testing app is where your test cases, test suites and testing support rules (like supporting data transforms, activities, simulations) go. The production app is what you can package and ship to production after routing that app through QA, UAT, etc . The idea is that your production app should always be ready to go at a moments notice. Using deployment manager, you can even trigger an automated deploy to your QA region on merge, so having a clean production app at all times can allow this to happen.
Keeping your testing app separate from your production app and your dev app gives you the ability to deploy the testing app to other environments in order to validate your deployment, but you can also keep from deploying the testing infrastructure to prod unless you want to. Also, with your testing infrastructure in a separate app, you also have the ability to apply simulations without the risk that your overrides become part of your production app and mess up a production deployment.
Yes, I can share some thoughts on the Definition of Done and how to assure that the user stories are brought to done in our build phase.
Obviously, the concept of ‘Definition of Done’ (DoD) is important in Scrum and focusses on defining what “done” actually means. Within a team people can easily have different views on what it means for work to be completed. In short DoD is a shared understanding within the team on what it takes to make your Product Increment -in this case the user story- releasable.
And while DoD is a Scrum best practice, Pega Express meets and extends this by delivering us tools and best practices to support it.
There is however not a single version of a DoD; what good looks like depends on the project, the team and the client context.
There are three important components in the DoD:
This talks about the business value that the functionality should bring. The DoD needs to always include checks that all the acceptance criteria are met. There are multiple ways to do assure this. Possible actions here are:
Prepare a show and tell for the business users
Approval of the product owner as a signoff that the user story is functionally complete
Test scenario proofing that the acceptance criteria is met
Testing the user story is very important. My strong advice is when you start designing how to implement a story that you directly define what needs to be tested and proofed and how you will test this.
And as the functionality when passing DoD is releasable, a great feature is toggles inside of Pega. This would allow to directly have the functionality deployed to production but not made available to the business users yet. Then with the toggle the business owners can decide when they want to make this feature available.
In any software delivery high quality software is crucial for long term success. You don’t want to start with instant technical debt as you know this will carry along for a long time. In Pega we have some great quality tools to support, like the test automation features such as Pega unit test or the quality dashboard that will provide insight into the compliance score (guardrails) and the test coverage. Good actions for the DoD here are:
Test automation case are created and tested
Implementation is peer reviewed and/or a merge review is performed
Nu unjustified guardrails (and a proper justification does not state ‘as per requirements’ but it gives a business reason why this guardrail warning cannot be prevented)
Regression test successful (to proof your added functionality doesn’t break anything else)
Although this could be added under the quality category, it is often missed and therefore important to explicitly call it out. These talks about the standard characteristics or attributes of the product that might not add direct business value but without it cannot be released. It defines system attributes such as security, reliability, performance, maintainability, scalability, and usability; they serve as constraints or restrictions on the design of the system. You can find some of this written down as acceptance criteria, for example about the performance of a screen refresh.
Security is an important topic to mention. Every delivery must leverage the security checklist as this provides Pega's leading practices for securely deploying applications. But for the DoD it can prove helpful to add actions such as:
Perform rule analyzer (RSA) in case of custom code.
Add privilege to all applicable rules
Check security events for changes in the security administration
Extend the role to control access for the new functionality
As said, there is one size fits all. But when you make sure these three categories are taken into perspective with the whole Scrum team in the context of the client, then you will be able to assure a strong DoD. And its not something that is set in stone; its there to help you as a team to assure the functionality is done. If it doesn’t work, has too fine grained checks, you can adjust it.
But one thing is crucial; if the story does not meet the Definition of Done, it is not done!