Ask several business units how they do the "same" thing and you get several different answers: different steps, different names, different definitions of the same words. Getting them onto one process model is one of the most foundational things a transformation does, and it is a negotiation disguised as a diagramming exercise.
Delivery Craft, How Transformations Get Built

Reconciling Many Business Units Into One Process Model

Reconciling Many Business Units Into One Process Model Ask several business units how they do the "same" thing and you get several different answers: different steps, different names, different definitions of the same words. Getting them onto one process model is one of the most foundational things a transformation does, and it is a negotiation disguised as a diagramming exercise. In any enterprise made of multiple business units, the same activity: selling, quoting, onboarding a customer...
Continue reading
When an enterprise’s systems are fragmented, the reflex is to replace them all with one. That is the slowest, most expensive, and most politically explosive path there is. The overlay pattern is the pragmatic alternative enterprises rarely write up: add the missing capability as a thin layer above the systems you already have, and leave them running.
Data & Architecture

The Overlay Pattern: Adding Capability Without Ripping Out the CRM

The Overlay Pattern: Adding Capability Without Ripping Out the CRM When an enterprise's systems are fragmented, the reflex is to replace them all with one. That is the slowest, most expensive, and most politically explosive path there is. The overlay pattern is the pragmatic alternative enterprises rarely write up: add the missing capability as a thin layer above the systems you already have, and leave them running. An enterprise wakes up to the cost of fragmentation: many separate systems...
Continue reading
A prototype is the best tool there is for discovering what people need — and the worst possible way to record it. The step almost everyone skips is turning what the prototype revealed back into traceable requirements. Do it, and the prototype's learning survives; skip it, and you ship the mock-up's accidents as if they were the plan.
Delivery Craft

Reverse-Engineering Requirements From a Prototype

A prototype is the best tool there is for discovering what people need — and the worst possible way to record it. The step almost everyone skips is turning what the prototype revealed back into traceable requirements. Do it, and the prototype's learning survives; skip it, and you ship the mock-up's accidents as if they were the plan. An earlier piece in this series argued that prototyping has become the primary way to gather requirements, because people reveal what they need when they react t...
Continue reading
Most backlogs cannot answer the two questions that matter most: why does this item exist, and if the business need behind it changes, what do we have to rebuild? A traceability chain answers both.
Delivery Craft

The Traceability Chain: From Interview to User Story Without a Broken Link

Most backlogs cannot answer the two questions that matter most: why does this item exist, and if the business need behind it changes, what do we have to rebuild? A traceability chain answers both. Pick any story in a large product backlog and ask the team a simple question: why does this exist? In most organizations the honest answer is a shrug, or a name — "someone asked for it," "it came out of a workshop," "it's been in there since the last planning cycle." The provenance is gone. The item...
Continue reading