Skip to main content

LendOS Software Development Lifecycle (SDLC)

Executive Summary​

LendOS is a commercial lending platform serving enterprise clients with low tolerance for production incidents. Our SDLC balances startup velocity with enterprise reliability through:

  • Team Topology principles - Clear team boundaries and interaction modes
  • Continuous delivery with scheduled releases - Deploy when Product approves, not on arbitrary schedules
  • Debt prevention - DOR/DOD gates prevent monitoring, security, compliance, and technical debt
  • AI-augmented workflows - Story refinement and PR documentation automated
  • Smart contract reality - Manual revert strategy acknowledges DAML immutability constraints

Core Agile Principles​

We follow these fundamental agile principles:

  • ✅ Working software is the primary measure of progress
  • ✅ Welcome changing requirements, even late in development
  • ✅ Business and developers work together daily
  • ✅ Build projects around motivated individuals
  • ✅ Simplicity - the art of maximizing work not done
  • ✅ Self-organizing teams
  • ✅ Continuous attention to technical excellence and good design
  • ✅ Regular reflection and adjustment (retrospectives)

Team Topology​

Team Responsibilities​

Team TypeTeam NameLeadResponsibility
Stream-AlignedValue StreamBoskoEnd-to-end product features for commercial lending workflows
Complicated SubsystemDAML EngineeringStevenDAML smart contracts, Canton integration, distributed ledger logic
EnablingQARafaellaTest strategy, quality enablement, sign-off gate
PlatformDevOpsJake (Principal)CI/CD, IaC, deployment automation, Canton operations
PlatformProduction SupportHiring Feb 2026Incident response, monitoring, operational excellence

Sprint Structure​

Sprint Cadence​

  • Duration: 2 weeks (10 business days)
  • Start Day: Wednesday
  • End Day: Tuesday (2 weeks later)
  • Sprint Goal: Deliver an accepted release package (NOT deployment)
  • Deployment: Multi-tenant rollout occurs during the following sprint

Sprint Schedule Visualization​

Sprint Ceremonies​

📋 Sprint Planning​

When: Day 1 - Wednesday, 11:00-1:00 PM ET Duration: 2 hours Attendees: All team members + Product Owner

Agenda​

  1. Product Vision - What are we building and why?
  2. Velocity Review - Planned vs. completed story points
  3. Sprint Goal - One sentence definition
  4. Capacity Check - PTO, holidays, commitments
  5. Story Commitment - Pull stories meeting DOR
  6. Story Assignment - Engineers self-select work
Story Assignment
  • Single owner per story - One engineer takes full responsibility
  • Just-in-time assignment - Happens during Sprint Planning
  • Large stories → Subtasks - Break down cross-functional work

🗣️ Daily Standup​

When: Mon-Fri, 11:30 AM ET Duration: 15 minutes MAX Format: Async-first, sync for blockers

Each person answers:

  1. What did I complete yesterday?
  2. What am I working on today?
  3. Am I blocked? (If yes, who can unblock?)

🔍 Backlog Refinement​

When: As needed (typically Week 2 Wednesday) Duration: 1-1.5 hours Purpose: Prepare stories to meet Definition of Ready

Process:

  1. Engineer runs AI refinement plugin on stories
  2. Team reviews AI suggestions
  3. Work through DOR checklist
  4. Estimate complexity (Fibonacci: 1, 2, 3, 5, 8, 13)

🎯 Sprint Review​

When: Last Day - Tuesday, 1:00-2:00 PM ET Duration: 1 hour Format: Live demos, not slides

Agenda:

  1. Sprint goal achievement review
  2. Story demos by engineers
  3. Stakeholder feedback
  4. Next sprint preview

🔄 Retrospective​

When: Last Day - Tuesday, 2:15-3:00 PM ET Duration: 45 minutes Format: Safe space for improvement

Focus Areas:

  • What went well?
  • What needs improvement?
  • Action items for next sprint

Definition of Ready (DOR)​

Stories must meet these criteria before sprint commitment:

Functional Requirements​

  • User Story Format: As a [user], I want [feature], so that [value]
  • Acceptance Criteria: Clear, testable conditions for completion
  • Dependencies Identified: Technical, business, and cross-team
  • Edge Cases Documented: Error scenarios and boundary conditions

Technical Requirements​

  • Technical Approach: High-level implementation strategy defined
  • DAML Impact: Smart contract changes identified (if applicable)
  • API Changes: Endpoint modifications documented
  • Database Impact: Schema changes identified
  • Performance Criteria: Response time and load requirements

