No more status meetings to find out what is done
Tresmeta with all its capabilities, plus the ontologies and skills of a development team: it checks task status daily against your own code.
What it solves
In a development team, the question of what is finished gets answered in a meeting, and answered from memory. Someone says it is done, someone says almost, and the board tells a version of reality that resembles the one from three days ago.
The true answer is not on the board or in the meeting: it is in the code. What has been written, what has been merged and what is still open is objective data that already exists and that nobody consults to update the plan.
What it does
- Everything Tresmeta does, with the ontologies and skills of a software development project
- Analyses local or GitHub-hosted repositories daily, weekly or per sprint
- Checks the board's tasks against the real code and marks which are complete and which are not
- Spots work done that nobody logged, and logged tasks nobody has started
- Keeps the link between what was agreed with the client and what the team has actually built
- Turns the status meeting into a review of exceptions rather than a walk through the whole list
Our part in it
The tuning here is more specific still. A development team's vocabulary has its own structure — issues, branches, releases, acceptance criteria, technical debt — and the relationship between a business task and the changes in the code is rarely one to one.
Our work is to refine those ontologies and skills until the system gets it right about what is done, without inventing correspondences that do not exist. And above all, so that when it is unsure it says so instead of accepting a guess.
The point is not to watch anyone. It is to stop the team's conversation being spent working out the status, and start it being spent deciding what to do about it.
Got a process that hurts?
Tell us about it in half an hour. No forty-page deck. If we are not the right people, we will say so and point you towards someone who is.