The approach
How we deliver
Why work breaks between handoffs, and the five jobs that keep it whole.
On this page
Most software projects that go wrong do not go wrong inside a step. The code works, the ticket is closed, the release goes out. What goes wrong is the move from one step to the next: the reason behind a request does not make it into the ticket, the ticket does not say what "done" means, the developer never sees the conversation where the client changed their mind. Each handoff loses a little, and what is lost comes back later as rework.
This page describes how AiM Infosoft delivers software with that in mind, and where each part of the approach lives in Jarvis.
Where work breaks
There are four handoffs on every project, and each one has a typical leak.
| Handoff | What tends to get lost | How Jarvis holds on to it |
|---|---|---|
| Client to project | Why the work exists | The project carries a written goal, notes and specs, and every ticket inherits them. |
| Brief to ticket | What "done" means | Tickets link to an outcome and carry acceptance criteria: what the client signs off and what the reviewer checks. |
| Ticket to code | What was said since the ticket was written | Agents read the brief, the criteria, the comment thread, the attachments and the notes. See What an agent reads. |
| People to agents | Judgement | Agents propose and people approve. Agent work always stops at the approval gate, and an agent asks instead of guessing when something is missing. |
Agents make the last handoff more frequent, not less important. An agent will do exactly what the ticket says, quickly and confidently. If the ticket is missing the reason, the agent is missing it too.
Five jobs every delivery needs
Delivery needs five jobs done. When nobody owns one of them, that is usually where the rework starts.
| Job | The question it answers | Its home in Jarvis |
|---|---|---|
| Define | What are we building, and what must stay true while we build it? | Clients, projects, the project goal, notes and specs |
| Plan | What pieces is it made of, and in what order? | Outcomes, tickets, sprints, the board, the workflow, assigning agents |
| Steer | Is the work still heading where we meant it to go? | The live run screen, review comments, permission requests, the approval decision |
| Fund | Is the effort going where the value is? | The usage and cost report, daily worklogs, proposal estimates |
| Ship | Has the client received it in a form they can use? | Pull request descriptions, deploys, client updates, timesheet reports |
Jobs, not job titles
These are jobs, not roles. On a small project one person covers all five. On a larger one, a delivery lead might Define and Plan, a senior engineer Steers, an account manager Funds, and the lead engineer Ships. An agent can help with part of a job, such as drafting criteria or proposing a change, but it never owns a decision.
What matters is that each job has an owner, and that the owner knows it. A project where everyone assumes someone else is checking cost, or someone else is reading the changes, is a project with a gap in it.
The flow
The approach runs in one direction, and each step leans on the one before it.
- Goal. Write the end state this phase works toward, in terms someone could check.
- Notes. Record the context, constraints, guidance and decisions that should shape every piece of work.
- Outcomes. Break the goal into lasting capabilities, and check each against six quality tests before marking it Ready.
- Tickets. Break each outcome into small pieces of work, each with acceptance criteria.
- Agent work. Assign an agent. It works on its own branch, reading everything above.
- The gate. A person reads the change, the screenshot and the agent's report, and decides.
- Pull request and deploy. Only approved work goes on to a pull request and a deploy.
You do not have to perfect every step before moving on. A project with a goal and two notes is already far better grounded than one with neither. But each step you skip is context the agent and the reviewer will not have.
The same thinking at every scale
The five jobs apply to one ticket, to a whole project, and to every client AiM Infosoft works with. What changes is the question you ask.
| Scale | The question | Where you check it |
|---|---|---|
| One ticket | Is this done, by its own criteria? | The acceptance criteria, shown again on the approval screen |
| One project | Are the outcomes delivered, and is the goal now true? | The Outcomes tab, with progress per outcome from its linked tickets |
| Every client | Is the effort going where the value is? | Usage and cost by project and agent, daily worklogs, and timesheet reports for each client |
A reviewer at the gate asks the first question. A delivery lead looking at the Outcomes tab asks the second. Whoever looks after the account asks the third. Each is doing the same kind of check, against a different piece of writing.
Where to start
If you are setting up a new project, follow Getting started, then read Goals and notes and Outcomes and quality checks before writing tickets.
If you are joining a project that is already running, read its goal, its notes and its outcomes first. They will tell you more about what the tickets are for than the tickets themselves.
Something missing or unclear? Tell us.