Lucent Owl logo Lucent Owl

SDLC Diagrams

Last updated:

8 related guides
diagrams scrum kanban value-stream-mapping cicd team-topologies

Three Ways to Traverse the SDLC

Flow

Sequential, iterative and continuous passes through the same six activities.

The six SDLC activities traversed sequentially, iteratively and continuously Three rows share one time axis. Sequential: planning, design, development, testing, deployment and maintenance each happen once, for the whole system, one after another, so learning arrives late. Iterative: all six activities run inside each of five iterations, each over a slice of the system, so learning arrives every iteration. Continuous: many small changes each pass through all six activities independently and overlap in time, so learning arrives per change. THE SAME SIX ACTIVITIES, OVER THE SAME STRETCH OF TIME Sequential [whole system, once] learning arrives late Iterative [a slice per iteration] learning every iteration Continuous [each change, via a pipeline] learning per change Planning Design Development Testing Deployment Maintenance P D B T Dp M iteration 1 P D B T Dp M iteration 2 P D B T Dp M iteration 3 P D B T Dp M iteration 4 P D B T Dp M iteration 5 each bar is one change passing through all six, independently of the others P plan · D design · B build · T test · Dp deploy · M maintain. The activities never change; the batch size and how often they repeat do.

Boehm's Spiral Model

Flow

Four activities per pass, with commitment growing each turn.

The spiral model's four activities repeated in widening passes A spiral starts at the centre and winds clockwise through four quadrants: determine objectives and constraints, identify and evaluate risks, develop and verify the next increment, and plan the next spiral with stakeholders. Distance from the centre is cumulative commitment, so each pass commits more resources than the last. What each pass builds is whatever resolves the largest remaining risk. 1 · Objectives determine objectives and constraints 2 · Risks identify and evaluate the risks 3 · Develop develop and verify the next increment 4 · Plan plan the next spiral with stakeholders DISTANCE FROM CENTRE Cumulative commitment. Each pass commits more resources than the last. WHAT THE NEXT PASS BUILDS Whatever resolves the largest remaining risk. Risk, not feature priority, sets the agenda.

Four Team Types and Three Interaction Modes

Structure

The four team types, and which interaction mode connects each pair.

Team Topologies team types connected by the three interaction modes Four team types arranged in three columns. On the left, an enabling team, which helps other teams acquire a missing capability and then leaves. In the centre, two stream-aligned teams, each owning a continuous flow of work for one slice of the business and each delivering to users without handoffs. On the right, a platform team providing self-service internal products, and a complicated-subsystem team owning a part that needs deep specialist knowledge. Three interaction modes connect them. Facilitating runs from the enabling team to each stream-aligned team and is temporary. X-as-a-Service runs from each stream-aligned team to the platform team, where the consumer depends on a stable service with minimal conversation. Collaboration runs in both directions between the lower stream-aligned team and the complicated-subsystem team while an interface is still being discovered, and is expected to end. Cognitive load per team is the constraint the whole arrangement exists to manage. HELPS, THEN LEAVES OWNS A SLICE OF VALUE REDUCES OTHERS' LOAD Enabling team [temporary by design] closes a capability gap in another team, then disengages Stream-aligned team [the default team type] one flow of work, end to end, no handoffs e.g. checkout Stream-aligned team [most teams are this] owns build and run for its own slice e.g. inventory Platform team [treats teams as customers] self-service internal products, adopted because they are good Complicated-subsystem [exists only when justified] a part needing deep specialist knowledge e.g. a pricing engine INTERACTION MODES X-as-a-Service: the consumer depends on a stable service, with little conversation Facilitating: one team helps another get better at something, then stops Collaboration: high bandwidth both ways while an interface is discovered, then ends Cognitive load per team is the constraint. Every mode above exists to keep one team's load inside what it can actually hold.

One Scrum Sprint

Flow

The events inside a Sprint and the artifacts they produce.

The Scrum events inside one Sprint, with the artifacts they read and produce The Product Backlog, with its Product Goal, feeds Sprint Planning, which produces the Sprint Backlog with its Sprint Goal. Inside the Sprint the Daily Scrum repeats every 24 hours, inspecting progress and adapting the plan, and work becomes the Increment, which meets the Definition of Done. The Sprint Review inspects the Increment with stakeholders and its feedback revises the Product Backlog. The Sprint Retrospective follows and produces improvements for the next Sprint, which starts at Planning with no gap. SPRINT · ONE MONTH OR LESS · THE NEXT BEGINS IMMEDIATELY Product Backlog [Product Goal] ordered by value, refined continuously Sprint Planning the Sprint Goal and a plan to reach it Sprint Backlog [Sprint Goal] selected items plus the plan Daily Scrum [every 24 hours] inspect progress, adapt the plan Increment [Definition of Done] all Done work so far Sprint Review inspect the Increment with stakeholders Retrospective [Sprint Retrospective] improvements for the next Sprint feedback from the Review revises the Product Backlog the next Sprint starts at Planning, carrying the improvements Tinted boxes are artifacts, with the commitment each carries in brackets. White boxes are events inside the Sprint.

Reading a Sprint Burndown

Chart

Four burndown shapes and what each one means.

