I once joined a team that had been struggling with delivery for the better part of two years. Demos kept failing. Deployments kept crashing production. Rollbacks were so routine that the ops team had gotten eerily efficient at them. (I’ll refer back to the team later — let’s call the company “Acme”).

I remember one in particular. The team was demoing a reactive search feature — the kind of thing where you start typing a product name and suggestions appear in real time. Same idea as typing “penguins” into Google and getting “Penguins of Madagascar” as a suggestion.

The demo cratered. Someone typed a product name, and nothing happened. Twenty minutes of poking around later, the demo was cancelled. What struck me wasn’t the failure itself — it was the reaction. Nobody was surprised. Nobody expected it to work. “Maybe next time.”¹

Later that afternoon, a planned deployment seemed to have crashed a key service. All hands on deck for a rollback. The team executed quickly. Rollback done. They’d had a lot of practice.

Here’s what immediately jumped out at me: in both cases the team had zero operational intelligence. No telemetry. No metrics. No centralized logs. No traceability. No way to quickly zero in on a root cause. They were flying blind — and they’d been flying blind so long they’d forgotten what visibility even looked like.

And that’s why the reaction was the same each time. Abort. Rollback. “Afterward, we’ll figure out what’s wrong.”

The irony is that both failures had quick fixes. Each time, queries weren’t reaching a service because the wrong port was configured. Instead of changing the port and continuing, the team burned hours — even days — backtracking, diagnosing and trying again.

That experience crystallized something I’d been feeling for decades: observability isn’t a tool you add. It’s an architectural decision you make — or don’t. And the cost of not making it compounds in ways that are genuinely difficult to measure, precisely because you don’t have the instrumentation to measure them.

The “flying blind penalty”

In the old days — before cloud, before microservices, before systems became truly distributed — opacity was tolerable. You had a monolith on a few servers. If something broke, you SSH’d in, looked at logs, poked around. It might take hours, but there wasn’t that much territory to cover.

Modern systems don’t afford that luxury. A single user request could traverse dozens of services, touching databases, message queues, caches and external APIs along the way. Just today I participated in a sprint review discussing a database architecture that was 29 views deep. A latency spike could originate in any one of those — or in the invisible interplay between the services that call them.

Without observability, you’re operating on instinct and prayer.

Here’s what that looks like in practice. A bug ships. It doesn’t manifest right away — it surfaces under load, or in a specific user segment, or under certain timing conditions. By the time anyone notices, users are already suffering. Now the team has to diagnose the problem. If they’re lucky, someone complains and provides enough detail to be helpful. They narrow down which service is involved, reproduce the issue, trace the flow of data through the system, find the root cause, fix it, deploy and verify.

The whole time, sweating over how many more customers are running into the problem.

Every single step without observability compounds in difficulty. You’re not just debugging — you’re doing archaeology at midnight, piecing together behavior from scattered artifacts across dozens of services.

With observability designed in from the start, you proactively see which service is degraded. You can drill into specific request traces. You can correlate logs across service boundaries. Mean time to detect and repair drops from hours to minutes — even becoming predictive.2

DORA.dev research bears this out. Elite-performing teams — the ones deploying multiple times per day with sub-hour recovery times — aren’t elite because they have better engineers. They’re elite because visibility closes a critical gap: it’s a prerequisite for every other capability DORA measures. They can detect and diagnose problems before those problems cascade. Their systems are instrumented to answer questions the team hasn’t even thought to ask yet.3

What matters is how you think about the problem

Monitoring and observability are not the same thing.

Monitoring answers questions you anticipated. You watch CPU utilization, disk space, error rates. You set thresholds and alert when they’re exceeded. “Is the database up? Is the error rate spiking?” These are known questions about known conditions.

Observability answers questions you haven’t thought of yet. It’s the ability to interrogate your system’s behavior without adding new instrumentation every time you have a new question. “Why is this specific user’s checkout so slow today when it was fine yesterday? What changed in the request path between those two deployments?”

Charity Majors — co-founder of Honeycomb and one of the sharpest voices on this topic — frames it as the difference between known-unknowns and unknown-unknowns. Monitoring handles the known-unknowns: the things you anticipated might go wrong. Observability handles the unknown-unknowns: the things you couldn’t have predicted. It empowers you to follow the breadcrumbs wherever they lead.4

Monitoring is reactive. Observability is generative — it creates the conditions for discovery.

Daniela Miao, CTO of Momento, put it well in a Dev Interrupted episode: “By giving more visibility into what’s happening with your software, your application, you actually do enable development to be faster as well. It’s not just insurance for when something goes wrong.”5

That’s critical. Most teams think of observability as insurance — you invest in it to cushion the blow when things break. But the real dividend is velocity. Teams with strong observability ship faster because they can see the impact of their changes in real time. They don’t have to guess whether a deployment worked or a tweak to a query ran faster. They know.

Why we don’t instrument on day one

Early stage. You’re shipping fast. Three or four services, maybe. Errors go to a text file. You’re small enough that you can hold the whole system in your head. Observability feels like overkill. “It’s in the logs, just read ‘em.”

Growth. Suddenly there are ten services, and logs are scattered across different servers. You can’t correlate them anymore. Someone says “we should get a logging tool.” You pick one — Datadog, Splunk, whatever — and bolt it on. The instrumentation is inconsistent. Some services are covered, others aren’t. Metrics are sparse and don’t tell a coherent story. You’re reading fragmented logs from disparate systems and trying to correlate events in your head. It’s starting to fall apart.

Pain. Now you have fifty services. Traffic has increased tenfold. Something breaks, and you’re still flying blind — not because you lack tools, but because the observability layer wasn’t designed. It was stitched on, piecemeal, after the fact. Different teams instrumented different things using different conventions. Tracing is incomplete. Metrics don’t correlate with logs. You’re paying more and more for tools that don’t give you the insight you need.

Here’s what’s easy to miss: that team invested in observability. They bought the tools. They checked the box. But because every investment was reactive — a logging platform when logs got painful, a metrics dashboard when someone asked for one, a tracing system when debugging got unbearable — they ended up with three separate systems that don’t talk to each other. Logs in one silo, metrics in another, traces in a third. Every decision about what to capture was made at write time, under pressure, for a specific fire they were fighting that week.

Charity Majors, co-founder of Honeycomb, calls this Observability 1.0: many pillars, many sources of truth, many tools. It’s what you get by default when you bolt observability on after the fact. The fragmentation isn’t a failure of effort — it’s a consequence of timing. You can’t design a unified telemetry model when you’re patching gaps reactively.6

And it matters — because a fragmented model can answer the questions you anticipated (is the database up? is the error rate spiking?) but collapses when you need to ask something new. “Why are checkouts slow today when they were fine yesterday? What changed between those two deployments?” Those questions require slicing across dimensions you didn’t pre-define. They require the kind of open-ended interrogation that siloed tools simply can’t support.

Insight requires design. That’s the part teams miss.

Why does this happen? Because observability isn’t a feature. It’s not something you built first, it’s what got built last. It doesn’t generate revenue — at least not visibly. It feels expensive up front. And teams, under pressure to deliver, don’t demand the time they need for planning a solid foundation.

I’ve written about the same false economy with security and testing. The things that feel expensive to build at the start turn out to be astronomically more expensive to retrofit.7

Why it has to be architectural

You can’t add observability with a library import. You can add logging and metrics — that’s the easy part. But genuine observability, the kind that lets you answer arbitrary questions about system behavior, requires architectural forethought.

Consider what’s involved:

1. How do requests get identified as they flow across boundaries? Trace IDs need to propagate through HTTP headers, message queue metadata, database session context — everywhere a request touches. If you don’t design this in, you can’t correlate activity across services.

2. What events merit recording? Not every line of code should produce a log. That’s noise. But the meaningful transitions — state changes, boundary crossings between services, external calls and their response characteristics — these are the signals that matter.

3. What metrics actually reflect system health? Not just CPU and memory, but application-level indicators. How long do payment transactions take? What’s the cache hit ratio? What’s the queue depth trend? These are the metrics that tell you whether your system is behaving — or trending toward overload.

4. How does context propagate? When a request carries metadata — a customer ID, a feature flag, a request source — how does that context flow through the system in a way that key transitions are captured seamlessly?

This is the shape of how you structure services, how you handle requests, how you organize code. And capturing it after the fact is brutally hard.

For example: if you decide later that you want end-to-end tracing, you need to add trace ID generation at your entry points, thread those IDs through every service-to-service call, correlate logs using those IDs, and store traces in a specialized backend. That means touching every API, every RPC, every async boundary. If you’d built it in from the start, it’s a few lines of middleware.

Consider structured logging: if you’ve been writing freeform string logs for two years, migrating to structured JSON events means auditing every logging statement, retrofitting context and rewriting every query your team depends on. If you start with structured logs, it’s just how things work from day one.

It’s not expensive when you build it in. It’s a handful of decisions, many of which improve things by introducing consistency. OpenTelemetry standardizes the plumbing — trace propagation, metric collection, structured logging — across languages and frameworks. You focus on what to instrument, not how to propagate context.8

But retrofitting: that’s an ordeal. Orders of magnitude more expensive — in engineering time, in tool sprawl and in the debugging sessions that never needed to happen.

What to actually build

Here’s how to do it right — whether you’re making the investment in an old project or starting fresh. The key is to think in events, not pillars.

Start with events, not tools

The most consequential decision you’ll make is how you model your telemetry. Do you emit three separate streams — logs here, metrics there, traces somewhere else — and try to correlate them after the fact? Or do you start with a single primitive: one structured event per unit of work?

The event-first approach works like this: when a request enters your system, you begin composing a structured event — a wide, context-rich record that accumulates everything meaningful about that request as it flows through your services. By the time the request completes, the event carries the trace ID, service name, duration, user ID, feature flags, error state, dependency latencies, cache hits, queue depths — whatever context matters.

You store that event once. From that single store, you can derive everything else: aggregate events over time and you get metrics; filter and read individual events and you get logs; stitch events together by trace ID and you get traces. One source of truth, many views.

This is what Charity Majors calls Observability 2.0 — and it’s the architecture that actually delivers on the promise of answering questions you haven’t thought of yet. Because the events are wide (carrying dozens or hundreds of fields), you can slice by any dimension after the fact. You didn’t have to anticipate the question at write time. You just ask it: “show me all events where cache_hit=false and region=eu-west and latency_p99 > 2s.” If those fields are in the event, you get your answer.

Compare that to the three-pillars approach, where you'd need to have predefined that specific metric, logged that specific combination, and hoped your tracing tool captured the right spans. Three tools, three queries, three partial answers — if you’re lucky.

The event model is the architectural decision. Everything else follows from it.

Establish a trace ID convention

Every request gets a unique identifier the moment it enters your system. That ID propagates through every downstream call — HTTP headers, message metadata, database session context. Every event includes it.

This is foundational. Without it, you cannot correlate activity across service boundaries. With it, a single ID connects every event across every service for a given request. It’s what lets you stitch individual events into a complete trace — the full journey of a request through your system.

OpenTelemetry handles those mechanics gracefully. Use it. It’s language-agnostic, framework-aware and it solves the propagation problem so you don’t have to.

Enrich your events at every boundary

Not every line of code should produce telemetry. That’s noise. The moments that matter are the boundaries and transitions — the points where a request crosses from one domain to another or where state changes meaningfully:

1. Request entry — what arrived, who initiated it, what context it carried.

2. External calls — what you called, what came back, how long it took.

3. State changes — meaningful transitions: a payment processed, a queue depth shifted, a circuit breaker tripped.

4. Errors — always, with full context. Stack traces, request metadata, the works.

At each of these boundaries, you’re not firing off a disconnected log line — you’re enriching the event that represents this unit of work. Add fields: payment_gateway_latency_ms=302, cache_hit=false, feature_flag_new_checkout=true. The event gets wider and richer as the request progresses. When the request completes, it captures the full story.

Make every field structured and discrete. Not a freeform string like “User 12345 logged in from 192.168.1.1” — but named fields: user_id=12345, source_ip=192.168.1.1, session_id=abc, duration_ms=47. Structured fields are queryable. “Show me all login failures for user 12345 in the last hour” becomes a single query instead of a regex excavation.

Derive your metrics from the same data

Once you have rich, structured events flowing through a single store, metrics become a view — not a separate system. You aggregate events to spot trends:

Read more

You’re working on an automotive assembly line. Your job is to install the steering column assembly and steering wheel. The next car rolls down the line. You grab the parts and lean in, tools in hand and try to fit the column. It won’t fit. Something’s off.

