4 Values and 12 Principles of Agile

Fields in a bug report

Fields of a bug report

1. Bug ID

2. Bug description and what happens

2. Steps to replicate

3. Where the bug is noticed ( module, page etc.)

4. Severity of the bug

5. Screenshot

6. Bug raised by (Tester).

Process to create test scripts...

• Get a thorough understanding of the application under test -- either through documentation, or from BA/ product owner or the team. 
• After an understanding of the application and the requirements, identify the scenarios/ risk areas which then give an idea of what to test. 
• Once the scenarios are clear, decide on the test cases and test data.
• Write the test scripts
• Get these reviewed
• Executive the test scripts, report bugs.
• Work with Dev team to close the bugs.
• Report on the bugs and closure.

Mortgage Process

Test Process Improvement (TPI)

TPI is owned by Sogeti.

My insurance claims

• Medical Insurance Purchase
• Research insurance options
• Cost benefit analysis based on monthly 
• Apply for insurance online; submit relevant documentation
• Call customer and confirm.
• Review for completeness of documentation, if not request correction. 
• Check eligibility, policy details, benefits, etc. approve / reject application.
• Communicate to customer - send welcome package.
• Arrange for and deduct monthly insurance. 
• Medical Insurance Claim - cashless
• Get docs from doc.
• Submit claim online; submit documentation.
• Review claim and documentation; request further details if required.
• Based on claim type, disease, and the claim amount, initiate cashless.
• If not inform customer of lack of cashless and how to initiate reimbursement with bills.

TMMI

The Testing Maturity Model (TMM) was based on the Capability Maturity Model, and first produced by the Illinois Institute of Technology. [Wikipedia]

Insurance Claim Lifecycle

AirBnB Workflow

Hotel Reservation System - Workflow

WINIT - Web Application Process, Testing

Web Applications -- ASP.NET ; for a couple of Desktop Apps, C# and VB.NET was used.
================================================================

Lakeplace --- booking reservations for small motels near lakes
AAXA ---- Cargo transportation & logistics
Fine Tuxedos -- online Tuxedos sale
Etc.

1. Client interactions / comms -- requirements gathering.
2. Define workflows / business logic
3. Wireframes [sketching, dreamweaver / frontpage, photoshop]
4. Style guide ---
5. Front End design -- ASP.NET, PHP, SQL (Own 3 tier architecture that dev were supposed to follow).
6. Backend Dev
7. Paypal integration
8. UI and Functional Testing
9. Client review every couple of days.

-- No formal test strategies.
-- No formal test planning either
-- Manual testing
-- Write test cases based on workflows
-- Test, raise bugs, get them closed by dev, report bugs
-- Test paypal integration

Paypal Integration Testing...

1. Get details of dummy credit card
2. Checkout button --> Paypal --> Paypal gateway processing --> Back to your website
3. Check for session expiry, session ends.
4. Check what happens if Payment Gateway stops responding.
5. Check for data going to the backend.
6. What happens upon successful transaction -- database, messages, etc.
7. Check receipts are generated and sent to customer email account

Agile Conflict Resolution

Conflict resolution

==============

Telstra

--------

W was a product owner for one of my teams in Media. I noticed that he was increasingly getting himself excused from user story refinement sessions, beginning to withdraw. This was also the time when there were interactions with the senior management in media around team restructuring (feature teams). 

One fine morning W summoned me to his 20th floor office. The moment he saw me, he turned red faced. The moment we went into a meeting room, he blasted me off. For the next 15 minutes he vented his ire. He seemed to harbour a fear that his job is on threat. And that I as an Agile Coach / Scrum Master was conniving with the senior management to throw him out. 

There was a context to this. Telstra was going thru a gigantic transformation exercise. Age old team structures were being taken down to reorganise people into meaningful cross-functional teams. 

I patiently heard W. Apologised to him if there was any misunderstanding. And now that he was at ease after letting himself out, I started putting forward the background of what was happening. 

1. What are your concerns / fear?

2. In your opinion how could we have approached this?

3. Is there a better approach you think could assuage you and other people?

4. Let's agree to a way of communication going forward. I want to be honest with you, and expect the similar honesty from you. 

It was then W came out with the fact that he was caring for a dying mum, and his emotions were getting mixed with the uncertainty times in the office.

After the matter was resolved, an hour later I receive an email where W officially apologised for his behaviour.

Common Agile Metrics

• Lead Time
• Cycle Time
• Sprint Burndown - tells us how much value has been delivered.
• Sprint Velocity
• No. of deployments to prod
• Average time to prod.

