Wednesday, November 27, 2019

Agile lifecycle in TxS
==================

1. Discovery workshops to clarify scope.
2. High level Pega estimates by Pega team (Pega Design Council) - Epic level (in terms of both T Shirt sizes and man days).
3. User story mapping and Release planning sessions.
4. Sprint Planning.
5. Daily standups, Refinement sessions (Every wednesday), Sprint Review (Fri 3pm to 4pm), Retro (4pm to 5pm).
6. Scrum of Scrums [TxR Upstream and downstream] daily 9:45am, standups daily 10:15am to 10:30am.
7. Release Train Scrum of Scrums every Tuesday 2:30pm to 3:00pm.

For Agile Release Train [ART]
======================

o Establish and embed SAFe framework to manage scope, delivery, quality and resources.
o Employ Scrum at team level to reinvigorate team, bring about trust & empathy, transparency and clarity of purpose.
o Coordinate activities in preparation for PI Planning – Backlog with epics, features, stories.
o Coordinate in-PI-planning, dependency management and presentation.
o Plan and coordinate Sprint 0 activities such as initiation, elaboration, architecture, etc.
o Coordinate customer journey mapping and User Story Mapping
o Help team in defining MVP, Release plan, sprints, etc.
o Facilitate sprint planning, daily stand ups, Sprint Review and retrospective.
o Managing program board, dependency management with stakeholders.
o Stakeholder communication, management reporting, etc.
o Manage team conflicts, challenges; escalate where necessary.

Personalised Rates Workflow


Root Cause Analysis ( RCA )

RCA comprises the techniques and tools to uncover the underlying causes of problems. 
  • Most common is 5-Whys?
    • When you have a vast amount of data:
      • Do a 80-20 Pareto chart to identify the 20% causing the defects.
      • Do a 5-Why on the 20% based on the defect categories.
  • Fish Bone / Ishikawa Diagrams










* Images may be subjected to copyrights. I don't hold the rights.

Defect Triage

Defect Triage is process of determining the priority of a defect based on their severity. Severity is raised by the software tester. A decision on priority is made collectively in conjunction with the Product Owner. 

1. Is this a valid bug?
2. Is this bug reproduceable?
3. Is this bug worth to fix in the present sprint / can it be deferred?
4. If it has to be fixed, then When? 


Defect resolution in TXS, sample user story

  • Acceptance Criteria was written for each user story in the BDD format (Given - When - Then).
  • Testers wrote Functional tests based on the acceptance criteria. 
  • Developers wrote code for US, unit-tested the code, uploaded the artifacts in Pega.
  • Testers ran the functional tests, logged defects / findings.
  • Testers ran Defect Triage. 
  • Defects categorised, prioritised and the fixed. 
  • Defects re-tested and closed.
Sample User story with Acceptance Criteria.

Business Scenario

Toyota customers will get Toyota personalised interest rates Online for New Vehicles they are interested to finance which can be used by contacting toyota dealerships for Quote/Application processing. 

Description

As a Digital Marketing Manager

I want online guests to fill an online TXR form which will collect their personal information
so that TXS can offer them personalised rate based on their credit score / risk based price rate.

Acceptance Criteria #1- Create TXR Case

Given a request to obtain customer TXR is recieved 
When BOOMI triggers request TXR service call
Then Create a TXR case which is associated to customer record
AND all the information associated to TXR request should be recorded
AND Expiry of TXR case should be same as Credit score validity 

Acceptance Criteria #2- TXR case_Error Handling

Given a request to obtain customer TXR is recieved 
When TXR case creation failed 
Then Error message should be sent to BOOMI about transaction failure 

Technical Details

1. Create Case Type 
2. Create Case Fields and skeleton 
3. Create Case stages 
4. Define case Status (Open, Resolved - Expried (When credit score is expired))

Data from TXR online forms and additional details will flow from 
T-Bone--> BOOMI--> Pega

First Name
Last Name
DOB
DL#
Address  with Sensis SA1 value
Contact details (email, telephone)
Marital status
Residential ownership
Co-applicant Y/N
Consent to obtain credit score
Vehicle Details
Dealer ID
GUID

(Above is not the entire list of fields and there are more fields expected as part of Create TXR service call) 
- Complete list of fields from TXR call are covered as part of US-2783

Dependency 

Awaiting sample request XML from BOOMI

1. Field Mapping across systems ( T-Bone -> BOOMI -> Pega)
2. Request authentication 

Assumption/Facts

* All field validations to be implemented at T-Bone end (pega validations list to be provided) 
* TXR requests are applicable only for individual borrower types 

If we already have automation, what's the need for Agents?

“Automation” and “agent” sound similar — but they solve very different classes of problems. Automation = Fixed Instruction → Fixed Outcome ...