Operational Requirements​

  • Monitoring Plan: Metrics and alerts defined
  • Security Review: Authentication/authorization considered
  • Compliance Check: Regulatory requirements addressed

Definition of Done (DOD)​

Stories are complete only when ALL criteria are met:

Code Quality​

  • Code Complete: All acceptance criteria implemented
  • Code Reviewed: PR approved by 2+ reviewers
  • Tests Written: Unit tests (80%+ coverage)
  • Tests Passing: All CI checks green
  • No Critical Vulnerabilities: Security scan clean

Documentation​

  • Code Documented: Inline comments for complex logic
  • API Documented: Swagger/OpenAPI updated
  • User Documentation: Help text or guide updated
  • Release Notes: Customer-facing changes documented

Operational Readiness​

  • Monitoring Active: Metrics and alerts configured
  • Logging Implemented: Structured logs with correlation IDs
  • Feature Flags: Rollout strategy defined
  • Rollback Plan: Reversion strategy documented

Verification​

  • QA Approved: Testing complete and passed
  • Product Approved: Meets business requirements
  • Demo Ready: Can be shown in sprint review

Release & Deployment Process​

Release Strategy​

Deployment Windows​

  • Alpha: Immediate on merge to main
  • Beta: Within 24 hours of approval
  • RC: Scheduled deployment window
  • Production: Scheduled maintenance window
DAML Contract Constraints

Smart contract upgrades require ~2 week cycles due to immutability. Plan accordingly for contract changes.

Data Migration Scripts​

Overview​

Data migration scripts are DAML programs that modify production ledger data outside of normal application workflows. They are used for data corrections, migrations, and hot fixes.

Common Use Cases:

  • Fixing incorrect data from bugs
  • Migrating data to new contract structures
  • Bulk updates not practical through UI
  • Correcting settlement dates or lender positions
Complete Documentation

See Data Script Development Playbook for detailed procedures.

Workflow​

Responsibilities​

TeamResponsibility
ProductDefine requirements, identify side effects, validate results
DevelopmentWrite data-driven scripts with tests, comprehensive logging
PQS/DevelopmentQuery production data, create JSON files for both environments
DevOpsPackage version, execute scripts, capture logs

Key Principles​

  • Data-Driven Design: Scripts accept JSON input rather than hard-coded values
  • Idempotent: Can be run multiple times safely
  • Graceful Error Handling: Continue on failures, report all results
  • Comprehensive Logging: Debug output for every operation
  • Staging First: Always validate on staging before production

AI-Augmented Workflows​

Story Refinement​

  1. AI plugin analyzes story text
  2. Generates acceptance criteria suggestions
  3. Identifies potential edge cases
  4. Recommends test scenarios
  5. Engineer reviews and adjusts

PR Documentation​

  1. AI analyzes code changes
  2. Generates PR description
  3. Creates release notes draft
  4. Identifies breaking changes
  5. Developer validates and publishes

Monitoring Requirements​

Every feature must include:

Application Metrics​

  • Response time (p50, p95, p99)
  • Error rate and types
  • Business metric tracking
  • Resource utilization

Infrastructure Metrics​

  • CPU and memory usage
  • Network latency
  • Database query performance
  • Canton/DAML metrics

Alerting Thresholds​

  • Error rate > 1% → Warning
  • Error rate > 5% → Critical
  • Response time p95 > 2s → Warning
  • Response time p95 > 5s → Critical

Tools & Platforms​

Development Tools​

  • IDE: VS Code with team extensions
  • Version Control: Git/GitHub
  • Code Review: GitHub Pull Requests
  • CI/CD: GitHub Actions

Project Management​

  • Sprint Tracking: Jira
  • Documentation: Confluence + This Wiki
  • Communication: MS Teams
  • Time Tracking: Internal system

Testing & Quality​

  • Unit Testing: Jest
  • E2E Testing: Playwright
  • DAML Testing: Scenario tests
  • Performance: K6/Artillery

Success Metrics​

Sprint Metrics​

  • Velocity Stability: ±20% variance
  • Commitment Accuracy: 80%+ completion
  • Defect Rate: <5% of stories

Quality Metrics​

  • Code Coverage: >80%
  • PR Review Time: <4 hours
  • Build Success Rate: >95%

Delivery Metrics​

  • Lead Time: <1 sprint
  • Deployment Frequency: Weekly
  • MTTR: <2 hours
Questions?

Contact your Scrum Master or Engineering Manager for clarification on any SDLC process.

Last updated: November 2024