Simpaisa Digital Office - Organisation Structure

10-Day Delivery Cycles

• Days 1-9: Kanban delivery. Squads pull Stories from the backlog, deliver, and ship. Continuous flow with WIP limits. No daily standups - async updates via tooling.
• Day 10: Retro, Demo, Refine. Retrospective on the cycle just completed. Demo of shipped work to stakeholders. Refining and organising the next cycle's backlog.
• Continuous shipping. Work ships as it's ready during the 9 days, not at the end. The cycle is a planning rhythm, not a release gate.
• No velocity theatre. Track throughput (Stories completed per cycle) and cycle time, not story points or velocity charts.

Epic Governance (Replaces Projects)

• An Epic is a "Project" with Agile mechanics. It has a clear objective, a Definition of Done, an owner (PM), and a closure point. It is NOT an open-ended bucket.
• Budget tracking via Epic burn. Assign a budget/appetite to the Epic. Track burn based on Stories completed, not hours logged.
• Dependencies via issue linking. If Epic A needs something from Epic B, link them ("Blocks" / "Is Blocked By"). Visualise on the board. No programme manager needed.
• Stakeholder visibility. Stakeholders see Epic progress via roadmap and progress bars, while squads focus on granular Stories.
• Change is flexible. Add, remove, or reprioritise Stories within an Epic without formal change requests - as long as the Epic goal stays the same.

Non-Feature Work Types

• Stories: User-facing features and requirements. Written from user perspective with acceptance criteria.
• Spikes: Time-boxed research or architectural investigation. Has a clear question and defined output. Run by Digital Office or within a squad. Maximum 1 cycle.
• Bugs: Defects found during delivery. Treated as Stories, prioritised on the backlog alongside features.
• Chores: Documentation, compliance activities, tech debt, infrastructure tasks. Required to ship but no direct user value. Still on the backlog, still prioritised by the PM.

Discovery & Pre-SDLC

• Cycle 0 (Discovery Cycle): Before a new Epic begins delivery, run a discovery cycle. Digital Office and PM validate feasibility, write the initial Stories, and define the Epic's Definition of Done.
• Dual-Track: Discovery track (Product + Digital Office) runs continuously alongside Delivery track (Engineering). Discovery stays 1-2 cycles ahead of Delivery.
• Shape Up Pitches: For larger initiatives, a senior person writes a pitch (problem, appetite, solution sketch, rabbit holes). The squad shapes and delivers within a fixed appetite (e.g. 6 cycles).
• OKR-Driven: Quarterly OKRs set outcomes. Squads own how to hit the key results. No task-level programme plans.

Why No Project Managers or Scrum Masters

• PM owns "what" and "why" - the Product Manager is accountable for outcomes, owns the backlog, and manages stakeholders. No project manager tracking Gantt charts.
• Lead/Manager owns "how" and "when" - the engineering Lead or Manager coordinates delivery within the squad. This is a hands-on technical role, not a status reporter.
• Everyone knows the operating model - Kanban board, WIP limits, 10-day cycles, escalation paths, and work hierarchy are documented and understood by all. No one needs a coach to follow the method.
• AI handles coordination overhead - status reports, dependency tracking, risk flagging, and stakeholder updates are automated via AI agents.
• Multi-squad coordination - handled by the CTO and CPO in a lightweight weekly sync. No programme managers.

Definition of Ready (DoR)

A Story is not pulled into a cycle until all of these are true.

• Problem stated: The Story describes a user or system need, not a solution. "As a [user], I need [outcome] so that [reason]."
• Acceptance criteria written: Specific, testable conditions that define when the Story is complete. No ambiguous language ("should", "might", "generally").
• Dependencies identified: Any blocking dependencies are either resolved or explicitly tracked. The squad is not waiting on another squad mid-cycle.
• Sized to fit: The squad has confirmed the Story can be completed within one 9-day cycle. If not, it must be split before entering the cycle.
• Design resolved: Any UX flows, API contracts, or schema changes are agreed before the Story starts. Design is not a delivery-cycle activity.
• Security considered: For Stories touching auth, payments, PII, or external APIs, a security note is added confirming the approach has been reviewed.

Definition of Done (DoD)

A Story is not marked complete until all of these are true.