You look closely and realize the mounting point isn’t where it should be — it’s offset by a few inches. You figure, you’ll try anyway. No good. Worse, the chassis is aluminum and your steel column will cause galvanic corrosion on contact. You think to yourself — maybe this car is supposed to have something else entirely — a joystick, perhaps? You’re going to need time to research the platform and figure out what belongs here. But you’re out of time. The line grinds to a halt. Delivery stops. Something unforeseen has surfaced, and you need time to research the right solution.

That’s not how automotive assembly lines work. But it is how software works. Building software is about research, discovery and development.

The “big mistake”

Waterfall treats software like an assembly process: define everything up front, hand off designs to builders, assemble in sequence and test at the end. It assumes you know what you’re building before you start building it — the same way an automotive engineer knows every dimension of a steering column before it reaches the assembly line.

The trouble is, software doesn’t work that way. When you’re writing software, you’re inventing something new — combining emerging tools in novel ways to create products that have never existed before. You’re not assembling known parts. You’re conducting research, running experiments and adapting to what you discover. That’s fundamentally a research and development process, not a manufacturing one. It’s more like discovering a new drug therapy than assembling a car.1

And we’ve known this for over fifty years.

We were warned — in 1970

The great irony of waterfall is that the person credited with defining it actually warned us not to use it.

In 1970, Dr. Winston W. Royce — a software engineer at Lockheed who had spent nine years building mission planning and analysis systems for spacecraft — published a paper titled “Managing the Development of Large Software Systems.” In it, he presented the now-familiar sequential diagram: requirements → design → coding → testing → deployment. Then he said this:2

“An implementation plan to manufacture larger software systems, and keyed only to these steps, however, is doomed to failure.”

He said it was “risky and invites failure.” He spent the bulk of his paper explaining why projects should iterate — passing through development “at least twice,” with the first pass serving as a prototype to validate assumptions.

People extracted his diagrams and ignored his warnings.

By 1975, the U.S. Department of Defense had already identified the consequences: a study from the Office of the Secretary of Defense cited requirements changes as the most significant factor in cost growth, alongside poor visibility into development progress and late defect discovery. And yet, in 1985, the DoD formally adopted waterfall as its official software development standard — DOD-STD-2167 — mandating six rigid sequential phases. It took until 1994 for them to replace it.34

The pattern is familiar. The evidence mounts, and the institution keeps doing what it’s always done.

Why waterfall costs more

Barry Boehm’s research at TRW and IBM in the late 1970s quantified what Royce predicted: fixing a requirements error after delivery costs up to 100 times more than catching it during the requirements phase. Even on smaller projects, the multiplier is roughly 4:1. This isn’t surprising if you think about it — in a sequential process, every mistake bakes itself deeper into the foundation with each subsequent phase. By the time you discover the steering column doesn’t fit, you’ve already welded the chassis, painted the body and installed most of the interior.56

This is the hidden tax of waterfall. You pay for certainty up front — detailed requirements documents, comprehensive design specs, elaborate Gantt charts — and then you pay again when reality diverges from the plan. And it always diverges, because software development is research.7

Modern data confirms the cost difference. The Standish Group’s CHAOS Report, drawing from over 50,000 project profiles, found that agile projects succeed at a rate of 42% compared to just 13% for waterfall. Waterfall projects fail outright 59% of the time versus 11% for agile. For large-scale projects, agile approaches are six times more likely to succeed.89

McKinsey’s research found that waterfall-style organizations average 89 days from code completion to production, while agile teams average 15 days. That’s not a marginal improvement — it’s a fundamentally different relationship with time-to-market.10

What does work

If waterfall is a manufacturing process misapplied to research, what does a research-friendly process actually look like?

It starts with acknowledging uncertainty. Software development proceeds through discovery — you formulate hypotheses about what users need, build small increments to test those hypotheses and adapt based on what you learn. Sometimes discoveries open new opportunities you hadn’t anticipated. Sometimes they reveal limitations that force a pivot. Both are valuable signals, but only if your process can accommodate them.

That’s the philosophical shift. But philosophy alone doesn’t ship software. You need a concrete process that embodies these principles — one that’s structured enough to be repeatable but flexible enough to absorb the surprises that research inevitably produces.

An iterative delivery process

The approach I’ve refined over decades — and captured in the Delivery Playbook — organizes software delivery into four overlapping phases: Mobilization, Blueprinting, Delivery and Operations. Each phase contains specific activities, and each activity has clear inputs and outputs protected by quality gates. Think of it as a subway map — you can see where you are, what comes next and what you need before you move forward.11

Here’s why this matters for our conversation about waterfall: every one of these phases incorporates feedback, iteration and course correction. You don’t finish mobilization and hand off a frozen requirements document. You discover your product vision, validate it with stakeholders and revisit it as you learn. Blueprinting doesn’t produce a static design — it produces a target state architecture that evolves as the team’s understanding deepens through techniques like event storming and domain modeling.12

Mobilization marshals the team and launches discovery. You build a product vision, define strategic goals and map your value stream. But you’re not locking anything down. You’re establishing a direction and identifying what you don’t yet know — which, early on, is most things.

Blueprinting is where the real architectural thinking happens. Strategic event storming captures requirements by collaborating directly with the customer — not by having a business analyst disappear for three months and return with a 400-page document. Domain modeling, context mapping and target state architecture emerge iteratively, each activity refining the output of the last. The team builds a shared understanding that no specification document can replicate.

Delivery is where code meets reality. But unlike waterfall’s “build it all, then test it” approach, delivery proceeds in thin vertical slices. You prove the concept-to-production pipeline end-to-end with a steel thread — a narrow slice of functionality that validates your architecture, your deployment pipeline and your assumptions all at once. Then you iterate, expanding from that proven foundation. Each iteration includes specification, elaboration, validation and verification — not as sequential phases but as tightly coupled activities within every increment.13

Operations isn’t an afterthought bolted on at the end. Monitoring, observability and operational readiness are woven into the delivery activities from the start. You don’t discover your system is opaque six months after launch — you instrument it as you build it.

The subway map makes this tangible. Every “stop” on the map follows the same design: goals, inputs, process and outputs. To advance, you need the output from the previous stop. It’s a checklist — not a straitjacket. The structure keeps you honest about following the important steps, while leaving room for the team to adapt their approach, substitute tools and evolve their methods.

The mechanics that make iteration work

Within this framework, specific practices compress the feedback loops, where waterfall stretches across months. For instance, validation of each feature (or “testing”) happens before the feature is coded.

Test-driven development embodies the scientific mindset that software demands. TDD and its cousin BDD aren’t just testing techniques — they’re design disciplines that force you to articulate expectations before writing code, creating a tight feedback loop between intention and validation. We design our experiment before we look for results.

The key insight is blending design thinking with experimentation: you think carefully about what you’re building, then prove your assumptions through working code rather than through documentation and downstream inspection.1415

Shifting left — or moving testing, security and compliance earlier in the development cycle — collapses those same feedback loops. Instead of discovering a flaw in integration testing weeks after you wrote the code, you discover it minutes later, while the context is still fresh. Rather than hastily bolting on observability after a server crashes and customers start hollering, it’s there as a feature from the get-go.16

Every control process you move earlier accelerates the entire pipeline. But waterfall doesn’t allow this to happen: instead, each monolithic stage gate is a barrier stopping the efficient flow of information. It’s creating a static model out of an evolving system.

And crucially, you need a delivery pipeline that integrates experimentation, prototyping and testing as continuous activities — not phases. The steel thread approach I mentioned earlier gives you architectural confidence without requiring everything to be designed up front. You prove the pipeline works before you fill it with features.17

The real cost of “safe”

Waterfall feels safe. It promises control through documentation and predictability through planning. But the safety is illusory. What you actually get is a process that locks in assumptions before you’ve had a chance to validate them, discovers problems too late to fix cheaply and delivers products that may already be stale by the time they reach the market.

The 89-day pipeline McKinsey documented isn’t just slower — it means the product you ship reflects decisions made three months ago. In a market that moves in weeks, that’s not a delivery timeline. It’s a time capsule.

We’ve had the evidence for over fifty years. Royce told us in 1970. The DoD learned the hard way through the 1980s. The Standish Group has been publishing the data since the 1990s. The question isn’t whether waterfall works for software — it doesn’t. The question is why we keep pretending it does.

For more on treating software development as the research process it is, see Stop measuring effort. For practical guidance on shifting your delivery pipeline, see Moving away from the monolith — “shift left?” and The balancing power of TDD. If you’re ready to rethink your delivery approach entirely, the Delivery Playbook is a good place to start.

If you enjoyed this article, consider sharing it with a colleague who’s still stuck in a waterfall process. And if you haven’t subscribed yet, you can do so below — every new article lands directly in your inbox.

Refer a friend

Introduction

This activity is about making sure we’ve taken the time to think about happy paths as well as failure scenarios. It’s about adding fidelity to our use cases so that our finished product is a quality product — one that our customers will enjoy using.

As part of that process, we’ll explore variations on the scenarios in our design. For example, we’ve defined a scenario to make a purchase — but what about when the credit authorization fails? Or the product isn’t available in the warehouse? Or our customer adds a duplicate product to the shopping cart? What should we do if the customer abandons their shopping cart?

Working with your team to think through these scenarios — poking each scenario, prodding to see if it stands up under pressure, adding new paths if it doesn’t — will help ensure our design is solid.

Building better specifications

This activity isn’t just about testing our assumptions — it’s about creating better designs. We want to be sure we’ve thought about how code will be used before we build it. This outside-in pressure tends to produce interfaces that are cleaner, more focused and easier to consume, as well as code that is more reliable.

Read more

The incident

On June 4, 1996, the maiden flight of the European Space Agency's Ariane 5 rocket ended in catastrophic failure. About 40 seconds into its flight sequence, at an altitude of about 3,700 meters, the launcher veered off its flight path, broke up and exploded.1

The cost for this failure was estimated to be $370 million. The rocket was carrying four satellites intended to study the earth’s magnetosphere. Because of the payload’s destruction, building new satellites delayed scientific research into the magnetosphere for four more years.23

An elaborate and careful investigation into the cause of the failure was conducted.

While several factors led to a cascade of events, it came down to a data conversion error — an error that would have been caught in testing.

Unfortunately, the internal SRI software exception that caused the problem was never tested. Or, more specifically, it wasn’t tested in the Ariane 5 configuration. The failure resulted because Ariane 4-era software that used 16-bit signed integers had been plugged into a more modern system — a system that used 64-bit floating point data. The older Ariane 4 SRI software couldn’t cope with the new data format.

That’s the technical reason.

There’s a more important lesson here. The real reason for the failure was human error. Somewhere along the line, a decision was made: the decision that the Ariane 4 SRI module didn’t need to be retested in the new Ariane 5 configuration.

The investigatory board pointed to an underlying theme in Ariane 5 development as a root cause, that theme being, “that software should be considered correct until it is shown to be at fault.” The board took another view. Their belief was, “that software should be assumed to be faulty until applying the currently accepted best practice methods can demonstrate that it is correct.”

Systems must be tested to prove correct behavior. We cannot simply assume they are correct.

Preventable failure

The key takeaways from the Ariane 5 disaster are:

1. We cannot rely on software to be reliable unless currently accepted best practices demonstrate that it is correct.

2. Continuous integration and testing for correctness is necessary — even when correctness has previously been proven.

The Ariane 5 case is widely taught in software engineering courses as the canonical example of how a simple, preventable defect — discovered late in the lifecycle (during operation) — can have catastrophic and costly consequences.

In fact, we know that the longer we wait to discover a defect, the more costly it is to fix. Research dating back to the 1970’s says we can fix a defect in design for nearly zero additional cost — or we can wait until production and spend north of 100 times the cost to fix it later (Boehm, 1979).

This exponential curve isn’t arbitrary. It reflects the reality that as software progresses through development stages, each defect becomes increasingly entangled with other code. Downstream systems begin to depend on it.

A requirements misunderstanding caught in design costs a conversation to fix. The same misunderstanding caught after integration means code rework, integration testing, release cycles, product updates and coordination across downstream dependencies. It can cascade into updating multiple products.

In concrete terms, that $25 defect can be fixed early, “for free,” or we can wait until later and spend $2,500 or more.

And there’s evidence that a 100X cost factor is by no means the upper limit. More recent research, in some cases, point to a factor of 1,500X cost to correct defects in operations. That $25 design defect just turned into a $37,500 cost to correct. There’s no upper limit — as the Ariane 5 team learned. (If you’re interested in reviewing more recent data there are references to NIST, NASA and Westland research in the footnotes).456

But there’s good news. We know how to prevent failures: By applying software quality assurance policies and practices — and pairing them with rigorous software testing.

Applying best practices

