Governance of Workflows

Why agile fails, and how category theory can help

Author
Affiliation

Dr Charles T. Gray, Datapunk

Good Enough Data & Systems Lab

Published

March 31, 2025

Pitfalls of getting tool locked

No matter how advanced the tooling is, mathematicians solve conceptual problems at the blackboard. Why?

  • It forces minimal representation of the problem.
  • Tools don’t constrain the solution.

Once the concept is clear, then we instantiate it in tools that serve that structure.

The problem with agile

Agile workflows and tools like JIRA often miss the mark and drift into tech theatre. Developers have pretty great ways to break tasks down to computationally isolated tasks, but the way of piecing them back together is doomed to fail because too often there is an assumption the project plan will remain stable.

However, development is highly chaotic; unexpected blockers as well as new solutions appear.

Think of agile like this. 

Leadership: Mirror, mirror on  the  wall, 
  who has the FAIRest vision of them all?

Product managers smash the mirror into pieces.

Developers smash those pieces into shards.

Different developers paint the shards in 
  tiny ways to make the vision FAIR.

Developers reassemble shards into pieces.

Product managers reassemble those pieces 
  into the mirror painted to leadership's vision.

Leadership: Mirror, mirror on the wall, forget FAIR, 
  I can't see my fucking face at all.

Without governance of the workflows, epistemic drift becomes inevitable (draft).

Kanbans are for working, not reporting

Sadly, I’ve seen far too many managers attempt to govern from the workflow level, without any consideration of the core priorities. This locks the team in a myopic dystopia: always working toward short-term goals, yet never achieving anything of substance.

This is where systems of human intelligence governance, such as Getting Things Done (Allen 2015) provide models of structured intelligence governance. Just as GTD promotes an annual review, technology workflows benefit from first assessing core priorities conceptually – before turning to tools.

core cluster_domain cluster_domain_core Core domains adulting Adulting wellness Wellness create Create pandan Project planning pandan->adulting defines tasks pandan->wellness defines tasks pandan->create defines tasks study Study pandan->study defines tasks study->adulting supports career study->create supports domain_node Domain

Figure 1: In my current system, I divide life into three core domains: wellness (health, relaxation), adulting (work, household), and create (math, code). Study is a supporting domain to work and create.

Governance of core domains

A critical failing in tech management is sufficient reporting to both leadership and developers. In my experience, managers set a vague goal and do little else but ask when it will get done, e.g., an epic with only the title filled in, “KPIs - due december”.

Too often this middle layer

  • fail to correct the epistemic drift of development chaos by intervening in key blockers
  • and also misrespresent to leadership the status of the project.

In their defense, I don’t believe there are good enough tools for them to do this yet, and I aim to contribute to mitigating that. We need better methodologies to ask how well our governing mechanisms (Figure 4) serve our core domains (Figure 1).

governance cluster_governance cluster_governance_jira JIRA dashboards cluster_governance_review Review cluster_governance_forest Forest pomodoro app daily Day achievements weekly Week achievements monthly Month achievements proj Project progress inf Repeating tasks drev Daily review drev->daily supports wrev Weekly review wrev->weekly supports wrev->monthly supports wrev->proj supports wrev->inf supports forest Forest summaries forest->daily supports forest->weekly supports forest->monthly supports forest->proj supports forest->inf supports governance_node Governance

Figure 2: Governance need not be tool locked under a category-theoretic framework. With math, we can ask if the combination of governance tools faithfully report the core domains.

Far less defensible, however, is the norm I’ve seen from middle management: blame and dispose of developers when their vague fantasies about AI and machine learning fail to eventuate. Unfortunately, discrimination and exploitation of developers is the solution that is usually chosen by middle management.

Developers are not to blame for management lacking tools of governance, yet developers are the ones who bear responsibility.

Workflows should not be tool locked

Ways of working are critical to governance, otherwise developers will revert to what feels safe and comfortable but without the context managers have from leadership. Developers need workflows that facilitate deep work (Newport 2016) where they focus on a single task.

Task management tools are great, but often try too hard to be all the things. Better to go to the blackboard and inspect the combination of workflows, from stand up, to kanbans, or whatever.