• Acceptance criteria met: All criteria from the DoR are verified - automated where possible, manually confirmed where not.
• Tests written and passing: Unit tests cover the new logic. Integration tests cover the boundary. No reduction in overall coverage.
• Code reviewed and merged: Pull request approved, CI gates passed, merged to main.
• Deployed to staging: The change is running in the staging environment and has been smoke-tested by the engineer.
• No known defects introduced: No regressions observed in staging. Any edge cases discovered during delivery are logged as follow-up Stories, not silently deferred.
• Observability in place: Logs, metrics, or traces are in place for any new behaviour. Silent failures are not acceptable in a payments system.
• Documentation updated: API docs, runbooks, or ADRs updated if the change introduces a new pattern, contract, or operational behaviour.

Key Rules for Success

• Definition of Done per Epic: Define exactly what "complete" looks like. Is it when all Stories are done, or when a specific business outcome is met?
• No never-ending Epics: Every Epic has a clear closure point. If it's ongoing maintenance, it's not an Epic - it's BAU on the team's Kanban board.
• Stories must fit in one cycle: If a Story can't be completed in 9 days, break it down further. Large Stories are a planning failure, not an execution problem.
• Products are permanent, Epics are temporary: Every initiative maps to a product (Pay-Ins, Pay-Outs, Portals, Platform). There is no work that lives outside a product.

Source Control & Branching

• Trunk-based development. All active development targets main. Feature branches are short-lived - maximum 2 working days. No long-running branches.
• Branch naming: feat/, fix/, chore/, spike/ prefixes required. Branch name must reference the issue ID - e.g. feat/SP-1234-payment-retry.
• Commit messages: Conventional Commits format required. feat:, fix:, chore:, docs: prefixes. Body describes why, not what.
• No direct commits to main. All changes via pull request, including hotfixes. Emergency hotfixes use a hotfix/ branch and expedited review, not a bypass.
• Mono-repo per domain. Each product domain has a single repository. Shared libraries in a separate platform repository. No microrepo sprawl.
• Repository access: Engineers have write access to their squad repo. Cross-squad contributions require PR from a fork or a temporary branch with team lead approval.

Code Review Standards

• Minimum one approval required for all merges. Two approvals required for: payment processing logic, auth flows, shared platform components, database migrations, and external API integrations.
• Principal or Manager approval required for: changes to settlement logic, cryptographic operations, PII handling, and anything touching financial calculations.
• Review SLA: Reviewers must respond within 4 working hours of PR submission. Stale PRs (no activity for 2 working days) are flagged to the squad Manager.
• Review checklist: Correctness, test coverage, security implications, performance impact, error handling, and observability. Reviewers are accountable for what they approve.
• No rubber-stamping. Approving a PR without reading it is a conduct issue. If a reviewer lacks context, they must say so rather than approve blindly.
• Self-review is not review. The author may not approve their own PR. Senior ICs reviewing their own Principal's work is encouraged - review is not hierarchical.

CI Pipeline & Gates

• CI runs on every push to a feature branch and on every PR. Failing CI blocks the merge - no exceptions, no bypasses.
• Mandatory gates (all must pass):
  • Lint and formatting check
  • Unit tests - 0 failures, coverage must not decrease
  • Integration tests against a containerised test environment
  • SAST scan (static application security testing)
  • Dependency vulnerability scan - no critical or high CVEs unaddressed
  • Build artifact produced and tagged
• Pipeline ownership: Platform Engineering owns the CI pipeline infrastructure. Squads own their pipeline configuration within the platform's standards. Squads may not disable gates.
• Build time target: CI must complete within 10 minutes. Pipelines exceeding this are flagged for optimisation by Platform Engineering.

Testing Standards

• Testing pyramid: Unit tests form the base (fast, cheap, numerous). Integration tests in the middle. E2E and contract tests at the top (fewer, slower, high value).
• Unit tests: Required for all business logic. Cover happy path, error paths, and boundary conditions. No logic ships without a unit test.
• Integration tests: Required for all service boundaries - database operations, external API calls, message queue interactions. Run against real dependencies in CI using containers.
• Contract tests: Required for all inter-service API contracts. Consumer-driven contract tests (Pact or equivalent) prevent breaking changes between services.
• E2E tests: Maintained for critical user journeys only - payment initiation, settlement, reconciliation, merchant onboarding. Owned by the RE team, not individual squads.
• Test data: No production data in tests. Synthetic data generators maintained per domain. PII in test fixtures is synthetic only.