Test Driven Development (TDD) and Behavior Driven Development (BDD) are fundamental strategies to move defect detection left on the graph — ideally all the way to the design phase where cost is lowest.

Both practices create proofs that prevent defects. What’s more, they rely on executable specifications that prevent regression. Even after initial development, the test suite continues to catch defects early. A change that inadvertently breaks existing behavior is caught in seconds during the next test run — not discovered in production by users.

This ongoing protection is particularly valuable as systems age and original developers move on — the tests preserve institutional knowledge about intended behavior. Imagine how powerful it would have been if the Ariane 4 SRI module had included a continuously run regression test sequence.

The fundamental promise isn’t about testing — it’s about creating better designs. Both practices demand writing tests first. That forces thinking about how code will be used before thinking about how it will be built. This outside-in pressure tends to produce interfaces that are cleaner, more focused, and easier to consume, as well as code that is more reliable.

The deeper point

TDD and BDD aren’t really about testing at all. They’re about feedback loops and thinking clearly about intent before implementation. The tests are a byproduct — valuable, but secondary to the discipline of thoroughly articulating what you want before you build it.

Critics often attack the testing artifacts while missing this point entirely. It’s not always about going faster or whether every scenario needs to be test-driven. It’s whether your development process includes mechanisms that force clarity of thought and protect against regression. Both TDD and BDD are proven ways to achieve that.

TDD or BDD?

TDD catches implementation errors immediately. When you write a failing test before writing code, you discover mismatches between intent and implementation within minutes, not days or weeks.

The feedback loop is so tight that “debugging” often becomes unnecessary. When a test fails you know exactly what change caused it.

Compare this to traditional development where bugs lurk undetected until integration, verification or even user experience — by which point the original context has faded. Investigation becomes archaeological, time consuming and costly.

What TDD does well is clarify the boundaries of your system. Code that’s hard to test is often code with unclear responsibilities or excessive coupling. Even if you don’t achieve full coverage, attempting TDD reveals where your architecture needs attention.

But TDD has a limitation: it doesn’t “shift left” enough on our error discovery graph.

TDD is largely a technical exercise, focused on functional specification. As such it can get deep into the weeds of a feature — but may fail to rise to the level of product behavior. In other words, we might be applying our test-driven thinking to a conceptual design that is already defective.

That’s why I prefer BDD.

Behavior Driven Development

Behavior Driven Development is a collaborative approach that evolved from Test Driven Development. It bridges the gap between technical and business team members by expressing specifications as concrete examples, written in plain language everyone can understand (the “Given-When-Then” style, or Gherkin format).

Read more

A daily standup is a great idea — provided it’s done right.

A well-run standup:

1. Is a place to foster collaboration and mindshare.

2. Provides a forum to get help.

3. Makes sure the team doesn’t spiral.

Unfortunately, most standups that I join don’t do any of these things. Quite the opposite. These standups impede productive work, acting as a needless interruption that offers almost no value.

More often than not what I see is a team forced to stand together while each team member robotically itemizes their work since the last sprint. In some miserable cases, the “PM” and one or two team members hold the entire team hostage while a specific problem is diagnosed.

The standup stretches to 30 or 40 minutes. Your eight person team takes a cumulative five hour hit to their productivity.

Create value in your standups

If you Google “questions to ask at a standup” you’ll find the worst culprit sitting right at the top of the list: “what did you do since yesterday?”

Ban this question.

Almost just as bad is, “wha…

Read more

In the previous article I introduced a foundational architecture for our data pipeline, checking off several of our requirements. Here’s a quick recap:

1. We leveraged an internal cache for isolation to break our dependency on external data sources, improving our resiliency and scalability options.

2. We introduced the idea of an asynchronous message architecture, so we aren’t bound by lengthy, sequential processes.

3. We keep our annotations long-term with internal persistence so we don’t reprocess data when unnecessarily.

4. Source data as treated as an immutable source, thus protecting our data integrity.

5. Our visualization layer is responsive, running off our internal cache so that it’s independent from other components.

Here’s a sketch of the architecture as it stands now:

It’s a good start, but we aren’t finished.

There are still two requirements that don’t have a clear solution:

1. We want to be able to reprocess data, effectively “rewinding history” and applying new analytics. For instance, if we add a new analysis and insight to our pipeline, how are we going to go back and view that new analysis on old data?

2. Finally, we want to be able to model our insights — that is, visualize it in a presentation layer. But we haven’t talked about how that’s going to happen.

Once we tackle those last few requirements, we’ll fill in some details — such as, deciding on a cache technology to use. We’ll also take an end-to-end look at what we’ve designed to see if we missed something important.

Finishing our foundation

One of the most powerful and underused capabilities in data analytics is the ability to reprocess historical data with new logic. When you fix a bug in your analysis or refine a calculation, you often want to know: “what would the last three months have looked like with this new logic?”

Fortunately, our design thus far aligns pretty well with this goal.

Essentially, all we are saying we need to do is throw out information that is no longer accurate and then reprocess the source data and rebuild a new and improved picture of the world. We might do this for a couple of reasons:

1. We changed our analytics. Consequently, we need to throw out all of our old findings and recalculate our insights.

2. The source data changed. Perhaps there was a historical data update, invalidating our findings. Again, we want to throw out our findings and reprocess.

Looking at the problem from that perspective, the architectural answer is simple: we need a way to delete our annotations.

Once we wipe our annotations, we’ll need to make sure they are recalculated. There are different strategies we could use, but for the most part our options are:

1. Rebuild our annotations on-demand. This is fine if we’re OK with a bit of a delay while we wait for analytics to run. Depending on our visualization strategy we might be able to break the work up and trade one big delay for a few small delays.

2. Alternatively, rebuild our annotations preemptively. We might do it as soon as we realize there’s data to analyze, or perhaps we have some kind of schedule or external trigger. The point here is, we run the analysis before we think a user will want to visualize it.

We’ll add these capabilities to our architecture diagram. That means responding to both external data changes as well as internally sourced changes.

Rewinding history

To “rewind and reprocess,” we’ll just delete our annotations and then make sure there’s a mechanism to rebuild them. Here’s an example chain of events we’ll model in our architecture:

1. Administrative user invalidates some (or all) of the annotations we’ve stored in our cache:

   1. Optionally, if the data was invalidated because source data changed, the system loads fresh data from the external data source.

   2. The system deletes or otherwise invalidates the annotations in our cache.

   3. An event such as “analysis invalidated” (with some metadata, perhaps a date range) is emitted.

2. The analytics service is listening for events, and receives the “analysis invalidated” event:

   1. The event includes the date range of deleted data. The service checks the date range to see if annotations are missing from the cache.

   2. If the data is still missing, it runs the analysis and rebuilds the missing annotations.

   3. As annotations are rebuilt, they are written to the cache.

   4. An event such as “analysis completed” (with some metadata) is emitted.

3. Separately, a visualization service might be running where a user asks to display the visualization for some missing data:

   1. The system checks the cache, realizes annotations are still missing, and sends a “run analysis” message directly to the analytics service.

      1. The analytics service is already working on analyzing the data so it can ignore the message, or respond with an “analytics in process” message.

   2. The visualization presents some kind of “waiting for analysis” display while it listens for the “analysis completed” message. When it receives the message, it loads the annotations and displays them.

This is one way to handle a specific chain of events. We’ll need to handle other events and commands as well — such as an event to tell us external data has changed.

Since we’re talking about responding to events that happen, it makes sense to use event storming to model those events and commands. We can model “things that have happened” (the events) as yellow cards, and “what we want to happen” (the commands) as blue cards.

If you need a refresher, Chapter 2.3 Strategic event storming and Chapter 3.4 Tactical event storming provide in-depth explanations on modeling event driven architectures.

Here’s an updated architectural drawing showing how our events and commands interact with the system:

Persistent annotation cache

One of the things we haven’t decided yet is exactly how we’ll store our annotation data. There are quite a few options, and certainly more than one strategy that will work well.

In part two I hinted at using a relational database to store a copy of the external source data. This makes a lot of sense, but it isn’t the only option.

We could store all of our data in a persistent data store such as MongoDB, a noSQL document-oriented database. Document databases offer some fantastic search capabilities and, perhaps most interesting, don’t force us into a predefined schema — we can, essentially, attach anything as our annotations.

That’s a nifty idea, because we want flexibility to change our data analysis and come up with new data sets to store, freely associating them with source data.

We could also stick with a purely event-driven architecture. In this kind of system, we would emit annotations as events into a persistent queue (such as Kafka). The persistent queue becomes our source of truth — and annotations are just messages on the queue, like, “sprint X: total out-of-sprint hours: 500.”

With many options, it’s probably a good idea to decide on our business requirements:

1. Obviously, we want to cache the original source data, so we aren’t tightly coupled to an external system. (We know the external system is a relational database).

2. We want to easily create new annotation data sets. If we dream up a new calculation (maybe, “number of activities completed after hours on Fridays”), we want to be able to store it easily.

3. We know we’re using DataFrames for analysis. Storing our DataFrames without translating them into something else would be convenient (but not necessary).

4. Our annotation data should be persistent (to avoid unnecessary delays rerunning an analysis) — but, once a particular report or visualization is no longer being used, we probably don’t need to keep it around.

5. Finally, we’ll want to think about performance and wait times. We definitely don’t want users to experience a slow system.

The relational cache for source data still makes a lot of sense.

For our internal annotation data, something more flexible is desirable. We don’t want to be constrained by a relational schema, forced to update the schema every time we think up a new report or annotation.

While a noSQL solution seems like a good fit, it may be an unnecessary complication. It would afford long-term persistence, but unless we run into performance problems that long-term persistence may be pointless.

Designing for flexibility makes sense.

We’ll implement our internal annotation cache as a service. The service will:

1. Allow us to store annotations (data structures) in a persistent fashion (but, not necessarily permanently).

2. Provide a shared data service (allowing other services to leverage the shared data).

3. Give us scalability (we can boost processing power or memory, start up multiple copies, or upgrade to a more powerful data store technology).

4. Allow us to start simple, just storing annotation data in memory. A long-running service might give us all we need (after all, we’d only rebuild our annotations if we restart the server).

Let’s update our architecture diagram one more time:

Read more

Introduction

This activity creates fidelity in our engineering models — the diagrams and specifications that give us enough technical depth so we can proceed to coding.

Everything we’re going to build should be modeled. That might sound like of lot of work, but with the right drawings and specification style, it’s not — plus, our models should be reusable. For instance, once I’ve modeled my implementation of a circuit breaker, I don’t have to model it again. I can just use that circuit breaker design everywhere I need it.

The approach I’ll introduce here increases the fidelity of your technical designs using data inputs and outputs, paired with very clear and specific functional results. It builds on your existing engineering artifacts and further validates your value stream, making sure alignment with business objectives is maintained. We capture our control processes and at the same time enhance communication among those designing the solution.

One of the challenges with modeling is deciding on what’s effective yet not overly constraining or complex. We want to define some clear standards of practice and make sure the engineered product is fit for purpose. At the same time, teams should have the flexibility to take a different path if that different path is more fit for purpose.

The modeling approach we use in the Delivery Playbook meets those goals:

• We define engineering artifacts using two specific diagram types, neither of which are difficult to understand or use.

• Clear objectives are defined while giving teams enough freedom to follow a different path — so long as those objectives are met using whatever approach they choose to follow.

Read more

In the previous article I introduced data pipelines, highlighting their ubiquity and a few of the challenges you’ll face architecting a good data pipeline. Here’s a quick recap of those requirements:

1. Moving data efficiently. Pipelines are all about making sure the right data gets to the right place at the right time, in the right format. For many applications, like air traffic control or the stock market, timing is everything. The architecture has to scale, meeting demand without degrading — often with life-saving implications.

2. Data integrity. This is about ensuring the source data is what we think it is — incorruptible, unchanged as it moves through the pipeline. We have to make sure there’s no data loss, no translation errors, no dropped information. Yet, at the same time, pipelines are fundamentally about processing that data, deriving new insights from it.

3. Non-destructive annotation. Being able to add to the data in the pipeline efficiently and flexibly is key. This makes it possible to create new insights from the source data — but it implies a schema that can grow in unpredictable ways.

4. Rewinding history. Pipelines evolve, refining their algorithms and adding new processing steps. When we fix a bug or refine a calculation, we need to know, “what would the last three months have looked like with this new logic?” If we can’t reprocess the data we’ll never know if an inflection point in our analysis was due to a different calculation or new business conditions.

5. Surfacing discoveries and creating actionable insight. All of these steps need to culminate in actionable intelligence. Getting those pieces to work together, then correlating all that disparate data and presenting it clearly, logically, can present its own challenges. Does the data processing sequence matter? How does one element depend on another? What happens when your analysis depends on external data or fundamentally different data structures?

