How we work
We work where you can watch.
Every task, bug and decision on your project lives in Azure DevOps, and you have a seat at the board. Finding out what happened this week does not require a meeting. It requires a browser.
This page says what that seat includes, item by item, and names the one thing it does not include. We would rather draw that line ourselves than have you find it.
The default
Most software firms manage their clients by summary.
The work happens on Monday. The status report is written on Thursday. You learn what went wrong three days after it went wrong, in a summary composed by the person whose work is being judged.
That is not malice. A summary is the cheapest thing to produce and the easiest thing to consume, and most of the industry settles on it for exactly that reason. But a summary is a narrative, a narrative has an author, and the author decides what you learn. On a good week that costs you nothing. On a bad week it costs you the three days between the problem and the report.
The unit of truth
If it is not on the board, it did not happen.
We do not run on summaries. We run on work items. Every change we make traces to one. Every pull request links to one. The commit message names it. Nothing lands in the codebase without one. The board is not a picture of the work, drawn afterward for your benefit. The board is the work.
That discipline sounds bureaucratic until you see what it buys. A closed work item carries the whole record: who asked for it, what we estimated, what we discussed, which commits implement it, which pipeline run deployed it, and when. Six months later, the question of why the system behaves the way it does has an answer with a date on it.
Here is the life of one change, exactly as you would see it:
- Filed. Every change starts as a work item: a bug, a task, a feature. It gets a number and a place on the board, visible to you from the moment it exists.
- Estimated. We put a number on the effort before we start, where you can see it. The estimate stays on the item, next to what actually happened.
- Built on a branch. The code is written on its own branch, named for the item, so work in progress never touches the main line.
- Reviewed. A pull request links the branch back to the item. The review happens in comments on the pull request, on the record, not in a chat thread that evaporates.
- Merged by pipeline. The merge runs through the build and the tests. If they fail, it does not land. There are no exceptions for deadlines.
- Deployed. The same pipeline carries the change to the environment. The run has a number and a result, and both are kept.
- Closed. The item closes with a link to the deploy that shipped it. Filed to shipped is one unbroken chain, and every link in it is a page you can open.
Your seat, precisely
What you can see, exactly.
Your seat is an Azure DevOps Stakeholder license. Microsoft grants it at no charge, and it covers boards, backlogs, dashboards, work items and pipeline runs. It does not open private source repositories. Anyone who promises you can see everything is promising past the license. Here is our list, with the boundary on it.
Every task, bug and feature we file, with its state, its estimate and its history. The whole backlog, not a curated slice of it.
What is committed this sprint, what is in progress, what is blocked, and what got pushed. The same board we plan against, not a copy prepared for visitors.
Every state change and every comment, recorded by the system at the moment it happened. Memory does not get a vote.
Which changes are in review, what the review said, and what merged. The argument about the code happens where you can read it. Reading the diff itself requires repository access, which is the last row in this table.
Every build and every deployment, pass or fail, kept on record. If a deploy failed on Tuesday, the record says it failed on Tuesday.
The Stakeholder license stops at the repository door. That is Microsoft's licensing boundary, not a wall we built, and we would rather tell you than have you find out. Read access to source is arranged per engagement, when you want it. And when an engagement ends in a handover, the code is yours regardless. Owning it is the point.
What it buys you
You can audit us.
Our estimates sit next to our actuals, permanently. When we are wrong about how long something takes, you can see by how much. You can read the bug we filed against ourselves before you ever felt the problem it describes. You can watch a task sit blocked and ask why on the day it blocks, not at the monthly review. A firm that only shows you the wins is showing you a narrative. We show you the ledger.
This is not free for us. Working in the open means our mistakes are legible, our misjudged estimates are on record, and a slow week looks like exactly what it is. We do it anyway. The alternative is asking you to trust our summaries, and this whole page is an argument against trusting anyone's summaries, including ours. We think that is the correct trade.
The demonstration
This website is the proof.
The page you are reading came out of the process it describes. This site's source, its board and its deployment pipeline live in the same Azure DevOps organization we use for client work, in a project called Coding Innovations. Changes to it travel the same road: filed, branched, reviewed, merged by pipeline, deployed. There is one process, and you are reading its output.
The first work item on your project is a paragraph about what is broken. Send it.