Security Gates

• SAST on every PR. Static analysis runs in CI. Critical and high findings block the merge. Medium findings are logged and must be remediated within the cycle.
• DAST on staging. Dynamic application security testing runs against the staging environment before every production promotion. Blocking on critical findings.
• Dependency scanning daily. All production dependencies scanned for new CVEs daily via automated tooling. Critical CVEs require a patch PR within 48 hours. High within 7 days.
• Secret scanning on every commit. Automated pre-commit hook and CI gate detect secrets in code. Any committed secret is treated as compromised immediately - rotate, do not just delete.
• Security review for high-risk changes. Manager of Security Engineering or Principal Security Engineer must review PRs touching auth, payment processing, cryptographic code, or PII pipelines before merge.
• Penetration testing quarterly. External pen test against staging environment. Findings tracked in the security register with SLA-based remediation. CISO sign-off on scope and results.

Environment Promotion

• Three environments: dev (local and CI), staging (production parity), production. No environment is skipped.
• Staging parity: Staging mirrors production configuration, infrastructure sizing, and partner test credentials. It is not a toy environment - treat it as production with synthetic data.
• Promotion criteria - dev to staging: All CI gates pass, PR approved and merged to main.
• Promotion criteria - staging to production: Smoke tests pass in staging, RE sign-off on observability readiness, no open critical bugs introduced by the change, CISO sign-off if the change touches security-sensitive paths.
• Feature flags: Large features are deployed to staging behind a flag. Flag state is managed by the PM. Flags are not permanent - every flag has a removal date set at creation.
• No hotfixes direct to production. All changes pass through staging. Expedited staging validation is permitted for P1 incidents, but the stage is not skipped.

Release & Deployment

• Squads own their deployment. There is no separate release team. Engineers promote their own changes through the platform pipeline. Deployment is a routine engineering activity, not a ceremony.
• Deployment frequency target: Daily per service. Batching releases is a symptom of process problems, not a risk management strategy.
• Deployment method: Blue-green or canary deployment via the platform pipeline. Traffic shifted incrementally. Full cutover only after health checks pass.
• Automated rollback: If health checks fail post-deployment, the platform rolls back automatically. Engineers are notified immediately. Manual rollback is available but should rarely be needed.
• Deployment windows: Standard deployments anytime. Deployments to payment-critical paths avoid peak settlement windows (09:00-11:00 GST and 14:00-16:00 GST). CISO approval required for out-of-hours security changes.
• Release notes: Every production deployment generates a release note from commit history (automated). Stored in the change log. Not optional.

Observability & Production Readiness

• Observability is a shipping requirement. Code that cannot be observed in production is not ready to ship. Logs, metrics, and traces must be in place before promotion.
• Structured logging: JSON format, mandatory fields (service, trace ID, correlation ID, severity, timestamp). No unstructured log lines in production code.
• Metrics: Every service exposes RED metrics (Rate, Errors, Duration) as a minimum. Business metrics (transactions processed, settlement value, partner error rates) emitted by the owning squad.
• Distributed tracing: All inter-service calls instrumented with trace context propagation. Payment transactions traceable end-to-end across all services.
• SLO coverage: Every production service must have an SLO defined before it goes live. SLO targets set by the RE team in consultation with the squad. Breaching an SLO triggers an automatic incident.
• Runbook required: Every new service or significant operational behaviour requires a runbook before production deployment. Runbook reviewed by the RE team.

Secrets & Configuration

• No secrets in code. No API keys, tokens, passwords, certificates, or connection strings in source code, commit history, or environment variable files checked into version control. Ever.
• Secrets platform: All secrets stored in the central secrets management platform. Injected at runtime via the platform pipeline. Engineers never see production secrets directly.
• Rotation policy: All secrets rotated on a schedule - API keys every 90 days, service account credentials every 180 days, certificates before expiry with 30-day lead time. Rotation is automated where possible.
• Config per environment: Configuration is environment-specific and injected at runtime. No hardcoded environment checks in application code (if env == "prod" is a bug, not a pattern).
• Least privilege: Service accounts and API credentials scoped to the minimum required permissions. No wildcard policies. Access reviewed quarterly by the CISO.
• Compromised secret protocol: Any suspected credential leak is treated as confirmed until proven otherwise. Rotate immediately, notify CISO within 30 minutes, open a security incident.