In this article, we’ll develop a foundational data pipeline architecture. I’ll approach the architecture iteratively — beginning with something simple, exploring whether it fits our purpose, and refining it. Our final architecture will provide a foundation that can grow into a scalable, powerful data pipeline platform.

For our use case, we’ll design an application that tracks team activity across projects in an organization. Our goal in tracking all this information is to deliver new business intelligence that gives useful, actionable insights into team efficiency across the organization. That’s intelligence we can use to remove bottlenecks, improve team productivity and velocity, eliminate wasteful process and more.

What are we measuring?

Before we get started, it’s a good idea to know what we’re trying to influence. We want to surface insights, not just tables and charts. The difference between data and intelligence is whether it impacts our decisions.

Actionable intelligence changes what you do next.

For our test case we want to develop a better understanding of team efficiency. There’s an existing body of work that covers this topic, and we’ll leverage it.

Our plan is pretty simple. Following the principles of a waste walk, we’ll have team members tell us whether their day-to-day activities are creating bottlenecks or inefficiencies or draining their effectiveness. They’ll do this by capturing activities and marking them as “in sprint” or “out of sprint.” (If you aren’t familiar with those terms, take a look at part one of this series).

We’re going to assume this data is available — perhaps coming from a JIRA dashboard or other time tracking application. I’ve actually built a mobile-friendly application that does this. It’s part of a waste walk analytics platform in use today. For our purposes, what matters is the data — not the mobile app.1

The data schema is straight-forward. Team members are Users, they track their individual Activities, and each Activity belongs to a Sprint.

If we diagram out the basic data model, it would look like this:

As you can see, Teams are also modeled (so we can manage sprints and their team members as a group), and every activity has an Activity Stereotype. These stereotypes are basically the kinds of activities team members can track in the system. They can’t just record a random event; instead, they pick an activity from a list of “stereotypes” like “meeting,” “writing code” or “story refinement.”

We’ll take a look at the specific fields in a little while. For now, we have a conceptual understanding of the data — that’s what we need to move forward.

Data versus insight

Given the data we have available, we need to ask ourselves: what kind of insights can we derive from the source data? How might those insights change our behavior?

Here are a few ideas:

1. If team members spend too much time doing activities that could be automated, we’d want to prioritize automation — letting those team members get back to more important work.

2. If a lot of time goes into investigating defects, we would probably want to know about it so we could investigate why we have so many defects (and fix the root cause).

3. It would also be informative to know when the team works on fixing defects; is it after the product ships, early in design, or somewhere in-between? Early defect correction is much better than late defect correction.

4. A lot of planning late in the product lifecycle — for instance, planning after a sprint has started — might indicate opportunities to improve coordination or design process. Late-stage planning often creates bottlenecks for team members.

5. If individuals feel their time in sprint ceremonies and meetings is not productive, we should probably investigate why they feel that way — especially if it’s a lot of time.

6. If we knew how many different things team members had to juggle, it might influence how we prioritize work and focus time for the team.

7. Probably most important: we want to know, across the organization, exactly how much time is going into inefficient or wasteful activity. A small amount is fine, but in aggregate, the time and effort lost could be costing us more than we realize.

I’ve done these kinds of analyses for many teams — and the insights are almost always transformative. Just one example: one team found they were spending close to 23% of their time on activities that could be entirely automated. The effort was spread out, of course — an hour here, another there. At an individual level, it was about a day’s effort each week, tweaking manual deployments, doing environment tuning, “sanity testing” in staging and production.

Now scale it up. For a team of eight, that’s 150 hours per sprint. Stated another way, by investing in automation, the team would get back 150 productive hours every single sprint and their quality of life would be improved at the same time. Knowing those numbers, prioritizing Infrastructure as Code (“IaC”) for deployments, automating those repetitive “sanity tests” — suddenly makes a lot of sense.

Transforming raw data into insight

We know what data is available to us. But how do we transform it into actionable intelligence we can use to create better outcomes?

The raw data doesn’t really get us there. That’s where the data pipeline comes in — by transforming that data into something we can use:

1. First we need to “intake” our source data. Once we can access it, we can analyze it, of course.

2. Then, we transform the data into what we need. We aren’t planning anything overly complicated (at least, not yet). Here’s the gist of what we need to do:

   1. Separate “in sprint” versus “out of sprint” activity. We’ll be focusing on the out of sprint activities or, in Lean Engineering terms, the “non-value add” effort. This “non-value add” work is where we’ll find our biggest gains.

   2. Summarize data about activities. For example, we’ll need a way to add up all the activities that could be automated. That tells us how much effort is spent here.

   3. We also want to be able to count up and somehow tally the time between activities (the “context switching time”) for each team member — probably as some kind of aggregate or average number.

3. Of course, we’ll want to visualize the results.

That all seems very straight forward. The first logical step is to think about how we’re getting our source data.

Start with the source data

The first thing we need is our source data. Fortunately for us, it’s readily available and easy to access.

Our tracking application stores all this activity data in a SQL database, using a traditional relational format. That makes a lot of sense — it’s a relatively static data structure, and the relationships between teams, users, sprints, and activities are clearly hierarchical.

One approach is to just read the data directly from the SQL database. This would be the easiest solution. Once we read the data, we can perform our calculations, add in the context switching data, and display it:

This does raise a few interesting questions, though:

1. What happens if the source data changes in some way or if we can’t access the SQL database when we want to display our data?

2. How, exactly, are we going to store the results of the calculations and annotations?

3. Does this mean that every time we display the results we have to run through the entire pipeline, reading the data, performing calculations and then displaying our findings?

4. How does constantly accessing an external database impact our performance?

Data integrity and availability

We want our application to be highly available and reliable.

The problem is, we’ve created a dependency on an external system — the SQL database. If the external system changes or just isn’t available when we need it, we’ve got a problem. It would break our data pipeline. We need a solution that ensures both the integrity of the data as well as its availability.

The simplest solution is to just copy the data and keep a local cache of it. Whenever the source data is updated, we can update our local cache. If something goes wrong — for example, the data format changes or we can’t contact the SQL database — we can keep using our local cache until we fix the problem. That gives us high availability.

This also gives us a degree of certainty about the data format.

While the external SQL database might change, our internal cache can potentially remain constant. For example, let’s say the external database is using an Integer data type for activity duration, but at some point they decide to change it and start using a Time type instead. Since our local cache is under our own control, we have a few options:

1. Update our local cache to use Time as well, and change our pipeline code accordingly.

2. Convert the incoming data from Time to an Integer and store that. Leave our code as-is.

3. Decide to use a completely different type, like Duration, in our internal cache and make similar changes to our code.

Our strategy would depend on the situation — but we have options. We’ll examine a few different ones in a bit, but for now we’ll just note the internal cache in our architecture.

Adding a cache to the architecture might look something like this:

I’ve added an “ACL,” or “Anti-Corruption Layer,” to the intake process. ACLs are used to protect the data integrity of our domain — in other words, we don’t control the external SQL database but we do control our internal cache. That cache can, for instance, use a Duration to represent the passage of time regardless of how the SQL database represents time. The ACL is where we translate from the external format to our internal, domain-specific format.

It gives us a nice layer of isolation from external change. Generally speaking, creating isolation between services is a great strategy for improving reliability (as well as scalability — more on that later).

Benefits of isolation

I pointed out that by copying external data into our own system we are creating isolation. This is an important architecture topic for a few reasons:

1. Isolation means we are not inexorably dependent on an external system. If that external SQL database goes down, or the data changes, we can still function.

2. We also get architectural independence. If we decide to change the structure of our internal data cache, we can. It’s under our own control.

3. Being in control of our own data architecture also means we’re in control of our scalability. If our data analysis product becomes the hottest thing since sliced bread, we can scale up. We might add more servers to our cache, or we might evolve our architecture toward CQRS patterns — we’re in control, and it’s all hidden behind our product API.

From this perspective, copying data is a good idea. We need to remember there’s an external source of truth. But we remain in control of when we run data intake, how we change the data on the way in, and how our own data is structured.

Powerful, non-destructive annotation

Our original requirements include making sure that we maintain our source data integrity. The best possible approach in that regard requires two things.

First, we have to capture every record, in its entirety. That ensures we won’t miss anything important (including the possibility that something becomes important later, even though we thought it wasn’t important at first).

Second, we can’t change what we capture — we can only add to it. This means our analysis and data annotation can’t alter the source data — it’s immutable. We have to find a way to piggy-back or pair our new data with the raw source data.

We’ll leverage that in our code. Let’s say, for instance, you wanted to find out how many seconds of “out of sprint” work each user tracked in a sprint and you also want to make sure paid time off is not included in that number. Here’s a very simple example, using a snippet of Explorer code:

data
|> DF.group_by([“user_id”])
|> DF.filter(stereotype_code != "pto")
|> DF.summarise(out_of_seconds_sum: sum(out_of_sprint_seconds))

Data is just an array of raw data records. The group_by line groups all records with their respective team member. Then, with filter we make sure paid time off is not being included. And finally, we sum up all the out_of_sprint_seconds and put the result in a new variable, out_of_seconds_sum.

Two important things to note here: first, we haven’t altered the source data in any way. Second, we’ve annotated our data set by associating that new variable, out_of_sprint_sum, with our DataFrame.

We’ll explore this in depth soon. For now, I just wanted to give a quick taste of what we can do and explain why it’s valuable.

Tackling data analysis

We’ve decided how we’ll get the data, but there’s more work to do. How are we going to perform our calculations and store the results?

Read more

These past few months were very busy. I had two projects compounded on top of each other — one, a client modernization effort; the other, a new release of an analytics tool we use with our customers. It was more than I like to take on at one time and, yes, I got a bit burned out.

Which is a good reminder — prioritize your well being!

Work will always be there. Life will pass you by.

Recharge in Malaga

After getting all the work out of the way, we took some time to recharge: a few weeks off in Malaga.

Read more

Why data pipelines are interesting

A data pipeline moves data to a destination, transforming it along the way, turning it into something useful.

It’s like a factory assembly line. But, imagine you’re assembling data. Raw data is your source material entering at one end. It goes through various processes and comes out the other end as finished product (clean, structured data ready to use).

For instance, air traffic control systems process data from multiple radar stations, transponders, weather sensors, and flight plan databases to build a real-time picture of airspace. A picture humans can interpret in a split second. An air traffic control system:

• Ingests position data from hundreds of aircraft every few seconds.

• Correlates radar returns with flight plans and transponder signals.

• Filters out noise, birds and ground clutter.

• Predicts flight paths and potential conflicts.

• Integrates weather data to route around storms.

• Handles sensor failures gracefully — if one source goes down, seamlessly switching to backup sources.

Controllers need accurate data within seconds, and failures can have catastrophic consequences. They need real-time data, rather than batches, with real-time redundancy and validation.

Data pipelines are fundamental to modern data infrastructure. A good pipeline makes sure the right data gets to the right place at the right time, in the right format.

If you think about it — that’s the foundation of just about everything in our data-driven modern society.

When it comes to projects that will evolve your mastery over data management, building a data pipeline is one of the most challenging and rewarding. That’s why, in this multi-part series, I wanted to do a deep dive into a data pipeline — including design, architecture and code. In this series, we’ll get hands-on and explore how to build an app that analyzes complex streams of data.

Creating actionable intelligence from data

Data pipelines start with the raw, source data — from wearables, instrumentation, monitors, databases, mobile devices. An Airbus A380 is fitted with up to 25,000 individual sensors. Each one of those is sending raw data that may need to be acted upon quickly. That raw data goes through different processes — cleaning, filtering, combining, reformatting — before landing in its final destination, which might be an instrument, display, data warehouse, analytics tool, or application.

Clearly, copying and interpreting all that data by hand is impossible. Instead, the data pipeline does it automatically, often as a real-time feed that transforms information on the fly. It ensures data moves reliably and consistently.

Raw data is often messy or in the wrong format. The pipeline transforms it into something useful — removing duplicates, standardizing formats, calculating metrics, or joining information from multiple sources, as with the air traffic control example.

Often, data pipelines are event driven. This just means they consume a sequence of events from the real world — some fact that already happened — then turn it into actionable intelligence.

“Actionable intelligence” just means some kind of information you can use. For instance, the fact that a stock price dropped could be turned into an automated buy order for that stock. An e-commerce company might have a pipeline that pulls daily sales data from its sales database, combines it with inventory data, calculates key metrics like revenue per product, and loads everything into a dashboard where executives can see performance at a glance.

