Conclusion

Shipping into the future

Self-awareness, self-realisation, self-actualisation

This was a really nice experiment for me, and I'd love to hear feedback.

I'd also like to get involved with the API behind it if I can think of neat ways to use it (but I suspect some of my more out there ideas will be scuppered by the limitations on inter-repo CI triggers).

To me the kanban evokes the psychological notion of self-realisation and causally, productively links it to self-actualisation (the top rung of Maslow's hierarchy of needs). When used at work in a business, you're actualising business value, and when used for your personal goals you're just actualising yourself:

"the possibilities of one's character or personality"

The kanban seems like a mundane tool but this connection to one's inner life makes it powerful.

Daydreaming of webhook integrations

When I first heard of Projects, I was working with a kanban that synced via a Dropbox-hosted config file.

I encountered them a few years later and had a vision of creating GitHub issues from a markdown note in real time, as you wrote it

Daydreaming of automating the creation of GitHub issues (with the automated project kanban integration which I’ve just discovered) from a to-do list on file, while manually re-typing it...

It's worth emphasising here that back then there was only the board view. With the introduction of the 'table' view GitHub have quietly shipped a new UI abstraction: at face value it's a table readout, but I'd suggest it's actually more like my daydream.

If you start a new 'table' layout Project, you effectively have a text file in which each line is a TODO item.

While this requires some manual work to 'elevate' the default draft items to issues, the kanban is entirely usable in this draft form.

I could imagine workflows where you create items on a Project via webhooks, and would enjoy experimenting with these as the team behind them is soliciting feedback and demos.

I came across a workflow example used to sync GitHub wikis and repos, and had a sneaking suspicion that there might be some potential crossover potential with the Projects webhook, so that editing a markdown in a GitHub wiki would sync with a repo, and from there update a Project, but it's still only a vague suspicion.

This daydream reminded me of a recent podcast with Charity Majors which told an anecdote of working at GitHub alongside Kent Beck (then at Facebook)

exploring something which was every time you press a key on your keyboard, I want it released to production.

And the theoretical thought exercise was like, you know, what kind of systems would you need to build to go do that?

And we just, we were talking for hours because I love to talk at the extremes because I think extremes reveal a lot of the thinking and can help you, like, clarify some things. So one extreme is you don't release ever or maybe once a year or what kind of baroque systems are you gonna have at that point?

But then, if you theoretically, every key stroke is a release to production, what kind of systems, what kind of things do you, do you need to build? Now, that was fascinating because of the safeties involved with that and, like, what you would end up doing. But the liberties you would get out of a system like that too, if it was in place. Oh my goodness.

Impact

The immediate impact of this was noticeable: I had been waiting for a panacea (pyx-sys, a workspace manager I was writing) to be powerful enough to house all of (what I now recognise to be) my "large batch" WIP, rather than enforcing small batch WIP (or single-piece flow, 1 WIP at a time).

Having the personal kanban allowed me to take an objective look at the situation and effectively file away the 'background' WIP (which I'd just been leaving open indefinitely).

Following this intervention I no longer have any 'background' WIP and am obeying the proper lean style in my workspace, which is far less chaotic and liable to loss.

Treating the practical knowledge of "what you are up to" as WIP state in the Agile/Lean way makes it analogous to software (where the software is practical knowledge).

If the goal of lean thinking about software is to ship software faster, and an iteration is called deployment, then in a broader defined project like "personal development", an iteration on a task is deployment, so "shipping" means "achieving the tasks that you find fulfilling".

Faster deploys equates to faster self-actualisation, small batch deployment equates to clearer separation between your tasks (less 'backgrounding'), and reducing lead time equates to "doing what you say you're going to do faster".

This latter point is a pattern that I've wanted to enhance for a while: specifically to change the wishful speculation of "I'd like to do X" into actually doing X (even if only incrementally). This seems to be exactly what this sort of setup facilitates.


This post is part of Supporting and structuring personal development and open source contributions with GitHub Projects, a series covering how I began using the GitHub Projects tool for tracking my personal development and shipping outside of work. I hope you've found this series helpful and are inspired to use GitHub Projects to support your own development goals!