DoR and DoD in TxS...

DOR in TxS
==========

1. User stories written in As a < type of user >, I want < some goal > so that < some reason >.
2. Acceptance Criteria written, and in BDD format - Given, When, Then.
3. User stories approved by PO.
4. User stories prioritised by PO.

DoD in TxS
==========

1. Development is complete.
2. Pega unit is complete
3. Code reviewed.
4. Relevant comments and attachments made.
5. Dev QA complete
6. ZSIT / IT complete
7. System Testing complete
8. UAT complete (based on TC provided by business).
9. No open Sev 1/ Sev 2 bugs.
10. US approved by PO.

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 

Defect severity and priority

• Priority of a bug is the urgency of need to fix the bug.
• Severity of a bug is the impact it has on the system. 

Severity
--------
S1 - Critical: Defect affects critical functionality / data. No workaround.
S2 - Major: Defect affects major functionality / data. Has workaround, but is difficult / complicated.
S3 - Minor: Defect affects minor functionality / non critical.
S4- Low: Does not affect functionality or data. No need for a workaround.
S5 - Cosmetic: Defect affects only the look & feed, but not the functionality.

Priority
---------
P1 -- High: Defect must be fixed ASAP.
P2 -- Medium: Defect can wait until the next build / release.
P3 -- Low: Defect can be deferred until a more serious defect is fixed. 

Airbus - HP Quality Centre 9.2 Central Administration

Software Bug Lifecycle

In TxS, the lifecycle was simple:

1. New
2. Open
3. Assign
4. Fix
5. Reassign
6. Resolved-Closed

V Model - Classical Lifecycle

• Requirements Analysis -- Business requirements document or business requirements specification
• System Design -- Systems requirements specifications / functional specification
• Architecture Design -- High level design
• Module Design - Low-level design

Shift Left (Courtesy BMC)

Shift left is a software testing approach where software testing is performed (moved or shifted) to the left / earlier in the Life-cycle. This basically is "Test Early and Test Often".

• In the Traditional Model, requirements and design happen to the left, and testing of those requirements to the right. As the project progresses, the testing effort increases. 
• Consequently later the defects are found, the costlier it becomes to fix those bugs

• In Shift Left, testing is performed during early stages by engaging early in the project lifecycle. 

JavaScript Object Hierarchy - CERN European Particle Physics Laboratory

TXR Test Planning & Execution

7 Principles of Software Testing...

Leadership coaching skills --

As a coach, you should be:

Tools for retrospectives

1. Confluence
2. Funretro.io
3. Mural
4. 
   

Who kickstarts Agile Transformation defines it's success!

Usually the Executive 

Coaching vs. Consulting... Mikhail Stepanov

Prioritising Requirements

• Kano Model
• Priority Matrix

Moscow Model

Pega Case and Case Types

Pega Case

Pega Case Type

Case Lifecycle Design Model

The Iron Triangle

Agile Project Management -- when Agile projects are constrained by all the three parameters -- Cost, Time and Scope. 

Sayings about Culture...

• Culture is what happens when you are not looking.
• When you see something that is below standard and do nothing, then you have set a new standard.

Dimensions of Trust - Seapointcenter.com

SAFe Requirements Model... (Source: SAFe Agile Portal)

Sample Epic, feature and US

Campaign management -- Epic
==========================

Features
========
1. Set up campaign
2. Run campaign
3. Gather campaign stats

User stories under set up
======================

Create campaign specific to MDA brand
Review and publish MDA brand campaign requests

============================================================
============================================================

Create ZS pega sales portal [EPIC]
=============================

Features
========
1. Create base portal
2. Portal delta (set of additional features)

Stories under base portal
=========================

1. Set up base portal from Quantum

Stories under Portal delta
==========================

2. Ability to select MDA fin options for trade-in details
3. ZS provision to capture 3rd party supplier details
4. Update TSS field reference

Lean startup - Image (Dave Landis)

Behavioural questions -- Kirsty Bonner

• Tell me about a challenging client-facing situation and how you handled it.
• Provide an example of a time when you personally demonstrated ownership.
• Give me an example of a time when you faced a conflict whilst working on a team. How did you handle that?
• Give me an example of a time when you had to challenge a management decision.
• Tell me about a time when you had to quickly adjust your work priorities to meet changing demands.

Human Centered Design