Four sprint burndown chart patterns Four small charts of work remaining over the days of a sprint, each against a dashed ideal line from total work to zero. On track: the actual line trends down to zero. Flat line: the line stops falling, meaning work is not being completed. Going up: the line rises mid-sprint, meaning scope was added or estimates increased. Steep drop at end: the line stays high and falls on the last days, meaning work was completed at the last minute. Shapes are illustrative. On track sprint days Trends toward zero Flat line sprint days Work not being completed Going up sprint days Scope added mid-sprint Steep drop at end sprint days Finished at the last minute work remaining ideal line, from total work to zero actual remaining work a pattern to investigate

Reading a Cumulative Flow Diagram

Chart

Stable flow, then a Code Review bottleneck, as stacked bands.

A cumulative flow diagram showing stable flow and then a code review bottleneck A stacked area chart of cumulative items over time with four bands, from the bottom: Done, Code Review, In Progress and To Do. In the first half the bands run parallel with a steady upward slope, which is stable flow. The height of a band is the work in progress in that stage, and the horizontal distance from starting work to Done is roughly the cycle time. In the second half the Code Review band widens while the In Progress band narrows and the Done band flattens, marking Code Review as the bottleneck. Values are illustrative. time cumulative items STABLE FLOW CODE REVIEW BOTTLENECK Done Code Review In Progress To Do VERTICAL GAP height of a band is the work in progress in that stage HORIZONTAL GAP from starting to Done is roughly the cycle time AFTER DAY 10 Code Review widens: work piles up. In Progress narrows and Done flattens: downstream is starved, throughput falls. Parallel bands with a steady slope mean stable flow. One band widening while the bands below it narrow marks the bottleneck.

An Example Value Stream Map

Chart

One item's 54 days, split into 12 of work and 42 waiting.

A value stream map timeline with work and wait times drawn to scale A timeline drawn to scale for one item from idea to production. It waits 21 days in the backlog, then design takes 3 days of work, it waits 7 days in the dev queue, development takes 5 days, it waits 4 days for code review, testing takes 3 days, it waits 10 days in the deploy queue, and deployment takes 1 day. Lead time is 54 days, process time is 12 days, and efficiency is 22 percent. ONE ITEM, IDEA TO PRODUCTION · 54 DAYS Backlog 21 days waiting Design 3 days Dev queue 7 days waiting Development 5 days Code review wait 4 days waiting Testing 3 days Deploy queue 10 days waiting Deployment 1 day Lead time: 54 days calendar time, start to finish Process time: 12 days time actually spent working Efficiency: 22% 12 of 54 days; the other 42 are waiting Raised blue blocks are work. Low tinted blocks are waiting. Widths are to scale.

The Shape Up Cycle and Its Three Tracks

Flow

Shaping, betting and building running on one timeline, with the circuit breaker.

One Shape Up cycle with shaping, betting and building shown as parallel tracks A timeline across three columns: weeks one to six building, weeks seven and eight cool-down, then the next cycle. Three tracks run in parallel rather than in sequence. The shaping track runs during weeks one to six, where senior people shape work for a later cycle, producing pitches. The betting track happens in cool-down, where a betting table picks which shaped pitches get a team for the next cycle. The building track runs weeks one to six, where one small team owns one whole project, and resumes in the next cycle on whatever was bet. At the end of the six weeks the work either shipped, or the circuit breaker trips: the project does not get an automatic extension and must be re-shaped and re-bet to continue. WEEKS 1-6 BUILDING WEEKS 7-8 COOL-DOWN NEXT CYCLE SHAPING BETTING BUILDING Shape work for a later cycle [senior people, off the build team] Set an appetite, rough out the solution, hunt rabbit holes, write a pitch. Runs one to two cycles ahead of building. Betting table [a few hours, not a ritual] Pick which pitches get a team. No backlog. Build one whole project [small team, uninterrupted] Fixed time, variable scope. The team decides what the solution is and hammers scope to fit the six weeks. Next bet [fresh six weeks] whatever won at the table Shipped Done inside the appetite. Most projects land here. Circuit breaker trips No automatic extension. To continue it must be re-bet. The tracks overlap in time. While one team builds, someone else is shaping what the next betting table will choose from.

Four Pipeline Patterns

Flow

Sequential, parallel, fan-out and branch-based pipeline shapes.

Four CI/CD pipeline patterns shown as small flow diagrams Sequential: build, test, package, deploy and verify run one after another. Parallel: after build, unit tests, integration tests, a security scan and linting run at once, then join into package and deploy. Fan-out and fan-in: a package deploys to regions A, B and C at the same time, the results are aggregated, then verified. Branch-based: a feature branch runs a PR pipeline of build, test and security scan; the main branch runs the full pipeline including deployment to staging; a release tag runs the production pipeline that deploys to production. SEQUENTIAL PARALLEL FAN-OUT / FAN-IN BRANCH-BASED Build Test Package Deploy Verify One stage after another. Simple to follow and debug. Build Unit tests Integration tests Security scan Linting Package Deploy Independent checks run at once. Faster, more resources. Package Deploy to region A Deploy to region B Deploy to region C Aggregate results Verify Deploy to several targets at once, then collect the results. Feature branch PR pipeline: build, test, security scan Main branch Full pipeline: build, test, scan, staging Release tag Production pipeline: deploy to prod More validation as code moves toward production.

Found this useful? Share it:

Share on LinkedIn