There are a lot of moving pieces. Getting those pieces to work together, then correlating all that disparate data and presenting it clearly, logically, is hard. There are challenges to doing it well, which I’ll talk about below.

Preserving data integrity

One of the most important things a good data analysis tool — and data pipeline — needs is a guarantee of data integrity. In this case, data integrity means the data is exactly the data we think we are analyzing. This sounds obvious, but it’s surprisingly easy to get wrong.

Here are some common pitfalls, all of which we need to design against:

• Silent data loss: Information dropped during joins, filtering, or transformations without warning. For example, only capturing summary data or a subset of available data instead of recording (and keeping) everything.

• Type coercion errors: Numbers becoming strings, dates and time zones handled incorrectly, or precision lost in conversions.

• Encoding issues: Data corruption caused when moving between systems — something as simple as assuming an input field uses Latin characters instead of Unicode.

• Partial updates: Only processing some records, possibly ignoring “uninteresting data,” or failing to capture records that don’t process correctly.

• Implicit assumptions: Null handling, unexpected data volume, unexpected inputs or missing parameters, duplicate treatment, or sort order that changes behavior unexpectedly.

Good data pipelines preserve integrity.

In the second article in this series we’ll dive deep into data pipeline architecture and address each of these potential pitfalls.

Annotating data

We also need a way to evolve our data over time — that is, add to it in a way that we don’t end up breaking our data integrity rules.

Raw data rarely speaks for itself. A transaction table tells you what happened, but not why. A spike in errors shows something broke, but not what you were doing at the time. Good data tools let you add context and turn numbers into understanding.

Annotations work at multiple levels. At the record or event level, they document what the data represents, adding fidelity. A data analyst might add a “review” tag to what looks like an accidental double-entry, or a prescription drug regulatory pipeline might link together other drugs that treat similar symptoms.

At the macro level, annotation can build on a core data set, adding new information. Data from multiple sources can be combined to create a more complete picture. Hard-to-perform calculations can be run and attached to existing data, making it easy to extract more meaning later. Later, in our example use case, we’ll do this by annotating our data set for further exploration.

Annotations compound over time. Six months later, when someone investigates why something looks unusual, annotations lead to new institutional knowledge. Without them, context can be lost and every new analyst has to rediscover what happened.

Surfacing insight

Data analysis tools should surface insights, not just tables and charts. The difference between data and intelligence is whether it changes what you do next.

We need the right level of aggregation and annotation: too granular and patterns disappear in noise; too macro and you can’t identify root causes.

Start by focusing on decisions. Before building a dashboard, a report or a graph, ask what decision it will inform. If the answer is vague or simply, “it’s good to know,” it’s not actionable. Every result should express some clear, specific action.

Make the analysis do the work, not the reader. Instead of showing a table of conversion rates by channel, highlight which channels are underperforming, by how much and why. Instead of a trend line, show whether or not execution is deviating from planned goals and exactly how it changes your delivery plan.

Focus on metrics that lead to human action. Also, tune thresholds to minimize false positives. For example, it may be useful to “clean” a data set by removing anomalies and peculiar outliers. We’ll do that in our example app, effectively removing data that is suspicious and likely just “noise.”

The goal is to inform clear action. If it requires tribal knowledge, domain expertise, further exploration or twenty minutes of interpretation, it’s not yet actionable.

“Rewinding” history

One of the most powerful and underused capabilities in data analytics is the ability to reprocess historical data with new logic. When you fix a bug in your analysis or refine a calculation, you often want to know: “what would the last three months have looked like with this new logic?”

This is harder than it sounds. If your pipeline only processes new data, historical numbers are frozen with old limitations or bugs. You end up with charts where the methodology changes partway through, making trends impossible to interpret. “Revenue increased 20% in March,” but we’ll never know if it was growth or if it was due to a changed calculation.

Point-in-time correctness makes this possible: storing raw events or source data permanently, without changing it or pre-processing it. When you need to revise analysis, reprocess the historical data through the updated pipeline. The results of that processing becomes annotation to the data — ultimately, annotations that we can throw out and do again using a new approach. We look at data as an entire time series, a record of facts that happened in the past — and are, therefore, immutable.

But this means treating our analysis and transformation logic as code, not ad-hoc formulas or manual actions. The source data must never be altered — only our code, and the annotations and analysis it produces. That gives us a documented data model, not tribal knowledge about which column means what. The goal is reproducibility: given raw data from any date and a specific version of your data pipeline, you can create an exact analysis for any timeframe.

Building a data pipeline

I promised a deep dive into the design, architecture and code of a data pipeline. There are a lot of use cases — stock trade analysis, weather data, genomic research, geologic tremor research, the list is probably endless.

For this deep dive, we’ll explore an application that tracks team activity across all the projects an organization is working on. Our goal in tracking all this information is to deliver new business intelligence that gives useful, actionable insights into team efficiency across an entire organization.

We’ll build the application in stages, showing its evolution and developing a solid foundation for a data pipeline.

Using the app, team members will track their activities across various tasks, but unlike most “time trackers” they’ll be able to annotate their time as “in sprint” or “out of sprint.” These are defined as:

1. In sprint — essentially, “this is work that contributed direct value to my sprint goals.”

2. Out of sprint — this represents everything else, essentially, “this is work that I had to do, but it didn’t contribute value directly to my goals — it may have even slowed me down.”

We’ll scale this up across an entire organization. For a large organization, that means hundreds of teams, thousands of team members and tens of thousands of individual tasks. It’s a sizeable volume of data to work with, but in terms of what data pipelines are capable of it’s still pretty small (think about the volume of data flowing through the stock market, in comparison).

We’ll need a way for team members to capture day-to-day work, quickly and easily. This will become our data source, pushing data into the pipeline in real-time:

All the activities will flow into our data pipeline. We’ll capture those individual activities, but we need to look at the data in aggregate — from an organizational point of view. This means being able to annotate and analyze the data from different perspectives.

Looking at the data as a stream of events over time, we can “slice and dice” it. We can also compose the data with other analyses, all to produce actionable intelligence. That means being able to aggregate the data and run on-the-fly analysis across different segments of data (for example, being able to take a “slice” of data across four teams out of the entire organization):

We also want to perform detailed analysis. In our activity tracking app, we’ll show time the team spent on manual activity that could have been completely automated — letting the humans on the team spend their brain power on more valuable tasks:

As we discussed above, a good analytics platform also supports annotation — that is, being able to combine new data with existing data.

In our case, we’ll calculate how much time is lost to switching from one task to another. We’ll combine that analysis with pre-existing data to create new insights. Here we show the impact of giving the team more focus time:

Summarizing our goals

From a business perspective what we want to achieve with the activity tracking app doesn’t seem complicated:

1. Give team members a place to easily and quickly record their activities (what they did, how long it took).

2. Let them tag work that falls “outside” the sprint — representing work that, while potentially necessary, didn’t really contribute direct sprint value or move their goals forward.

3. Aggregate data across the entire organization to discover meaningful trends.

4. Expose action that we can take — action that will have an immediate impact on efficiency, productivity — improving “ways of working” across teams.

This is something that most organizations are working on — in fact, most are working on efficiency and productivity goals right now.

But the reality is, it’s complicated. There are competing concerns, unclear cross-organizational goals, a lot of noise to filter out, activity that may be necessary but might not seem necessary. How do we accurately analyze and filter it down into clear, actionable intelligence?

There are solutions. Ideas built on decades of rich, scientific research and business process evolution. Perhaps most famously, Toyota empowered their employees to do whatever it took to streamline automotive production lines. Toyota’s concepts regarding just in time production are deeply embedded in the foundations of Lean Manufacturing. Taiichi Ohno is widely regarded as having pioneered effective techniques for eliminating “wasteful action” in day-to-day work (Muda, a Japanese word meaning “wasteful”).12

Our application will build on that, gathering activity data and turning it into an actionable, live stream of insight about organizational health.

We’ll need to stay true to the critical concerns outlined in this article: preserve data integrity, focus on annotation not transformation, build a system that always delivers actionable intelligence and, perhaps most important, make it possible to “rewind and replay.” As our algorithms evolve and mature, we’ll want those insights to be applied retroactively.

Coming next

We’ve outlined our requirements above. Next up is defining the architecture, the “blueprinting” phase. That’ll be the topic of the next article in this series. By the end of the third article, we’ll have a concrete roadmap as well as an architectural foundation — a steel thread that we can build on to deliver a proof of concept in one or two sprints worth of work.

If you’re following along in the Delivery Playbook, we’ve just about finished our mobilization phase. We’ve got a product vision and we know what the product’s capabilities and functions will be.

If you find Customer Obsessed Engineering and the Delivery Playbook valuable, please share it with your friends and coworkers.

Share Customer Obsessed Engineering

Most teams are building on quicksand and calling it solid ground.

You’ve got 95% test coverage. Your CI pipeline is green. Your unit tests pass every time. You ship with confidence, and then — crash — production burns down because of an edge case nobody thought to test. The user entered a 37-character string instead of 35. Someone sent a negative timestamp. A list came back empty when your code expected at least one item.

Sound familiar? Here’s an uncomfortable truth: traditional unit testing is fundamentally inadequate for building reliable software.

Unit tests are like taking a single photograph of a mountain and claiming you understand the entire landscape. They capture one specific moment, one exact scenario, but they miss the infinite variations that real users will throw at your system. They’re missing the crevasses, caves, and sudden unexpected features. They’re necessary, but they’re not sufficient.

After decades of building and shipping software — from startup MVPs to mission-critical systems handling millions of transactions — I’ve learned that the teams who ship bulletproof software have one thing in common: They know that testing specific use cases is inadequate.

They don’t buy into the illusion of safety that unit testing offers. They use property-based testing.

Property-based testing doesn’t just find bugs. It finds entire categories of bugs you never knew existed. It’s the difference between checking that your bridge can hold one specific car versus proving it can fulfill its design parameters by handling a constant, unpredictable flow of traffic.

The fundamental flaw in how we think about testing

Let me paint you a picture. You’re building a user activity tracking system (let’s call it Tracky). Your traditional testing approach might look something like this:

test "creates activity with valid data" do
  user = insert(:user)
  sprint = insert(:sprint)
  
  assert {:ok, activity} = Activities.new_activity(
    sprint.id, 
    user.id, 
    ~D[2024-01-15], 
    ~T[02:30:00], 
    "Working on feature X"
  )
  
  assert activity.duration == ~T[02:30:00]
  assert activity.description != nil
end

This test passes. You ship. Then production explodes because:

• Someone enters a duration of 25 hours

• A date falls outside the sprint boundaries

• The description is 500 characters long and breaks your UI

• Someone passes a nil sprint_id

• The timestamp has microseconds that cause floating-point precision issues

Your unit test checked one path through the code. But software doesn’t operate in the controlled environment of your test suite. It operates in the chaos of production, where users do unexpected things, data comes in unexpected formats, and Murphy’s Law reigns supreme.

Instead of testing specific examples, we should be testing universal properties that must always hold true.

Property-based testing builds a foundation for quality by exercising all the behavioral boundaries of your code. This is exactly how we approach development using a “steel thread.” A steel thread creates an architecturally complete foundation by touching all the major components of a system.

The truth about test coverage

Here’s something that might challenge a few of your assumptions: high unit test coverage can actually make your software less reliable.

I’ve seen teams with 98% test coverage ship catastrophic bugs because they confused coverage with correctness. They tested their happy paths thoroughly but ignored the vast space of possible inputs that could break their system.

Property-based testing breaks through this limitation. Instead of measuring how much of your code is exercised, you’re measuring how much of your input space is validated. Instead of asking, “did we test this line of code?” you’re asking, “did we prove this business rule is always true?”

A single property test might only exercise 20% of your codebase but validate behavior across millions of potential inputs — including edge cases. Which approach gives you more confidence in production?

The takeaway here: coverage metrics optimize for the wrong thing. They optimize for testing effort rather than testing effectiveness.

What is a “property?”

A “property” is a universal law or attribute. Gravity is a property that dictates how objects are attracted to each other. Fluid dynamics define a set of properties about how fluids flow and interact. And, our Tracky application has certain properties, too:

1. Activities must fall inside the date boundary of a sprint.

2. An activity is limited in time (for our purposes, it’s a business rule that “activities must be less than 8 hours in duration).

3. Activities must be owned by a user, and that user can view, update, and delete only their own activities (not someone else’s activities).

4. Activities can, optionally, have a description.

Of course there’s more, but this is sufficient for the examples we’ll look at in this article.

These properties define how Tracky behaves; what you are allowed to do with it, and what you are not allowed to do. They are universal laws — in all conditions, an activity must fulfill each of these laws — and, very importantly, the system must gracefully prevent the violation of these laws.