• Creative approach to problem solving.
• Places customers at the center (a way of working and thinking).
• Design from their perspective.
• Introduces
• Collaboration.
• Empathy.
• Problem re-framing.
• Evidence-based decision making.
• Experimentation.
• Needs these
• Curiosity
• Optimism (See problem as an opportunity)
• Mindset to learn
• Creativity

Complexity Theory in Organisation Theory and Strategy - David L. Levy, Wikipedia (Courtesy)

1. "A System is a group of interacting or interrelated entities that form a unified whole. A system is de-lineated by its spacial and temporal boundaries, surrounded and influenced by its environment."
1. A System may be -- Simple, Complicated, Complex or Chaotic. (Below from noop.nl)
2. Simple -- Easily knowable [A Car key is simple]. Fully predictable.
3. Complicated -- not simple, but still knowable [A Car is complicated]. Fully predictable.
4. Complex -- not fully knowable, but reasonably predictable [Car traffic is complex. "I can travel up and down the same street for twenty years, and things would be different every time. There is no way to fully understand and know what happens around me on the road when I drive, how other drivers operate their vehicles, and how the people in the streets interact. I can make guesses, and I can gain experience in predicting outcomes. But I will never know for sure."]
5. Chaotic -- neither knowable nor predictable [Car traffic in Lagos is chaotic (not even predictable)]

In software, the following can be said of the above:

1. "A complex system is a system composed of many components which may interact with each other. Examples of complex systems are Earth's global climate, organisms, the human brain, infrastructure such as power grid, transportation or communication systems, social and economic organizations (like cities), an ecosystem, a living cell, and ultimately the entire universe."
2. "Complexity characterizes the behavior of a system or a model whose components interact in multiple ways and follow local rules. This means there is no reasonable higher instruction to define the various possible interactions."
3. Complexity Theory and Organizations: also called Complex Adaptive Systems is the use of study of Complex Systems in the field of strategic management and organizational studies.

Characteristics of Complex Adaptive Systems (CAS)

=========================

> Self organization

> Complexity

> Emergence

> Interdependence

> Space of possibilities

> Co-evolution

> Chaos

> Self-similarity

CAS has implications on:

• Organisational Management
• Project Management
• and more

How it affects:

> Advocates culture of trust

> learning orgnization

> Promote cooperation

> Embrace new ideas

> Focus on flatter, flexible org (rather than top down or command & control hierarchies)

Components of Complexity Theory includes:
=====================

• Chaos Theory: Chaos theory studies dynamics of turbulence in flow of liquids (Lorentz). Similar problem arises when trying to calculate path of an object pulled by two different objects (as in a planetary body attracted by two or more suns. Simple Newtonian mechanics can predict motion of an object around another, however when the motion is affected by two or more objects, you can no longer predict the path accurately over long intervals. For e.g. when a metal ball suspended over two or more magnets, the ball traces series of patterns that never exactly repeat themselves, yet are not totally random). 

The paradox here is the motion of the metal ball is driven by the same Newtonian equations as well as the understood case of a single gravitational attractor. According to Newtonian mechanics, if we know the location, speed and direction of an object, we should be able to predict the path of an object with reasonable accuracy. However, not in this case. The paradox is that a deterministic system gives rise to unpredictability. Tiny variations in the motion of a ball, over due course of time compound and result in a massive divergence [Butterfly Effect]. The chaotic behavior is a result of this.

• Networks Theory: 

Deterministic System - Wikipedia

In mathematics, computer science and physics, a deterministic system is a system in which no randomness is involved in the development of future states of the system. A deterministic model will thus always produce the same output from a given starting condition or initial state.

In philosophy, determinism is applied to understand everything that has or will occur in the system,  based on the principles of causality. In a deterministic system, every action, or cause produces a reaction, or effect and every reaction, in turn becomes a cause of subsequent reaction. The totality of these cascading events can theoretically show exactly how the system will exist at any moment in time.

Books that take a critical view of Agile

1. Questioning Extreme Programming - McBreen
2. Extreme Programming Refactored - The Case Against XP - Stephens and Rosenberg
3. Balancing Agility and Discipline - Boehm and Turner
4. Agile - The Good, the Bad and Ugly - Bertrand Meyer

Scrum Blockers - Michael Kusters

Theme, Initiative, Epic, Story -- Atlassian

Courtesy - Atlassian

• Themes are large focus areas that span the organization.
• Initiatives are collections of epics that drive toward a common goal.
• Epics are large bodies of work that can be broken down into a number of smaller tasks (called stories).
• Stories, also called “user stories,” are short requirements or requests written from the perspective of an end user.

Note: At Telstra, work was defined at Initiative level (A Funded Block of Work).