Building

No working code yet

Purpose

Prolly is a project management system mainly intended for software projects, but also applicable to any projects that need to worry about deadlines.

The emphasis is on mathematically correct estimation of the probability of completing a dynamic set of goals by certain deadlines.

Data Model

The tool's data model consists of a tree of "goals" (e.g. customer inquiries, user stories, coding tasks) and tree of "parties" (e.g. companies, teams, coders, PMs) with a relation called "owner" between 0-N of the former and 1 of the latter.

Most properties of a goal can only be edited by its owner.

The roots of both trees are fixed and represent the universe. All users of this system exist in the same data space, but of course they can't see all of it.

The history of the whole data model is stored so that it's possible to mine data from periods when the structure of both trees was different. In the future, team structure and leader status might be much more dynamic than today. Goal structure is extremely dynamic due to changing requirements and technical options.

A goal has an "arrangement" pertaining to its subgoals which specifies that they either must be implemented serially, or may be implemented in parallel, or that any one of them suffices alone. Extra levels of the goal tree may be used to make more complicated arrangements.

A goal or party may have multiple parents. This is useful when a coding task contributes to and blocks multiple higher-level goals, or when a coder takes part in multiple teams.

A goal is created by its first owner with a description of what needs to be achieved. Later, the owner may mark the goal as achieved. Ownership of a goal may be transfered from one party to another with the consent of both, but this is rare because it's usually better to create a subgoal owned by the second party.

Using a messaging system, the owner may seek another party to act as contractor, but "contractor" is not a property of goals, rather, the contractor would create a subgoal describing what they intend to achieve, thus becoming the owner of the subgoal. The owner of the main goal examines the subgoal and may mark it as "contracted" meaning that they agree that the subgoal contributes in some way to the main goal. If later the owner of the contracted subgoal marks it as "achieved", the owner of the main goal is alerted and may mark the subgoal as "signed off" with respect to the main goal (as opposed to any other parents). The proceedings of the messaging system are stored in connection with the main goal and subgoal. Parties may create subgoals of their own goals thus becoming their own contractors.

There are various styles of software development management possible under this system. In a medium-sized company developing bespoke software for various customers, a customer would create a goal for an inquiry and approach the supplier about it over the messaging system. If they're talking to multiple suppliers they'll make each inquiry a subgoal of some parent using the any-one-will-do arrangement. A PM at the supplier will create a subgoal to claim the case which should have the cultural effect of telling other PMs not to bother. Then they'll create subgoals of their subgoal for different aspects of the work, some of which they'll undertake personally and some of which they'll seek internal contractors for. These would often be user story goals offered to teams. The team leader is authorised to act as the team within the system.

There is now likely to be a "delegation" meeting similar to scrum's ticket refinement. The team might reject the user story goal and suggest a different team, haggle about its scope, or recommend that it not be pursued at all. In the latter case, the owner may mark the goal as abandoned to de-clutter their screen. Alternatively, if the team agrees to help pursue the user story, they'll either take ownership or create a "story coding" sub-goal. The former is unlikely because the team are likely to create multiple "coding task" subgoals which could be shared among coders. The team wants to present a complete solution to the PM, not bother them as each coding task is completed, and the team will want to check that the coding tasks have indeed added up to a solution. For this reason, the team will want one "story coding" subgoal of the user story comprising multiple coding task goals to be achieved one by one, and they'll only mark the story coding goal as achieved when the whole thing works. The story coding goal is alerted on completion of each coding task and likely to prompt a peer review, and the alert about the last of the tasks being achieved should look a bit more upbeat than the earlier ones to remind the team to mark the story-coding goal as achieved.

The output of this delegation meeting is that each coding goal has been analysed technically, knows its story points and the "modules" (areas of codebase where changes are expected) and has an owner who will implement it and arranges it in an expected ordering among their other goals.

Estimation: short term