What property-based testing actually does

We’re all familiar with unit testing and testing very specific “success criteria,” like I described above. The problem with that approach is the inherent limitation of testing a single path at a time. It’s an impossible burden to test every edge case using that approach.

Property based testing expands our test horizon. Instead of writing specific test cases, you define properties — universal truths about your system — and let the testing framework try to break them using hundreds or thousands of generated test cases.

In short, you write one generalized test scenario, and the system uses it to create thousands of potential test paths for you.

Let’s start with a simple example.

In this example I use a “generator” to seed my test with test data — if you aren’t familiar with generators, don’t worry, we’ll come back to them. For now, just understand that a generator creates an infinite, essentially random stream of test data. They are the powerhouse behind property based testing.

Let’s start by replacing my naive creates activity with valid data with a property-based test. Here’s how it might look:

property "activities must have reasonable durations and valid dates within sprint bounds" do
  check all sprint <- sprint_generator(),
            user <- user_generator(),
            duration <- valid_activity_duration_generator(),
            date <- member_of(Date.range(sprint.start, sprint.end)),
            description <- lorem_style_phrase_generator_or_empty() do

    result = Activities.new_activity(
      sprint.id,
      user.id,
      date,
      duration,
      description
    )

    # Property 1: Valid inputs should always succeed
    assert {:ok, activity} = result
    
    # Property 2: Output duration should match input duration
    assert activity.duration == duration
    
    # Property 3: Activity date must be within sprint bounds
    assert Date.compare(activity.date, sprint.start_date) != :lt
    assert Date.compare(activity.date, sprint.end_date) != :gt
    
    # Property 4: Description, sprint, and user must all match
    assert activity.description == description
    assert activity.sprint == sprint
    assert activity.user == user
  end
end

I’m using Elixir here, but that doesn’t matter. There are property-based test frameworks available for just about every language.1

At first glance, this might not seem to be much different. I’m still creating activities, and comparing the properties of those created activities with expected values.

But, this single property test does the work of thousands of individual unit tests. It generates valid sprints with random date ranges, creates users with different roles, generates durations up to 8 hours, picks dates within the sprint bounds, and creates descriptions of varying lengths. It does this many times, creating a myriad of combinations and edge cases that we would never think to code up by hand.

This means you’ll see a lot of combinations:

1. An administrator creating an activity with a minute-long duration.

2. Another user creating a 5-hour activity, mid-sprint, with a long description filled with emoji and Unicode characters.

3. Activities with nil, empty, very short, and very long descriptions with a variety of punctuation.

4. Activities that belong to sprints far in the future, or that started (and ended) a month ago.

And on it goes, with many, many combinations of users, sprints, dates, durations and descriptions.

And, it gets more powerful: With property testing we also test the boundaries. What happens when the duration is exactly 8 hours? What about when it’s one second over? What about when the date is exactly on the sprint start date? Or the end date? It’s easy to write negative scenario tests as well, just by introducing a generator that creates bad inputs.

The testing framework explores the entire input space systematically, looking for the edge cases and combinations of edge cases that will break your system in production.

The architecture of unbreakable software

Property-based testing forces you to think architecturally about your code. When you write properties, you’re not thinking about specific scenarios — you’re thinking about the fundamental invariants that must hold true regardless of input.

Thinking in terms of property-based testing makes architecture easier. We’re shifting away from, “let’s make this one specific test case succeed” and toward, “let’s define conditions that prove these fundamental truths are always true, no matter what we throw at it.”

Here are some of those “fundamental truths” property-based testing helps to verify:

1. Data integrity properties.

   1. Entities must always maintain appropriate relationships.

   2. Temporal properties (time and dates) must fall within suitable boundaries.

   3. Access and ownership must be part of the system.

Read more

The most productive teams I’ve worked with never argue about implementation details.

That’s probably surprising if you’ve spent years in rooms with engineers propounding about the merits of different algorithms, frameworks, or architectural patterns. What I’ve learned is that the teams who spend their time arguing about how to build something are the same teams that consistently miss deadlines, accumulate technical debt, and burn out their best people.

The highest-performing teams focus on what they want to achieve, then let declarative systems handle the how.

This isn’t just about programming paradigm or tool selection. It’s a fundamental change in how we think about building software, managing teams, and delivering customer value.

It’s the difference between organizations that scale effortlessly and those that collapse under their own complexity.

The hidden cost of procedural thinking

Most of us were trained to think procedurally. We write step-by-step instructions. “First, do this, then do that, and if this happens, handle it this way.” It feels natural because that’s how we’ve been taught to solve problems since childhood.

But procedural thinking carries a hidden tax on everything we build.

Here’s an example I bet sounds familiar: your team finds themselves inheriting deployment tooling for a complex product. I ran into this recently, to the tune of well over 1,000 lines of disparate scripts, loosely tied together across different systems. It handled environment setup, dependency installation, configuration management, and service startup. The scripts had been lovingly maintained by just one or two engineers for years. And it worked really well — most of the time.

The problem wasn’t that the script failed (it did, in spectacular ways, often completely derailing a new product release). The problem was what that script represented: years of institutional knowledge understood by one or two people, and requiring constant maintenance as the underlying infrastructure evolved (which was pretty often).

After those two people left the company, deployment became a bottleneck. When AWS updated their base images, someone had to trace through the script line by line to figure out what broke. When the team wanted to deploy to a different region, they discovered hardcoded assumptions baked into dozens of conditional statements. Little incompatibilities or unforeseen eventualities that the script just couldn’t handle. Sometimes it took days to reverse engineer a fix.

Here’s my key insight about this: every procedural system you build becomes a maintenance burden that grows exponentially with complexity.

Declarative systems are simple. They describe a clear end-state, not a series of complex instructions that hopefully get you there. Consequently, they become more valuable as they scale.

This is the fundamental difference between telling a system how to do something versus telling it what you want accomplished.

What “declarative” really means

Declarative programming isn’t just about using Infrastructure as Code (“IaC”) instead of writing for-loops and if-then statements (though that’s part of it). It’s about expressing intent rather than implementation.

When I tell Kubernetes “I want three replicas of this service running with these resource constraints,” I’m being declarative. The system figures out how to make that happen, how to recover when nodes fail, how to scale when load increases. I describe the desired state, the “what I want,” not the “how.” The system maintains it, figuring out the “how” for me.

CSS is declarative: “I want this text to be bold, pulsing dark blue on a midnight background.” It describes what I want to appear on my web page. The browser handles the complex rendering pipeline, layout algorithms, and cross-platform compatibility.

But “being declarative” is also about thinking intentionally, a way to reason about systems so they mirror my intention. By “systems,” I don’t mean code, I mean organizational systems. How your team operates. How you design your architecture, your product, your business.

That’s what most people miss: declarative thinking applies far beyond code.

When I create a Definition of Done that specifies the characteristics of completed work, I’m being declarative about quality standards. When I establish value stream maps that define customer outcomes, I’m being declarative about business objectives. When I build a playbook that specifies artifacts and quality gates for each delivery phase, I’m being declarative about process.

The teams that master this distinction operate at a fundamentally different level than their peers.

In using steel threads, I discovered that successful teams naturally gravitate toward declarative approaches. They don’t argue about how to implement the “right to be forgotten” for GDPR compliance — they declare what needs to happen and let the architecture emerge from that constraint.

Those declarations became architectural constraints guiding every decision. Teams stop bikeshedding about microservice boundaries and started building systems that provably meet requirements.

How procedural programming fails at scale

Procedural systems fail for the same reason that manually managing server configurations fail: they don’t account for the complexity explosion from system growth.

Every time you write a procedure, you’re making assumptions about the environment, the inputs, the available resources and the desired outcomes. You rely on expected side effects, assumptions about what’s happening outside the procedure. Those assumptions become technical debt the moment any condition changes.

I’ve seen this pattern repeatedly:

1. In DevOps: you start with simple deployment scripts, but as requirements evolve, scripts grow more complex. Eventually, it’s an unmanageable forest of conditional logic that nobody wants to touch.

2. With code complexity: systems designed procedurally become tightly coupled. When one piece changes, ripple effects cascade. What should be a simple update becomes a multi-team coordination effort.

3. During testing: procedural code demands testing every possible execution path, every external dependency. Side effects cause complications. Teams must choose between inadequate tests or spending too much time maintaining those tests.

4. With knowledge bottlenecks: procedural systems distill complex knowledge into internal implementation detail. When the code author departs so does the knowledge. It takes months to reverse-engineer implicit, complex logic.

The declarative alternative

Declarative systems solve these problems. Instead of encoding how something should happen (which brings with it all the fragility of a procedural approach), you specify what should be true, then rely on the system to maintain those conditions.

There are a few arguments against declarative code that I hear now and then. In my experience these are based on misinformation:

“Declarative code is hard to think about.”

I couldn’t disagree more. Declarative systems are concise, clear, and consolidate all of your logic in a single place. It’s easier to comprehend, and far easier to test. This is really about comfort and changing how we were taught to solve problems — we’re more comfortable thinking procedurally.

“You lose control with declarative approaches.”

You gain control. Instead of controlling implementation details, you control outcomes. When you declare “this service should always have three healthy replicas,” the system ensures that’s true even when nodes fail, traffic spikes, or deployments occur.

“Declarative systems are harder to debug.”

Procedural systems require tracing through execution paths to understand what went wrong. Declarative systems let you compare current state to desired state. The difference between current and desired state is the bug.

When a Kubernetes deployment fails, you don’t debug the container orchestration logic. You check if your declared resources can be satisfied and fix the mismatch.

Remember that deployment script example above? 1,000-line deployment script that sometimes failed spectacularly and required days of diagnosis?

We replaced it with IaC in Terraform, declaring the desired infrastructure state. The declarative specification is just a few hundred lines long. More importantly, we now deploy to any region. We change environment settings with a few variables, not by rewrite procedures. Deployments that previously took days (or, just outright failed) are now done with a click, via a dashboard, and it’s utterly reliable.

I mentioned that declarative thinking applies far beyond code. So how do we “scale up” from declarative code to declarative thinking?

Building declarative teams

The most profound realization is that declarative thinking extends beyond code to how we structure teams and processes.

Traditional project management is procedural: detailed project plans with dependencies, specific task assignments, and rigid timelines. When requirements change (and they always do), the entire plan requires revision.

Declarative project management focuses on outcomes: “We need a user authentication system that handles 100,000 concurrent users with 99.9% uptime.” The team figures out how to deliver that outcome, adapting their approach as they learn more about the problem space.

Goals and emphasis for the team shift away from activities and toward specific, measurable, provable outcomes.

This is exactly what the Delivery Playbook enables. Instead of prescriptive methodologies that tell teams how to work, the playbook declares what good delivery looks like, providing a framework to achieve it reliably.

Here’s a practical framework for moving your team toward declarative thinking:

1. Start with outcomes, not activities. Instead of “implement user authentication,” declare “users can securely access their data from any device.” The first focuses on building something; the second focuses on enabling something. This is the shift away from procedural thinking. It takes time, but with practice you’ll get there.

2. Express constraints, not solutions. Instead of “use microservices with REST APIs,” declare “components must be independently deployable and testable.” Let the architecture emerge from the constraints.

3. Define interfaces, not implementations. Instead of detailed API documentation explaining how to use your service, create OpenAPI specifications that declare what your service provides. Generate the documentation, client APIs, and validation from the specifications and code.

4. Build systems that maintain state. Instead of scripts that perform actions, build systems that ensure conditions remain true. Think about Kubernetes’ declarative nature: “there must always be 3 healthy replicas running.” Use Terraform, Kubernetes and frameworks like Ash Framework.

5. Test behaviors, not code paths. Instead of unit testing internal implementation details, write tests that assert observable behaviors and outcomes. Focus on policies, for instance, “forbid non-administrators from creating a new account.”

6. Use design thinking. Build organization processes that model your declarative “way of working.” Adopt inputs and specific outputs for project phases, relying on statements about target state (not focusing on “what activities everyone should be doing”). The playbook is a great example to use as a model.

7. Only measure progress. Focus on evidence-based delivery. What matters is achieving the declared target state. Progress is measured only by validating that your target state — your feature — is working and deployed.

Deep dive: a declarative security API by contract

I’ve written a lot about declarative thinking in abstract. An example will be helpful to crystalize what it really means. Let’s say we’re building a project tracking system for our agile team. We want to manage sprints and their activities.

One thing we’ll need is a way to track those sprints. Here’s one approach — a fairly traditional, procedural one:

Read more

Be uncompromising about your craft

Steve Jobs was notorious for rejecting products that were nearly complete if they didn't meet his exacting standards. He would send teams back to redesign products multiple times, sometimes scrapping months or years of work.

