SDLC SOP Gap Analysis: v1.0 to v2.0
| Field |
Value |
| Date |
7 April 2026 |
| Author |
Daniel O'Reilly, Chief Digital Officer |
| Classification |
Class 2 (Confidential) |
| Purpose |
Document all changes between SP-SOP-SDLC-2603 v1.0 and SP-SOP-SDLC-0704 v2.0 |
1. Executive Summary
The SDLC SOP v1.0 (SP-SOP-SDLC-2603), written by CTO Saqlain Raza on 18 March 2026, was designed for an organisation structured around product-line development teams with a separate SQA function, two-week sprint cycles, manual CAB approvals, and waterfall-style Jira gates. Following the appointment of the CDO and the restructure of the technology organisation into seven tribes, v1.0 no longer reflects how Simpaisa builds and ships software. Version 2.0 (SP-SOP-SDLC-0704) replaces it entirely with a Kanban-based continuous delivery framework, engineer-owned testing, automated pipeline gates, daily deployment capability, and role definitions mapped to the new tribal structure. This gap analysis documents every material change to support the transition and provide an audit trail for regulatory purposes.
2. Document Comparison Table
| v1.0 Section |
v2.0 Section |
What Changed |
Impact |
| 1. Executive Summary |
1. Executive Summary |
Rewritten to reflect AI-native, no-project, Kanban model. Removes references to sprint-based delivery. |
Framing |
| 2. Objectives |
2. Objectives |
Replaced generic objectives with seven specific, measurable objectives (daily deploy, engineer-owned quality, shift-left security, DORA metrics, no-project model, regulatory traceability, AI-native). |
Strategic alignment |
| 3. Scope |
3. Scope |
Expanded to explicitly name all five products (Pay-Ins, Pay-Outs, Remittances, Portals, Cards), all seven tribes, all markets, and all tooling. v1.0 scope was generic. |
Clarity and completeness |
| 4. Governance Principles |
4. Governance Principles |
New section. v1.0 had no explicit governance principles. v2.0 codifies: no-project model, AI-native engineering, automation over approval, ownership over handoff, transparency by default. |
Foundational change |
| 5. Roles (Product, Engineering, Architect, QA, DevOps, DBA, InfoSec, Service Delivery) |
5. Roles and Responsibilities |
Complete restructure. Eight role-based sections replaced with seven tribe-based sections plus cross-cutting Architecture function. QA role eliminated as a separate function. |
Organisational redesign |
| 6–16. SDLC Phases (11 phases: Requirement → Feasibility → Design → Security Review → Development → QA → UAT → Production Readiness → Deployment → Post-Deploy Monitoring → Handover) |
8. SDLC Lifecycle Phases (9 phases) |
Reduced from 11 to 9 phases. Feasibility merged into Discovery & Spike. QA and UAT eliminated as separate phases. Production Readiness merged into Deployment. Handover eliminated (no handoff model). Security Review moved before Development (shift-left). |
Streamlined lifecycle |
| 17. Release Governance |
10. Release Governance |
CAB eliminated. Manual approval replaced by automated pipeline gates. Feature flags introduced for risk management. |
Release velocity |
| 18. Compliance/Audit |
14. Compliance and Audit |
Strengthened with automated traceability chain (Jira → PR → Pipeline → Deployment). PCI-DSS and DFSA sections added with specific evidence requirements. |
Regulatory readiness |
| 19. Jira Workflow |
11. Jira Workflow |
Waterfall gate columns replaced with five Kanban flow columns (Backlog → Ready → In Progress → In Review → Done). WIP limits introduced. Approval gates removed. |
Workflow simplification |
| 20. Sprint Governance |
6. Delivery Model |
Two-week sprints replaced with Kanban continuous flow and 10-day cycles. Sprint planning, sprint review, and daily standups eliminated. Retrospective, Demo, and Grooming consolidated on Day 10. |
Delivery model change |
| 21. Exception Handling |
16. Exception Handling |
Expanded to cover three specific exception categories (regulatory emergencies, critical security vulnerabilities, P1 incidents) with concrete workflows. Added formal exception request process with CDO approval. |
Governance maturity |
| 22. Continuous Improvement |
18. Continuous Improvement |
Added quarterly SDLC retrospective, process change management procedure, and maturity model. v1.0 had a generic continuous improvement statement. |
Process discipline |
| 23–25. Approval |
20. Approval and Adoption |
Added phased adoption timeline with specific milestones and dates. Training plan included. |
Implementation clarity |
| - (not in v1.0) |
7. Work Hierarchy |
New section defining Initiative → Epic → Story → Task hierarchy with Jira types and ownership. |
Work structure |
| - (not in v1.0) |
9. Hotfix Process |
New section with dedicated emergency path, reduced approvals, mandatory post-incident review. |
Incident response |
| - (not in v1.0) |
12. Definition of Done |
New section with 10 explicit criteria per Story. v1.0 had no formal DoD. |
Quality bar |
| - (not in v1.0) |
13. Testing Strategy |
New section defining test pyramid, coverage targets (80% unit), and explicit prohibition of manual QA sign-off. |
Testing model |
| - (not in v1.0) |
15. Architecture Decision Records |
New section with ADR template, when-to-write criteria, and ARB review process. |
Architecture governance |
| - (not in v1.0) |
17. Metrics |
New section defining DORA metrics, flow metrics, quality metrics with specific targets. |
Measurement |
| - (not in v1.0) |
19. Supersedes |
New section explicitly recording that v2.0 replaces v1.0 with reasons. |
Audit trail |
3. Fundamental Model Changes
3.1 Sprints → Kanban
| Aspect |
v1.0 |
v2.0 |
| Delivery model |
Two-week sprints |
Kanban continuous flow with 10-day cycles |
| Planning |
Sprint planning at start of each sprint |
Continuous grooming; formal grooming on Day 10 |
| Commitment |
Sprint commitment (stories committed at planning) |
No commitment; pull-based system with WIP limits |
| Review |
Sprint review at end of each sprint |
Demo on Day 10 of each cycle |
| Retrospective |
Sprint retrospective |
Cycle retrospective on Day 10 |
| Daily standup |
Daily standup meeting (mandatory) |
No daily standups; async updates via Jira |
| Velocity |
Story points per sprint |
Throughput (stories per cycle), cycle time, WIP age |
| Forecasting |
Sprint velocity |
Cycle time distribution and throughput |
Rationale: Two-week sprints create artificial urgency and batch-processing behaviour. Engineers rush to finish "committed" stories by sprint end, then idle while waiting for the next sprint to start. Kanban eliminates this waste. Continuous flow with WIP limits optimises for lead time reduction and consistent throughput.
3.2 Separate QA → Engineer-Owned Testing
| Aspect |
v1.0 |
v2.0 |
| Who tests |
Dedicated SQA team (7 people) |
Solution Engineers who write the code |
| Test type |
Manual QA + some automation |
Automated test pyramid (unit, integration, E2E) |
| QA gate |
Manual QA sign-off required before release |
No manual QA sign-off; pipeline is the gate |
| Coverage target |
Not specified |
80% unit test coverage per service |
| QA team |
Separate SQA tribe (Head SQA, SQA Lead, 5 SQA Engineers) |
SQA team members transition to Production Engineering |
Rationale: A separate QA team creates a handoff bottleneck and reduces engineer accountability. When engineers know a QA team will catch their bugs, test discipline erodes. Engineer-owned testing means the person who writes the code is accountable for its correctness. The former SQA team's skills are redeployed to Production Engineering (monitoring, incident response, automated test infrastructure).
3.3 Manual Approval → Automated Pipeline Gates
| Aspect |
v1.0 |
v2.0 |
| Release authority |
Change Advisory Board (CAB) |
Automated CI/CD pipeline |
| Approval process |
Manual sign-off by CAB members |
Pipeline stages pass/fail automatically |
| Release manager |
Required |
Not required |
| Release form |
Manual document signed by stakeholders |
No release form; pipeline log is the record |
| Deployment frequency |
Gated by CAB schedule |
Daily (target: ≥1 per tribe per day) |
| Rollback |
Manual process |
Automated within 5 minutes |
Rationale: CAB approval is a bottleneck that adds days of lead time without meaningfully reducing risk. The evidence is clear from DORA research: organisations with automated deployment pipelines have both higher deployment frequency and lower change failure rates. Manual approval creates a false sense of control while actually degrading quality by batching changes into larger, riskier releases.
3.4 Waterfall Jira → Kanban Board
| Aspect |
v1.0 |
v2.0 |
| Board type |
Scrum board with approval-gate columns |
Kanban board with flow columns |
| Columns |
Multiple gate columns (Awaiting QA, Awaiting UAT, Awaiting CAB, etc.) |
Five columns: Backlog → Ready → In Progress → In Review → Done |
| WIP limits |
Not enforced |
Enforced per column per tribe |
| Flow visibility |
Obscured by gate columns (work sits in queues) |
Clear (work flows or is visibly blocked) |
| Aging |
Not tracked |
WIP age tracked; items >5 days flagged |
Rationale: Gate columns in Jira disguise queuing time as "progress." A ticket sitting in "Awaiting QA Sign-Off" is not progressing - it is waiting. Kanban makes wait time visible. WIP limits force teams to finish work before starting new work, reducing context switching and improving flow efficiency.
4. Role Mapping
4.1 Old Roles to New Tribes
| v1.0 Role / Team |
v2.0 Tribe |
Change in SDLC Responsibilities |
| Portal Development Team (Iqbal Butt → Selina Wilson → 5 developers) |
Solution Engineering |
No change to development work. Now responsible for writing own tests (no QA handoff). PR requires 2 approvals. |
| Pay-Outs Development Team (M. Khizer → Mawaiz Akram → 5 developers) |
Solution Engineering |
Same as Portal. |
| Pay-Ins Development Team (Pawan Kumar → Ratan Kumar → 4 developers) |
Solution Engineering |
Same as Portal. |
| DevOps and Infrastructure (M. Mohsin → Saifullah Khan → 5 engineers + 2 DBAs) |
Platform Engineering |
Expanded scope: now owns CI/CD pipeline as release authority (replacing CAB), feature flag infrastructure, automated rollback. Pipeline reliability is a first-class metric. |
| SQA Team (Owais Khalid → Hira Farooq → 5 SQA engineers) |
Production Engineering |
Fundamental role change. Manual QA sign-off eliminated. Team transitions to: production monitoring, incident response, on-call, SLO management, automated test infrastructure, service delivery. |
| Architecture (Maqsood Ali → Laique Ali) |
Cross-cutting under Digital Office governance |
Formalised: ARB facilitation, ADR ownership, architecture review gate before development. v1.0 had architecture involvement but no formal ARB or ADR process. |
| Product Manager / Product Owner |
Product Management |
Enhanced: now owns Story acceptance criteria quality as a gate to Ready. Participates in discovery spikes with Digital Office. Controls feature flag activation. |
| Information Security (Danish Hamid → Hamza Bari → team) |
Information Security |
Shift-left: threat modelling now happens before development (Phase 4), not after. Security requirements added as acceptance criteria to Stories. Snyk policy ownership. |
| Service Delivery (under SQA head) |
Production Engineering |
Absorbed into Production Engineering's production operations mandate. |
| - (did not exist) |
Data Engineering |
New tribe. SDLC for data pipelines, analytics, and reporting follows the same framework. |
| - (did not exist) |
Digital Office |
New tribe. SDLC process ownership, architecture governance, AI adoption, metrics, Agile coaching. |
4.2 Individual Transition Impacts
| Person |
v1.0 Role |
v2.0 Role |
Key SDLC Change |
| Owais Khalid |
Head SQA and Service Delivery |
Head of Production Engineering |
From QA gatekeeper to production reliability owner. Owns SLOs, incident response, on-call. |
| Hira Farooq |
SQA Lead |
Production Engineering Lead (Test Infrastructure) |
From manual test execution lead to automated test framework and monitoring lead. |
| Maaz Haider |
SQA Engineer (Automation) |
Production Engineer (Automation) |
Closest role continuity - automation skills transfer directly. |
| 4 remaining SQA Engineers |
Manual and automation QA |
Production Engineers |
Retrained for monitoring, incident response, and automated testing. Skills assessment determines individual placement. |
| Wajih Aslam |
Agile Coach (under PMO) |
Agile Coach (Digital Office) |
From sprint facilitation to Kanban coaching, WIP limit management, and flow optimisation. |
5. Removed Concepts
| Concept |
v1.0 Location |
Why Removed |
| Two-week sprints |
Section 20 (Sprint Governance) |
Replaced by Kanban continuous flow. Sprints create artificial batching and waste. |
| Sprint planning |
Section 20 |
Replaced by continuous grooming and pull-based work selection. |
| Sprint commitment |
Section 20 |
Replaced by WIP limits. Commitments create perverse incentives (scope reduction, quality shortcuts). |
| Daily standup meetings |
Section 20 |
Replaced by asynchronous Jira updates. Standups consume 30+ minutes daily across the division for low-value status sharing. |
| Separate QA phase |
Sections 11–12 (QA, UAT) |
Engineers own testing. Automated pipeline is the quality gate. |
| Manual QA sign-off |
Section 12 |
Replaced by automated pipeline gates. Manual sign-off adds lead time without improving quality. |
| Change Advisory Board (CAB) |
Section 17 (Release Governance) |
Replaced by automated pipeline gates. CAB adds days of lead time and is a deployment bottleneck. |
| Release manager role |
Section 17 |
Not needed when deployment is automated and pipeline is the release authority. |
| Waterfall Jira gate columns |
Section 19 |
Replaced by five Kanban flow columns. Gate columns hide queuing time. |
| Feasibility phase (separate) |
Section 7 |
Merged into Discovery & Spike. Separate feasibility created unnecessary handoff. |
| Production Readiness phase (separate) |
Section 14 |
Merged into Deployment. Production readiness checks are automated pipeline stages. |
| Handover phase |
Section 16 |
Eliminated entirely. There is no handoff in the new model - tribes own their services end-to-end. |
| Sprint velocity tracking |
Section 20 |
Replaced by throughput, cycle time, and DORA metrics. Velocity is a poor predictor and creates gaming incentives. |
| Project concept |
Throughout |
Replaced by Initiative → Epic → Story hierarchy. Projects are eliminated as a delivery construct. |
6. New Concepts
| Concept |
v2.0 Section |
Why Added |
| Governance Principles |
Section 4 |
v1.0 had no explicit principles. Five principles now anchor all SDLC decisions: no-project, AI-native, automation over approval, ownership over handoff, transparency by default. |
| Seven-tribe structure |
Section 5 |
Org restructure. Solution Engineering, Platform Engineering, Data Engineering, Production Engineering, Information Security, Product Management, Digital Office. |
| Kanban with 10-day cycles |
Section 6 |
Replaces sprints. 9 days delivery + Day 10 ceremonies. Continuous flow with WIP limits. |
| Work hierarchy (Initiative → Epic → Story → Task) |
Section 7 |
v1.0 had no formal work decomposition hierarchy. This codifies what each level means, who owns it, and how it maps to Jira. |
| Discovery & Spike phase |
Section 8, Phase 1 |
New phase. Digital Office validates feasibility and produces architecture blueprint before work enters backlog. |
| Shift-left security |
Section 8, Phase 4 |
Security review before development, not after. Threat modelling produces security acceptance criteria added to Stories. |
| Automated quality gates |
Section 8, Phase 6 |
Formal pipeline stages (unit tests, integration tests, static analysis, Snyk, build) replace manual QA. |
| Feature flags |
Sections 8, 10 |
Progressive rollout, instant rollback per feature, decoupled deployment from release. Not present in v1.0. |
| Automated rollback |
Section 8, Phase 7 |
Within 5 minutes. Triggered automatically by error rate or latency regression. v1.0 had manual rollback only. |
| Post-deployment verification |
Section 8, Phase 8 |
Canary monitoring, SLO validation, automated alerting. v1.0 had "Post-Deploy Monitoring" but no specific verification criteria. |
| Hotfix process |
Section 9 |
Dedicated emergency path with reduced approvals, mandatory post-incident review. v1.0 had no formal hotfix path. |
| Definition of Done |
Section 12 |
Ten explicit criteria per Story. v1.0 had no formal DoD. |
| Test pyramid and coverage targets |
Section 13 |
80% unit coverage target. Test pyramid model (unit → integration → E2E). v1.0 had no coverage targets. |
| Architecture Decision Records (ADRs) |
Section 15 |
Template, when-to-write criteria, ARB review process. Institutional memory for technical decisions. |
| DORA metrics |
Section 17 |
Deployment frequency, lead time, MTTR, change failure rate - with specific targets. v1.0 had no engineering performance metrics. |
| Flow metrics |
Section 17 |
Cycle time, WIP age, throughput, flow efficiency. v1.0 tracked only sprint velocity. |
| SDLC maturity model |
Section 18 |
Per-tribe maturity assessment across five dimensions. Drives coaching and investment priorities. |
| AI-native engineering |
Section 4 |
AI tools (code generation, review, testing, documentation) are standard equipment, not exceptions. |
7. Migration Plan
The transition from v1.0 to v2.0 is phased over 12 weeks, not a big-bang switch. This aligns with the CDO 30/60/90 Day Plan (Phase 2: Restructure and Implement).
Phase 1: Communication and Training (Weeks 1–2)
Period: 7–18 April 2026
| Action |
Owner |
Deadline |
| Publish v2.0 to Confluence |
Digital Office |
7 April |
| CDO all-hands presentation explaining the changes |
CDO |
9 April |
| Tribe leads briefed individually on their tribe's transition |
CDO |
11 April |
| Kanban training for all engineers (delivered by Agile Coach) |
Wajih Aslam |
18 April |
| PR workflow and code review training |
Digital Office |
18 April |
Period: 14–27 April 2026
| Action |
Owner |
Deadline |
| Convert all Jira boards from Scrum to Kanban |
Agile Coach |
14 April |
| Configure WIP limits per tribe per column |
Agile Coach + Tribe Leads |
18 April |
| Remove gate columns (Awaiting QA, Awaiting CAB, etc.) |
Agile Coach |
18 April |
| Archive completed sprints and reset boards |
Agile Coach |
21 April |
| Create Initiative and Epic hierarchy in Jira |
Product Management |
27 April |
| Create ADR space in Confluence |
Digital Office |
21 April |
Phase 3: Pipeline Automation (Weeks 3–8)
Period: 21 April – 27 May 2026
| Action |
Owner |
Deadline |
| Audit current pipeline stages per service |
Platform Engineering |
27 April |
| Add Snyk scanning to all pipelines |
Platform Engineering |
5 May |
| Add static analysis to all pipelines |
Platform Engineering |
12 May |
| Enforce unit test stage (fail pipeline on test failure) |
Platform Engineering |
12 May |
| Implement automated rollback mechanism |
Platform Engineering |
27 May |
| Implement feature flag infrastructure |
Platform Engineering |
27 May |
| Achieve daily deploy capability for one tribe (pilot) |
CTO + Platform Engineering |
27 May |
Phase 4: Production Engineering Transition (Weeks 3–8)
Period: 21 April – 27 May 2026
| Action |
Owner |
Deadline |
| SQA team members complete skills assessment |
Owais Khalid + HR |
27 April |
| Individual transition plans agreed (monitoring, test infra, or redeployment) |
Owais Khalid + CDO |
5 May |
| On-call rotation designed and published |
Owais Khalid |
12 May |
| SLOs defined for all critical services |
Owais Khalid + CTO |
14 May |
| Production monitoring dashboards operational |
Production Engineering |
27 May |
| First on-call rotation active |
Production Engineering |
27 May |
Phase 5: Metrics and Measurement (Weeks 8–12)
Period: 27 May – 27 June 2026
| Action |
Owner |
Deadline |
| DORA metrics collection automated |
Digital Office |
10 June |
| Flow metrics collection automated (from Jira) |
Digital Office |
10 June |
| First fortnightly engineering metrics report published |
Digital Office |
24 June |
| Baseline values established for all metrics |
Digital Office |
24 June |
| All tribes operating under v2.0 |
CDO |
27 June |
Phase 6: CAB Deprecation (Week 8)
Period: 27 May 2026
| Action |
Owner |
Deadline |
| CAB formally deprecated (CDO communication) |
CDO |
27 May |
| CAB-related Jira workflows removed |
Agile Coach |
27 May |
| Release approval process confirmed as pipeline-only |
CTO + CDO |
27 May |
Note: CAB deprecation is deliberately scheduled after pipeline automation is operational (Phase 3). The automated gates must be proven before the manual gate is removed.
8. Risk Assessment
| Risk |
Likelihood |
Impact |
Mitigation |
| Engineers resist owning testing. Solution Engineers accustomed to handing off to QA may not write adequate tests. |
High |
High |
Training programme. 80% coverage target enforced in pipeline (code that doesn't meet coverage fails the build). Coaching from Agile Coach. CDO monitors coverage metrics weekly during transition. |
| Test coverage is too low to remove QA gate safely. Current automated test coverage may be insufficient to rely on pipeline-only quality assurance. |
High |
High |
Phase 3 includes a test coverage audit before CAB deprecation. Coverage must reach 60% minimum before QA gate is removed for a given service. Production Engineering retains exploratory testing capability during transition. |
| Production incidents increase during transition. Removing manual QA and CAB may temporarily increase the change failure rate. |
Medium |
High |
Feature flags limit blast radius. Automated rollback within 5 minutes. Production Engineering on-call provides rapid response. Change failure rate tracked as DORA metric - if it exceeds 10%, the CDO will intervene. |
| SQA team members resist role change. Former SQA engineers may not want to transition to Production Engineering. |
Medium |
Medium |
Individual skills assessments and transition plans. Retraining provided. Alternative placement within the organisation if Production Engineering is not a fit. Natural attrition may resolve some cases. |
| Daily standup removal causes communication gaps. Async updates may not surface blockers fast enough. |
Low |
Medium |
Tribe leads review boards daily. WIP age alerts flag stuck items automatically. Tribes can reinstate synchronous check-ins if async proves insufficient - the framework permits ad hoc huddles. |
| Kanban discipline is weak initially. Teams may ignore WIP limits or not update Jira promptly. |
Medium |
Medium |
Agile Coach actively monitors boards during first 3 cycles. WIP violations are flagged in retrospectives. CDO reviews Jira hygiene in fortnightly metrics report. |
| Pipeline automation delays. Platform Engineering may not deliver all pipeline stages by 27 May. |
Medium |
High |
Pipeline work is the highest priority for Platform Engineering in Phase 2. CDO reviews progress weekly. If delayed, CAB deprecation is deferred (manual gate stays until automated gate is ready). |
| Regulatory concern about removing CAB. DFSA or PCI-DSS auditors may question the removal of a manual change approval process. |
Low |
High |
Automated pipeline provides a more rigorous and auditable control than CAB. Every gate is logged. Traceability chain (Jira → PR → Pipeline → Deployment) is stronger than manual sign-off. Section 14 of v2.0 documents the compliance evidence. Pre-emptive briefing for auditors prepared by Information Security. |
9. Quality Issues Fixed
9.1 Language Corrections
v1.0 used US English spellings throughout. v2.0 uses British English consistently, per Simpaisa documentation standards.
| v1.0 (US English) |
v2.0 (British English) |
| Organization |
Organisation |
| Authorized |
Authorised |
| Centralized |
Centralised |
| Utilize |
Utilise |
| Prioritize |
Prioritise |
| Analyze |
Analyse |
| Color |
Colour |
| Favor |
Favour |
| License (verb and noun both "license") |
Licence (noun) / License (verb) |
| Offense |
Offence |
| Defense |
Defence |
The following errors were present in v1.0 and are corrected in v2.0:
| Issue |
Location in v1.0 |
Status in v2.0 |
| Inconsistent capitalisation of role titles |
Throughout |
Standardised: role titles capitalised when referring to specific positions |
| Missing punctuation in several section headers |
Sections 6, 11, 15 |
Corrected |
| Duplicate content between Sprint Governance and Release Governance sections |
Sections 17 and 20 |
Eliminated - single source of truth per topic |
| Inconsistent date formats (mix of DD/MM/YYYY and MM/DD/YYYY) |
Header and body |
Standardised to DD Month YYYY (e.g., 7 April 2026) |
| References to "the team" without specifying which team |
Multiple sections |
All references now specify the responsible tribe |
| Jira workflow diagram did not match the described column names |
Section 19 |
Diagram and description are consistent |
| Several bullet points with trailing whitespace and inconsistent indentation |
Throughout |
Cleaned |
9.3 Structural Issues
| Issue |
Status in v2.0 |
| No table of contents |
Table of contents added |
| No document classification marking |
Class 2 (Confidential) added to header |
| No version history table |
Version history table added (Section 20.4) |
| No formal supersession statement |
Supersedes section added (Section 19) with explicit reference to v1.0 |
| No adoption timeline |
Phased adoption timeline with milestones added (Section 20.2) |
| No metrics or measurement framework |
Comprehensive metrics section added (Section 17) |
End of document.