The delegation meeting should output some details about the coding tasks. The assignee is, of course, the owner of the coding task. Assignees should arrange tasks to indicate the order in which they intend to implement them. They may also set the proportion of their time demanded by the goal below 100%; this is rare for coders but common for PMs. Complexity should be estimated in arbitrary "points". When transitioning from scrum, teams should use the story points they are used to to help with data mining of the legacy bug tracker. Furthermore, the affected "modules" should be estimated, i.e., the directories within the codebase where the changes are likely to be made. Points and modules may also be estimated for higher level tasks, and it's not an absolute requirement that they be populated in any goals, even coding tasks. However, this data is helpful for predicting implementation durations and each company can police the population of these fields as it sees fit.

Given that all the coding goals with any likelihood of being worked on before the next release have the properties of points, owner and modules defined, and also given that we have a corpus of historical goals in either this system or a traditional scrum management system like jira, we can calculate the expectation value and variance of the time required to implement each goal.

To make use of the modules field, we can mine the source control for the owner's "familiarity" in the modules, i.e., the amount of work they've ever or recently done there. We'd then mine for the influence of familiarity on implementation time. Coders also have an innate "speed" that can be separated from their familiarity with particular modules. Modules have a "spaghetti" factor that slows down all coders, but especially unfamiliar ones.

It's wise to separate the influence of speed, spaghetti, familiarity and points on the expectation value and variance of implementation time. It might seem tempting to mine for coefficients for each tuple of the product type of intervals in all four values, but this would lead to a model with thousands of coefficients and thus risk finding a fit to the historical data by sheer luck. Hoeffding's inequality teaches us to restrict the number of coefficients to about a tenth of the number of training samples.

It's not obvious how to define the implementation time of goals, but the definition should have the virtue that the simplistic mathematical statements that follow are approximately true. One approach is to associate each unit of one coder's time with exactly one goal. The source control, as well as the historical ticket database, can provide clues about the implementation time.

If we've prepared an expectation value and variance of implementation time for each goal, and if we know the order in which each coder will implement their goals, we can calculate the expectation value and variance of the total implementation time of any sequence of goals that a given coder intends to work consecutively. We simply add the expecatation values, and add the variances.

If we've prepared an expectation value and variance of implementation time for each sequence of goals starting from the current one of each coder, and we know how far through their current goal each coder is, and if we know what day it is, we can calculate the probability of any goal being implemented by a given release date in the not-too-distant future. Progress through the current task should be written down automatically rather than expecting the coder to tediously prod a progress bar along every day, but the coder should update the points when complications arise.

If we've calculated the probability of each coding task being achieved by a release date, and we've treated the delay between the last subtask being achieved and the parent goal being achieved by either neglecting it or capturing it as a "demo" or "testing" goal, then we have the probability of higher level goals like customer-comprehensible user stories being achieved by that release date.

If we can do that, and we allow a PM to select a set of the goals that a customer will be promised in the next release, then we can calculate the probability of the release shipping that full scope by multiplying the probabilities of each owner getting through all of their leaf-level tasks that are direct or indirect descendents of any of the promised goals. Careful attention to the independence of probabilities is required here.

It's recommended that the PM work with the customer in making this selection. When transitioning from a more traditional relationship, the supplier should agree to anything but draw the customer's attention to the probability of the release succeeding in full scope.

This same engine should be made available to the teams for use in delegation meetings. It's especially useful for advising how long alternative coders are likely to need for a goal in a given set of modules. To support estimation, the company will ask teams to populate coders' in-trays a couple of releases in advance, and they can only know whether or not they've done so if they have this calculator to estimate the duration of the sequence of tasks already assigned to a coder.

Estimation: longer term

TBC

Skills management

There's a strong tendency for modules to end up with only one coder understanding them. This is especially likely under deadline pressure because the opposition of overspecialisation creates delays due to both the unfamiliarity of the coder being indoctrinated and the expert having to provide assistance.

When one person becomes the monopolist of knowhow about multiple modules, there's a risk that both modules need maintaining simultaneously. There's also a risk that a monopolist is assigned to other tasks for many months and forgets how the module works, leaving nobody.

Companies must oppose overspecialisation, but due to the cost of doing so, they must be very targetted about this.

Because Prolly already has a concept of familiarity, it is the ideal basis for this effort.

Dynamic teams

TBC