workflows cluster_ritual cluster_ritual_jira JIRA cluster_ritual_forest Forest pomodoro app cluster_ritual_cards Index cards associated with pomodoros and kanbans cluster_ritual_cycle Shuffle stack cluster_ritual_decom Shuffle stack cluster_cards_inst Ordered stack music Put music on shower shower music->shower temporal dress dress shower->dress temporal coffee coffee water Lemon water coffee->water temporal pan_crit Critical project planning water->pan_crit temporal dress->coffee temporal inst_node Instantiate day inst_node->music Card stack cycle_node Deep focus inst_node->cycle_node temporal cycle_adulting Adulting cycle_create Create cycle_due Due cycle_joy Joy cycle_plan Plan cycle_housework Housework cycle_wellness Wellness cycle_critical Criticalæ cycle_dis Minddump cycle_node->cycle_node repeat decom_node Decommission day cycle_node->decom_node temporal decom_critical Critical deom_associate Associate minddump decom_due Due decom_wellness Meditation fortimes Forest timer fortimes->inst_node Timer exists fortimes->cycle_node Timer exists fortimes->decom_node Timer exists kanban Kanban kanban->inst_node Represents tasks kanban->cycle_node Represents tasks kanban->decom_node Represents tasks ritual_node Workflow

Figure 3: Workflows aren’t just a kanban or stand-up, but a combination of interlocking practices, what we might call a way of working. For myself, I use index cards that are tied to pomodoros and kanbans for each node in the workflow digraph.

Category theory lets us ask:

Do our workflows serve our priorities, or merely reinforce our tools?

With a diagrammatic model, we can answer that question formally.

Category theory is the mathematics of structure and transformation. Here, it becomes a language for reasoning about tasks, tools, and goals.

lifeswork cluster_ritual cluster_ritual_forest Forest pomodoro app cluster_ritual_cards Index cards associated with pomodoros and kanbans cluster_cards_inst Ordered stack cluster_ritual_cycle Shuffle stack cluster_ritual_decom Shuffle stack cluster_ritual_jira JIRA cluster_domain cluster_domain_core Core domains cluster_governance cluster_governance_jira JIRA dashboards cluster_governance_review Review cluster_governance_forest Forest pomodoro app music Put music on shower shower music->shower temporal dress dress shower->dress temporal coffee coffee water Lemon water coffee->water temporal pan_crit Critical project planning water->pan_crit temporal dress->coffee temporal inst_node Instantiate day inst_node->music Card stack cycle_node Deep focus inst_node->cycle_node temporal cycle_adulting Adulting cycle_create Create cycle_due Due cycle_joy Joy cycle_plan Plan cycle_housework Housework cycle_wellness Wellness cycle_critical Criticalæ cycle_dis Minddump cycle_node->cycle_node repeat decom_node Decommission day cycle_node->decom_node temporal decom_critical Critical deom_associate Associate minddump decom_due Due decom_wellness Meditation fortimes Forest timer fortimes->inst_node Timer exists fortimes->cycle_node Timer exists fortimes->decom_node Timer exists kanban Kanban kanban->inst_node Represents tasks kanban->cycle_node Represents tasks kanban->decom_node Represents tasks ritual_node Workflow domain_node Domain ritual_node->domain_node serve task focus governance_node Governance ritual_node->governance_node partial timers captured adulting Adulting wellness Wellness create Create pandan Project planning pandan->adulting defines tasks pandan->wellness defines tasks pandan->create defines tasks study Study pandan->study defines tasks study->adulting supports career study->create supports domain_node->governance_node tasks summarised informatively daily Day achievements weekly Week achievements monthly Month achievements proj Project progress inf Repeating tasks drev Daily review drev->daily supports wrev Weekly review wrev->weekly supports wrev->monthly supports wrev->proj supports wrev->inf supports forest Forest summaries forest->daily supports forest->weekly supports forest->monthly supports forest->proj supports forest->inf supports

Figure 4: Category-theoretic frameworks allow us to govern how well workflows serve our core domains.

References

Allen, David. 2015. Getting Things Done: The Art of Stress-Free Productivity. Penguin.
Newport, Cal. 2016. Deep Work: Rules for Focused Success in a Distracted World. Hachette UK.