InitiativesIdea
Approaches and spikes
An approach is one way to build an initiative, laid out in parts and checked against every requirement. A spike is a short investigation of something nobody knows yet, often what an approach depends on.
More than one way
Section titled “More than one way”Most things can be built more than one way, and what each way costs depends on what nobody has checked yet. So you keep two or more approaches side by side until you choose one. Each sets out its parts, its unknowns and its risks.
The agent writes them when you ask for the ways to build it. Say a customer’s depot managers want an agency driver’s access to end with the shift they approved. One approach puts the shift on the request, and a job takes the access away when the shift ends. The other gives drivers a day pass that lapses at midnight, renewed each morning from a list. The first rests on one unknown: can a depot assignment have an end time?
The fit check
Section titled “The fit check”The fit check sets every requirement against every approach. Pass, Partial, Fail or Not addressed, each with why. A pair nobody has checked yet says so, and doesn’t count against the approach.
You read it one requirement at a time, as a map of which parts of each approach carry that requirement and where one falls short. A line for each pair of approaches says what separates them, and that’s usually what the choice turns on.
- Every requirement. Pick one to put it in focus. Each dot is one approach’s verdict on it.
- The requirement in focus, the core goal, with both verdicts.
- The first approach: Pass, and why.
- A2, the part that ends the access, highlighted.
- The second approach: Partial, and why.
Spikes
Section titled “Spikes”When a verdict waits on something nobody knows, a spike finds it out. It has a goal, what an answer must show, and its questions. The agent opens one when an approach it writes rests on an unknown, and you can open one yourself. We let you open a spike from an initiative’s first day, because some questions come before the requirements.
You start the agent on a question, and can tell it where to look. For each question it picks where to read. That can be your connected documents and tickets, what colleagues worked out in Emargen, your code, or the web for anything outside your organisation. Each answer says how sure it is and cites what it read, so an engineer can check it in minutes instead of redoing the work. For anything about your own product, it’s told not to rely on the web alone.
In a support case about requests stuck after an approver’s role change, a spike asked why two old tickets were never solved and when the product hears of a role change. It read the tickets, the support topic, the sign-in provider’s documentation and the code.
- The first question.
- How sure the agent is of its answer.
- What it read for it: two documents from the connected tools, and the support topic.
- Two files in the code, with the lines it read.
- The provider’s own page, from the web, with the day it was read.
Once the answers meet what the spike asked for, the agent marks the unknown answered and any risk it covered mitigated. Then it rechecks the verdicts that waited on it. When only a person can answer, it isn’t a spike. The agent asks them instead.
Choosing
Section titled “Choosing”Once you’ve compared the approaches and the spikes are answered, you choose one, with a reason written for someone who wasn’t there. The approach keeps your reason, and the agent works out what it changes in your code, the decomposition.
A choice can change later. Until the initiative is approved, you choose again, and a new decomposition follows on its own. After that, it takes a change request.