The iPhone launched without a physical keyboard when BlackBerry dominated with keyboards. Jobs believed in making hard choices about what to leave out, saying “innovation is saying no to 1,000 things.”

He believed that true craftsmanship meant caring about every aspect of a product, not just what was visible.

Caring about your craft matters. It gives you passion. It drives exceptionalism.

Your customers care about what you build, too. They want to be delighted. Delighted customers become evangelists (just like Apple customers and the “cult of Mac”). This is your “value stream.” Understanding what really matters, and sticking to it.

Making compromises won’t lead to delight. Compromise leads to mediocrity.

Instead, be uncompromising. Seek excellence, say “no” to 1,000 things. Choose the best possible path forward — even if it takes longer, even if it’s the harder path.

Have really deep conversations with people that matter

It’s hard to build a shared understanding of a tough problem. But, only in-depth mutual understanding makes learning and joint decision-making possible. It how we discover better paths forward.

Where many teams go wrong is not understanding how important this is. They lose patience, try to explain a technical necessity with hand-wavy jargon, or tell their customer it’s “best practice.”

That creates opaque dependencies where your customer, your boss, your coworkers have no power. The only way forward would be blind trust. It’s just not realistic to believe anyone enjoys those conditions.

Plus, what if they know something you don’t?

No matter how experienced I think I am, I always have enough self-doubt to ask, “wait, am I missing something here?”

Have those deep conversations. Explain the tough problems. See if there’s a better way forward.

It means sharing decision making, because you’re opening yourself up. Admitting that maybe, there’s a better solution. At first it feels like you’re giving up control — but you’re not. You are sharing control by having those important conversations.

Test your assumptions

It’s not always easy to know if we made the right decisions, especially when we casually make assumptions. We make assumptions all the time. This feature will be great. That security policy is good enough.

Fortunately, in software, it’s pretty straight-forward to test those assumptions: establish your key results, and then measure them.

Pick the results you care about. Choose a metric to measure, like number of failures, latency to reply, or anything else that proves your feature does what it’s supposed to do.

Then, measure. That just means test the results. In software, I love Test Driven Development (TDD). I wouldn’t code any other way.

But what if we’re talking about doing what’s right? Cutting through the nonsense and deciding if this or that will leave our planet or our society in a better place, or a worse place?

The same strategy applies. Choose your key results and measure. Check the facts.

Maybe you’ve heard the argument, “we’re in a cooling period, the earth is actually cooler now than any time in 485 million years!” That sounds great. But don’t assume it is. Being cooler now than ever before could be a sign of fragility, a statistical anomaly. Outliers become normalized — plus, if you look closely, you’ll see other patterns. The sudden, rapid uptick in temperature that’s been happening for about 100 years? It happened once before, almost 250 million years ago — just before a mass extinction event that wiped out about 90% of life.

In the real world, don’t blindly accept some numbers you hear, instead check to see if they add up. Measure your results, and see if you were right.

It can be hard though. We’re basically trying to catch ourselves in making a mistake. Nobody likes to make mistakes — but at least this way, you catch it first.

Anticipate mistakes

I assume I’m going to make mistakes.

In fact, I assume I’ll make more mistakes when I feel more comfortable, more knowledgeable about something. Because it’s easy to get lazy.

But I don’t actually make that many mistakes. Why?

Because I’ve put systems in place to protect against them.

Those systems are my secret weapon. My personal edge that makes sure I don’t make mistakes — while sometimes, it seems like everyone else is figuring it out as they go along.

All it takes is stopping yourself from charging blindly ahead:

Read more

Being intentional about your drawings

I’ve seen a lot of technical drawings. I’ve been witness to religious wars about one style over another. I’ve seen engineering teams melt down over which arrow directionality means “input” versus “output.”

It can be a contentious topic — perhaps understandably so.

Adopting one kind of drawing style over another imposes a particular style on our architecture as well. Our drawings influence our architecture. If we use an object oriented notation, we’ll likely design a system based on objects. A style that’s heavily relational, we’ll probably put business logic in the database.

Our drawing style shouldn’t lock us into a predetermined technical approach.

That’s why we need to be really careful about our technical drawings.

I like technical drawings that are unambiguous, easy to read and easy to maintain. The drawings need to be understandable by everyone, including your customer. That’s essential — because the moment part of your team can’t follow along, it’s useless.

What’s more, the right style is going to add value to your project by:

1. Adding fidelity to business processes, in a way that the customer, product owner, and business can validate. It can’t be indecipherable technical jargon.

2. Being compatible with how we model business events, extending ideas about event modeling and contextual boundaries.

3. Extending validation criteria; in other words, it should model the acceptance criteria that proves we delivered the right thing.

4. Working well with all of our engineering requirements (not creating an impedance mismatch as we try to translate into a different domain or technology).

For the past decade or so, I’ve been using two specific types of diagrams. This is all I’ve needed across many domains and many project sizes.

I’ve chosen these two drawing types to meet two specific needs:

1. The first adds functional detail to complex business processes, so we can see exactly how these processes will be implemented and tested.

2. The second makes it easier to reason about complex interaction sequences between disparate components in complex systems.

#1. Architectural marble diagrams

Marble diagrams are a visual way to represent behavior. They align well with event modeling because they model streams of information using a timeline-based format. They use symbols to depict the emission of values, completions, and errors. A marble diagram represents an “observable source” with a timeline and demonstrates how information is transformed and ultimately emitted.

Marble diagrams are event oriented, so they fit well with event streaming architecture. Here’s a quick synopsis of terminology that’s frequently used in marble diagrams:

1. “Observable.” A thing that can be observed to be true or false; basically, something we can validate as correct. An “observable source” is just where an observable thing comes from.

2. “Operation.” Some kind of a process or function that we can apply.

3. “Value” and “event” are, respectively, discrete properties and some concrete thing that has happened and can be recorded.

It sounds a lot like an event driven architecture, making marble diagrams a great way to model a business process. It essentially takes an input, shows how the input changes over time, and what is ultimately output. If you’re following my playbook that formula should sound familiar.

A marble diagram, in a nutshell, looks like this:

Here’s a quick explanation. Each of the numbered post-its in the diagram correspond to the explanation below:

1. A business event from your tactical event map. If your diagraming tool supports it (Miro does), create a bidirectional link — allowing you to navigate between your tactical map and marble diagram with a click.

2. The input to a function is identified with a letter. In this case, the data set “A” is an input to the “4.0 Exploded Event” function.

3. Each function is represented as a sequence of “marbles” along a timeline. Individual marbles represent values, functions or “observables,” and emitted values. An emitted value could be a result, a signal or an error.

4. We can add another layer to explode further complexity — it’s “marbles all the way down.” You can think of each layer like another layer in the call stack. But, not necessarily literally; you model added complexity as you need by increasing depth.

5. Once the input has been transformed to a result, it’s no longer an “A” data type. It becomes a new type, here noted with a “B.” The “B” simply represents a new data set, in this case output from the “4.0 Exploded Event” function.

6. One of the things I love about marble diagrams is the representation of the result in your diagram. The output value, “B,” is your acceptance criteria. It connects your technical drawings directly to the specifications.

As you can see marble diagrams fit very well into an event driven architectural model.

The drawing style is easy to adapt and expand upon. You can add annotations and, of course, other shapes and icons to add specific meanings to your design.

And the value of point number 6 cannot be understated: the representation of your data in your design specifications is powerful. We’ve clearly carried our requirements forward, showing business inputs, how we will transform those inputs and then showing the output. The output, then, is your acceptance criteria — it effectively shows us exactly what we must test to validate our work.

Let’s walk through a real-world example. Here’s a simple event map that I’ve annotated by numbering the events — a better alternative would be to use clickable links, which would make numbering unnecessary:

What we want to do is explode the “4.0 Loan prequalified” event, adding more fidelity to that specific card.

I’ve added some annotations to help explain the example diagram below, along with a legend:

1. The marbles now have two styles. The bold style indicates an event has been emitted, for instance, writing the output value to a Kafka event queue.

2. Notations for logging, blocking function calls and retries have been added.

3. Other shapes are shown in the legend. Marble diagrams are flexible; you should feel free to add annotations whenever it adds clarity to your designs.

This example shows the specific steps performed in prequalification:

Read more

Introduction

I was recently asked, “how do you use a playbook?” The question made me realize that some teams might not have one or even know what it is — or, how it transforms software delivery for the better.

Airline pilots have a playbook. They use their playbook every time they fly. They pull out preflight, taxi, takeoff and landing checklists. They have checklists for malfunctions and emergencies, and more. So do SCUBA divers, which totally makes sense — forgetting to check your emergency regulator means you or your dive partner could die. Sports teams have playbooks so they know exactly what to do on the field and what each other’s responsibilities are. Elite military teams rely on playbooks to execute rapidly and reliably even in highly stressful conditions.

It seems everyone uses playbooks. So, why don’t development teams universally rely on them too?

It might help if I define what I mean by “playbook.”

A playbook is, literally, a “book of plays.” It’s a set of strategies, rules, suggestions and methods for doing something. Think of it as an operational manual that provides step-by-step instructions for how to handle various scenarios.

The term originates from sports, where coaches create playbooks containing strategic formations and tactics for different game situations.

Playbooks rely a lot on checklists. I think it would be fair to say most playbooks are extensively about checklists because checklists make sure we don’t forget something important. That’s what a playbook is, ultimately — a way to make sure we don’t skip the important bits.

A playbook gives us a reference, a way to double check what we’re doing. But it’s more than that.

Sure, a playbook offers guidelines and methods and checklists. Some guardrails so we don’t forget something important. But a playbook is also a complete reference manual. Writing software is hard. At least, writing good software is hard. There are many disciplines, lots of players involved, different strategies and innumerable technical solutions.

A good playbook gives us a single reference for all those complicated parts and processes — a way of keeping ourselves honest about following our “way of working.” A way to make sure we follow all the steps, all the checks we need to guarantee success.

It reminds a pilot to review maintenance logs before each flight, to check the altimeter and static system inspection date, and visually inspect for tipping rivets along the fuselage. They may be rote, boring steps — but they keep the plane in the air.

Why I wrote a playbook

Decades ago I was learning how to be a software engineer. I worked in defense, entertainment, research — lots of different industries. One thing I remember from all of them: being on time and delivering smoothly was rare. Most projects were late, or over budget, or both. Many failed to deliver what the customer actually wanted.

And not once did I find a team that really had their “way of working” nailed.

But every now and then, something went really well. When that happened, I thought, “maybe I should write this down — remember it, and do it again next time.”

I started to notice a few big themes.

Having your customer at the table, involved in every part of the process, usually turned out well. I turned that into a core operating principle — it’s foundational for my own playbook. Other techniques emerged as clear winners. The right kinds of tools for creating a shared, in-depth understanding between the customer and technology team. An approach to design that results in reliable, repeatable outcomes. A way of putting together a project so that you never lose sight of your most important, customer-driven goals.

I learned from other disciplines. I’m a SCUBA diver, and those checklists we use to stay alive are essential. It made me to think about checklists in software delivery.

I bake bread. I love baking bread, and I can make a pretty good loaf off the top of my head — but I still pull out my bread baking reference manual of choice. I check to make sure I’ve got the portions right. I re-read some of the trickier bits, refine my approach, build experiments using those guidelines. Even with years of experience, that cookbook is an invaluable resource I rely on all the time.1

It’s impossible to keep all the facts in my head, all the time. Having a playbook gives me the tools I need to stay consistent, to tackle those tricky problems and to think about new challenges.

I wrote the Customer Obsessed Delivery Playbook because nothing like it exists. It’s become a proven, tried-and-true way to build software. Every single time I use it, my team succeeds. Period.

Playbooks need to be easy & accessible

A playbook is a tool for turning something complex or tricky into something easy. It’s about tackling tough problems, remembering strategies for known situations and discovering solutions when confronted with the unknown.

A good playbook has to support creativity. It can’t constrain the team, because that stifles creativity. Quite the opposite, it has to foster innovation. Software is about research and discovery. Your team needs room to experiment, adopt new and better solutions, and evolve their playbook on the fly.

It’s a framework the team can use, applying it where it makes sense — but not being forced into it when it doesn’t.

It also needs to be easy to adopt. Accessible. One reason I designed my playbook around a subway map is that it’s easy to comprehend. Everyone has ridden a subway.

I’ve seen a lot of complicated diagrams that try to explain how to build software. Many are very good but few provide an overall map — a way of saying “I am here” at any stage of software design and delivery. A subway map makes the Delivery Playbook accessible, easily usable.

