Jay's Journal #100days


Always watching, always learning.


#100Days, Day 4

It seems that whenever I stumble onto something 'new', it's not really all that new. Which means that more times than not, I'm late to the party of the whatever I discover to be cool. Sometimes months late, but sometimes, decades late.

Some examples include, but aren't limited to:

  • Linux
  • Minimalism
  • Stoicism
  • Outsourcing
  • Rockabilly (fashion and music)
  • Intermittent Fasting
  • Internet Privacy and Security
  • Inbox Zero
  • Dynamic websites while sticking to MS Front Page, then using dynamic websites like Wordpress and Joomla, now static sites again using static site generators Anything I haven't discovered yet, or I did know about but didn't take the time to learn about it then love it and embrace it yet, until many years later

So, the latest 'discovery' of mine is using Agile and Scrum methodologies for my daily non-development work. I started using it this past week, along with some free tools that enable this, and am pleased with the results so far.

To be clear, I'm not a coder or a developer. In fact, I've been an infrastructure systems guy for pretty much all of my career. Typically non-coders and infrastructure types that install hardware, OS, and software applications and services follow a "waterfall" methodology.

Waterfall is typically a series of workflows that begin and end within a certain timeline, with the next workflow set to begin after the current one in progress is complete.

It's very linear, and each worflow or tasks needed to complete a milestone needs to be completed before a new one can begin. Therefore, if a workflow that is waiting to start because the current workflow is behind schedule, the delayed workflow calls the delayed workflow a "dependency".

Workflows won't flow very smoothly while dependencies exist. And, usually when one workflow on the waterfall is delayed, the delayed workflow and the other downstream workflows dependent on the delayed workflow will either also be delayed, or the project team will need to work additional hours to make up for the delay.

So, when one workflow is delayed, the usual result is the project itself will either be delayed or late. Both of which cost the organization or client money.

In addition to all that, managers and directors rarely want to wait for one workstream to complete before starting another. So, now you've got multiple workstreams working in parallel, with the same team members working on all active streams. This creates chaos, and even more delays, in addition to requiring more time to provide the reporting that explains the progress and delays of multiple workstreams all being worked by the same few team members.

But again, that's the only way I knew how to approach projects.

A few years ago, I led a team that was upgrading an implementation of an open source cloud platform. They were a bunch of Linux geeks who were developers and coders. And the Linux geeks as well as the stakeholders and managers of the project were all using Agile methodology.

At the time, this seemed very much at odds with everything I knew with a lifetime of waterfall experience. But, for the sake of the project, I quickly choked down the Agile workflow and reporting and made everyone happy.

And, as soon as I was done with that project, I said to myself that since I'm neither a coder or a developer, I'll probably never need this Agile stuff again. I was pretty relieved to be rid of such an abomination in my life.

Fast forward about five years, and reference the bullet points above, and here I am, embracing Agile and Scrum methodologies for my non-developer day to day duties, and so far loving it.

I bet you're wondering what changed. Well, it started with my recent frustrations with Outlook and OneNote at work. I've been using MS Office pretty much forever, but with my current workload and all the things I need to remember, action, ask others to action, and remember who I asked to what and when it needs to be done by, along with my own deadlines, these tools just weren't working for me.

To be fair, Outlook and OneNote do have amazing reminder and calendaring capabilities. I can create tasks in either application, and set reminders. I can use Outlook Tasks and keep detailed information on all the things I need to track, and even document the status, note updates, and track time spent on a task.

With OneNote, I can create a note, or a table, or even a spreadsheet, and flag any text for follow up or assign a due date. With OneNote, there's no end to the things I can annotate, clip, save, and store.

The thing is, Outlook is too structured, and OneNote isn't structured at all. And so the more I'd try to capture for tracking, the messier my life was becoming. On top of all that, my manager likes to have ad-hoc phone calls to discuss my progress on projects.

Needless to say, ad-hoc sync up calls leave me scrambling for the answers I get asked and wasn't able to prepare for ahead of time. As I've got stuff scattered between Outlook and OneNote tracking everything, I found that I'm not able to answer unexpected questions on just about anything regarding my projects.

Not being able to find status and data from my tracking sources, I've had to rely on memory a hell of a lot more. That's more work than I think should be necessary, so I went to find a better way.

I remembered reading sometime somewhere that Git as in GitHub and GitLab can be used for more than just coding and software projects. Plus, I'd started using both GitHub and GitLab for a side project I'm working on outside of work.

Everything came together... I needed a better way, I remember reading about a creative way to use coding tools for non-coding work, and I'd just started using those tools and found them pretty useful, for what I know about them now. I thought maybe if I learned how to leverage these Git services better, I'd get more out of it.

With that hunch, I spent last week setting up my Git "projects" for work. I can keep any project I want as private, and both GitHub and GitLab use two-factor authentication, so I feel even better about keeping my notes and tasks private.

After I set up my work projects, I took everything I was tracking from Outlook and OneNote and started using the "Issues" management features. These issues management tools with GitHub or GitLab allow me to track the task, keep narrative notes with timestamps for each task, and I can add labels to each task to let me know which project or workstream a specific task is attached to.

Updates are tracked as an ongoing narrative, along with status changes. And, I get a Kanban board with either service, allowing me to move different tasks to their appropriate status stack.

Now, at a glance, I can see what tasks I'm tracking, who's responsible, the current status, and any updates regarding that task, and the timeline associated with those updates.

To add to all that, I can see it all in a central location. If I wanted to, I could also upload any documents, attachments, or work product to each task, or to a central repository for later reference or usage. And, it's all stored in the cloud.

OMG, this was what I needed. Now, here's the icing on the cake. I can assign due dates to each task, but also create milestones for the project and associate specific tasks to a specific milestone.

The result? I know the progress and due date of each task, and how that impacts the due date of the milestone, which allows me to better track the entire project pretty much at a glance.

Because these Git services can use Markdown text files and track changes and even revert changes, this becomes a perfect project management and respotory tool for my writing business.

When I start using it that way, I can have multiple people working on the same document at the same time. Like, me and my client for example.

I can create a draft of my work for my client to review. My client can make comments on what should be changed, or even change text themselves, and it's all tracked separately from the soon to be finished version.

We can continue to refine and revise the document, implement only the recommended changes that make sense, and leaving out the ones that don't. That would merge all the accepted changes into the final finished document. Then, my client can either download the finished product in Markdown, or I can download it and convert it for my client in any format they want, like Word or PDF, fully formatted.

There's many more features that I haven't touched on, like free static website web hosting on either Git service, as well as desktop editors like Standard Notes that you can push (upload) your documentation changes to.

I'm definitely going to dive in even more and see how I can further leverage these free services to continue to improve my organization, my workflow, and my effienciency.

This was a long one, but this is yet another discovery that's got me geeking out yet again.


You'll only receive email when Jay's Journal #100days publishes a new post

More from Jay's Journal #100days: