Due to covid, my company laid off 25% of their workforce. I was part of the 25%. I learned a lot at that company, but being thrown around from project to project, I rarely had a chance to build a proper foundation for my understanding. I decided to do an agile transformation for my home lab, and decided on a pilot project. That pilot project goal was to investigate the fragility of the current technological workflows that I implemented on a daily basis. I was the stakeholder, product owner, scrumm master, toilet plunger, and everything else. I originally recognized I needed to distribute some of that workload, and got some buy in from a band of merry misfits I call my friends. I'm still product owner, but I have a scrumm master helping me. He'll get a callout if he wants one.

From there I started to look into documentation, and otherwise organizing my thoughts. There were some unanticipated downstream benefits to this optimization, and that makes for an interesting story in its own right. But, part of organizing my thoughts is documentation, and my goal for documentation is to only document what makes sense.

This blurb is to be the sole "business value add" for this project. I am writing this documentation because at some point I may be using this project professionally, and so I felt this would serve as a quick how-to manual for the rest of this. The only information I will add here is information I do not find valuable to document internally, but makes sense for a business case. After all, if you don't plan for it, then it's harder to add it downstream.

Currently, the pipeline can be created by pulling this repo and running docker-compose up -d in the directory you cloned this project into.