Uniformity is also important. Every chapter in the Delivery Playbook — each “subway stop” along the subway map — follows the same design. There are always goals and impact, inputs, activities and then outputs. To move forward, we need the output from the previous subway stop. By following each stop’s process we generate what’s needed at the next stop.

It’s a checklist. Do you have your product capabilities? Does the product owner agree with them? Ok, you can start defining your acceptance criteria.

The subway map organizes all of these individual activities into a whole, a cohesive way to deliver software. Along the journey are clear activities, proposed methods for solving specific problems.

For instance, Chapter 2.3 Strategic event storming captures requirements. We use event storming because it’s very effective when working directly with a customer, and because it gives the whole team plenty of opportunity to participate, ask questions, and build a common understanding.

How to use a playbook

How you use a playbook is simple: you use your playbook every single day.

Depending on who you are, you’ll use it differently. For instance, a brand new joiner will probably use it as an onboarding resource, going through it like a reference manual, learning the ins and outs of how the team builds software.

A more senior engineer might use it as a reminder about the sequence of important steps, or what best practices and tools should be applied in a certain situation. They’ll probably use it to help prepare for some activities too, leveraging the templates, checklists, and examples a good playbook provides.

Your quality engineering lead will use it differently — as a way to check all the quality gates and as a resource to make sure validation and verification is done well.

And even for me — with years of experience using this style of delivery — it’s a tool that saves me time every day. It’s my reference manual when I need to double-check some detail or technique.

I have my subway map printed out in large format and pinned to my wall. It helps me think about what good software delivery looks like. It’s a tool I can use to walk through specific steps with team members.

It helps reason about how we build good software.

For example, I remember an event storming session with one customer. It seemed pretty simple, we were just expanding on a single post-it card labelled “customer checked in.” By the time we finished, half a day later, we had discovered 24 disparate steps that flowed from, “get the passenger details,” including things like security checks, passport photos, prior on-board preferences and more. The playbook gave me everything I needed to prep the team for that exercise:

1. Training material for how to do event storming, including plenty of examples.

2. A “readiness checklist” to make sure the team was prepared; for example, sending background information ahead of time.

3. Activity inputs; a specific list of artifacts we would need for the workshop.

4. A suggested format for the working session itself, with timing and workshopping techniques.

5. Templates so we didn’t waste any time, along with workshop setup suggestions.

6. A step-by-step plan and agenda to run the activity, from start to finish.

7. Specific outputs we needed to produce during the workshop, so we had a clear outcome and specific goal.

Getting started with your playbook

A good playbook should not be proscriptive. Remember, it’s a tool to help your team become more productive — a framework and some guardrails, but it also needs to offer a path compatible with refinement and improvement.

Your team needs to own the process. They’ll be most successful with their own playbook, one that they control and tailor to their own needs.

The Customer Obsessed Delivery Playbook provides a team with a framework. It encourages innovation and is entirely adaptable. It fits within and works with any methodology — agile, waterfall, and others. If you don’t have a playbook, it’s a good place to start. On the other hand, if you have a mature process but lack a playbook, it can be used as a model to tailor your own playbook.

The best advice I can offer is to give it a try. Start by doing. The Delivery Playbook is best learned from example, so put it to use — learn from it, adopt what you like, improve what needs improving.

I know from my own experience: when we use the playbook, we have better outcomes. Our customer is well-informed, we actually do ship zero-defect products, and we accomplish more in less time.

Read the Delivery Playbook

Further reading

You may also find these articles interesting, one on the benefits of a playbook, as well as a “getting started” chapter from the Delivery Playbook itself.

Publication details

Accessing the Delivery Playbook online

Paid subscribers can access the Customer Obsessed Delivery Playbook online, either from this link or by clicking ‘Playbook’ in the menu bar on the Customer Obsessed Engineering home page.

If you’re a free subscriber, you will have access to previews of most chapters, as well as select full chapters as they are released.

Can we get a group discount?

You bet! Group subscriptions are nicely discounted too!

Get 23% off a group subscription

Check out the colophon for more details available to your organization.

If you find Customer Obsessed Engineering and the Delivery Playbook valuable, please share it with your friends and coworkers.

Share Customer Obsessed Engineering

AI is evolving so fast it’s hard to stay on top of all the changes. Just six months ago, so many of the tools we use now didn’t exist or where woefully flawed — nothing in AI is stagnant.

These evolutions have me applying AI more and more. I’ve had Ash AI on my list to research for some time, and finally carved out time to watch Zach Daniel’s introductory video from ElixirConf EU 2025.

But before we talk about AI, let’s talk about simplicity and flexibility.

Simplicity & flexibility

The first bit of Zach Daniel’s introductory video is about simplicity and flexibility, and it’s totally worth watching (even if you aren’t an Elixir and Ash fan) — because it’s not about those specific tools, it’s about how to establish leverage.

Zach’s kickoff is elegant. He says that we often think of simplicity and flexibility as two things on a linear scale, two ends of a spectrum:

Read more

I haven’t hired a tester on any of my teams for at least 15 years. Even so, I insist on zero-defect software in production and won’t settle for anything less.

So, how do I get zero defects if I don’t have any testers?

To better understand this, we need to talk about why I don’t hire testers. In my mind there are really three reasons.

“Downstream” is too late

The first, and the most important, is simply that downstream testing is stupid. Inefficient at least, and useless at worst.

The very nature of a specialized “tester” role is to test software after it’s built.

Let’s think about the mechanics of downstream testing for a moment.

First, requirements and engineering specifications are created. Later, engineers turn those into working code. Somewhere along the line, acceptance criteria have hopefully been created but often this is poorly done. Late in the game, after code has been written, testing finally gets serious attention. It’s too late. The defects are already baked into the product.

What’s more, testing like this is so far removed from the original goal that it’s almost impossible to maintain consistency and relevance. Your value stream is inevitably broken — you end up with flawed software and a team that suffers through multiple break-fix cycles, trying to recapture that lost value.

I have a better way. The defects should be prevented, not removed. We want to engineer quality into the product — not add quality to a flawed product.

Engineers are the best testers

The second problem I have with “bolt-on testing” is who is writing the tests. After decades of observing the difference between downstream testing and engineers building the tests up front — I’ve decided engineers are way better at engineering tests.

Not only have I proven this empirically over dozens of projects and teams, it also adds up from my personal experience.

As an engineer, I’ve got more engineering experience than most testers, which means I can engineer more robust tests. I also understand where my code is likely complicated and where it’s straight-forward. I know what was difficult to implement and what was “off the shelf” and easy.

The fact is, engineers tend to be tougher on themselves than someone else. For every engineer that has really stress-tested and pushed the limits of their own code, I’ve seen half a dozen testers throw together a bare minimum flawed test and call it done.

As an engineer, I take pride in shipping a perfect feature, something that performs flawlessly with no bugs. I think most engineers are like this. I want to harness that self-critical nature by giving engineers the responsibility and the tools to build better.

Juniors shouldn’t be in charge of quality

Product quality is perhaps the most important thing to focus on. I don’t want juniors responsible for the quality of my product. My third problem is, most testers are junior.

There are essentially two career paths leading from tester:

1. Graduate to become an engineer. This is where the numbers are. It’s what I see happen most often. Testing is a relatively easy path into engineering, but it also means that most tester are juniors.

2. Become a senior quality engineer, perhaps with highly specialized skills in healthcare, finance, or safety-critical systems. This is a critical domain specific role, but it’s typically not who you’ll be working with in most downstream testing cases.

While the latter is incredibly important and valuable, it’s also specialized and rare. I find this is especially true in all cases where an organization chooses a downstream testing approach.

Putting the responsibility for engineering quality into a junior’s hands isn’t a great idea. We need to find a way to put that responsibility in the engineer’s hands and, even more important, shift the quality insertion point “left,” earlier in the product lifecycle — in the early engineering stage.

Embracing “shift-left”

If we aren’t going to rely on downstream, specialized testers to enforce product quality, what’s the alternative?

We have to shift the “quality insertion point” left, as early in product development as possible. That means injecting quality before code gets written whenever possible.

I routinely shift 80 or 90% of that effort left and remove nearly all downstream testing.

What remains is intrinsically “downstream.” In other words, it can only happen downstream — for instance, usability testing with real users, accessibility testing, and validation of subjective qualities like user experience. Mostly, these need to happen after there’s a working product to play with (although we can learn a lot from interactive, mocked-up demos — so, again, there’s still room to shift-left).

By intentionally changing where we want to insert quality, how we do it becomes clear.

Getting to zero-defect delivery

The most important mental shift is away from “testing” and into “defect-free coding.” Remember, we don’t want to concentrate on removing defects — we want the code to be free of all defects from the moment it is created. That starts with our acceptance criteria.

Too many teams focus on demos. A demo that shows off a feature is inconsequential without proving it passes its acceptance criteria.

The goal I establish with my team is that code should be proven defect-free before it’s merged into the product.

Acceptance criteria, after all, represent a contract. They define our delivery objectives. It only makes sense we ensure the contract has been fulfilled.

Approaching zero

Attaining zero-defect product delivery is not an overnight journey, but you can get there. Your first step is that mental shift to embed quality early. But there are specific strategies I rely on, which I’ll cover below.

To be clear, “zero-defect delivery” is a goal, a standard. No team is going to be perfectly zero-defect all the time. But, you can be so close to zero that the occasional bug that pop’s up is a rounding error. Your statistical average for defects can be a small enough fraction-of-one that it is “approaching zero.”

This means your typical sprint will be truly defect free. Features will flow without coming back to the team for corrective action. “Incident capture” will start to look a lot more like “feature requests.”

What is Quality Assurance?

Let’s think about what it takes to, “engineer quality into the product, not engineer defects out.”

Read more

McHire is a chatbot recruiting platform for McDonalds. It’s used by about 90% of all McDonald’s franchises. The chatbot, named Olivia and created by Paradox.ai, is used by millions of job applicants to submit personal information, screen personal job preferences, and perform a pre-hire personality test.

And thanks to a shoddy implementation, it also exposed the personal information of over 64 million people.

Maybe it’s not that surprising. Reddit is rife with posts that mock the McHire chatbot for it’s nonsensical responses, an experience that’s surely frustrating for many prospective applicants:

Read more

Introduction

In chapter 2.3 Strategic event storming, we explored how to use event storming to reveal a lot about your product, its features, and what makes a successful delivery. The goal with event storming in that exercise was to model your business events and bring clarity to how different processes interoperate. The focus was on the business and not on technology.

In many regards, tactical event storming is an extension of strategic event storming.

This is were we transition from thinking about what is happening (the business process) and start thinking about how it happens (the technical implementation under the hood).

During this activity the team dives deeper into each bounded context, adding fidelity to your design artifacts. Technology team members drive the conversation but will work closely with the whole team to explore and document that understanding.

Aligning business and technology

Until now, we’ve largely focused our activity around building a very deep understanding of the product. Event storming, business capabilities, context maps and user journeys are some of the tools we’ve used to build this understanding.

As we shift our focus toward technical value it’s important to make sure we don’t lose sight of our original business value — that is, what matters to your customer.

I find that many teams make mistakes here. Those mistakes cost a lot to fix.

Shifting from a business context into a technical one often creates failures in translation. Much like an impedance mismatch in a complex circuit, a shift in focus can likewise cause misunderstanding.

For example, think about old-world monolithic projects where a product team wrote out requirements, then handed them to a separate architecture team for design, who handed their output to developers for specification. Each step introduced compounded risk that the message would be mistranslated.

The inevitable outcome is losing sight of the original value proposition — the desired behavior of a customer feature that was so important in the first place.

That’s why this exercise in tactical event storming very carefully adds fidelity on top of the business value we’ve already described. We’ll literally start by taking those “business facing artifacts,” like event maps, and give them more detail.

Once we’re done, we’ll have added technical specifications to the business events. We’ll weave commands, queries, and aggregates into those events, helping us to see how the underlying logic will be executed. We’ll also make sure that our APIs make sense and align with preconceived notions of business context. And throughout, we’ll still keep involving the whole team to make sure everyone agrees with the evolving design.

This approach preserves our value stream. It creates a direct line of sight back to the original customer driven value — and we’ll keep that line of sight alive throughout the technical design to make sure we don’t drift off-course.

Getting ready for tactical event storming

The activity picks up by adding detail to your strategic event maps. In that regard, it should feel quite familiar.

You’ll be adding detail to the event maps from chapter 2.3 Strategic event storming. You’ll answer questions that inevitably come up regarding those event maps. Having your context maps (from chapter 2.5 Context mapping) and your user journeys (from chapter 1.4 Business capabilities & functions) readily available will help answer those questions.

Read more