Taking an Agile Approach to New Year’s Resolutions

Written by NateAndorsky | Published 2017/01/09
Tech Story Tags: agile | software-development | startup

TLDRvia the TL;DR App

Ah, yes! New Year’s Resolutions- everyone has them and most of us (including myself) often fail to keep them. This year I am trying out a new approach and so far, so good.

If you’ve ever been involved in a software development process you may be familiar with two methodologies; agile and waterfall development. If you haven’t here is a quick run down:

Agile

A methodology where work is confined to regular, repeatable work cycles, often known as sprints or iterations. These sprints are short and often times defined by a number of user stories consisting of 3 main parts; a role, objective and a reason for the objective. For example:

As a user I want to be able to edit my profile so that I can update my personal contact information

The beauty of agile is it allows for short incremental milestones, constant feedback loops and iteration. Build a part of an app, evaluate feedback and then plan the next sprint based on the feedback received.

Waterfall

Agile’s arch nemesis is called Waterfall Development. It looks a bit like this:

Plan the entire application, build and then release it. This is great if you know exactly what you want to build but often times you don’t. Waterfall allows no room for feedback and tweaks along the way.

Typically New Year’s Resolutions are akin to large development projects built using Waterfall. They’re often large goals with a set roadmap and unable to adopt to changing needs.

Building software and pursuing your resolutions are quite similar in that roadblocks and unexpected issue always come up along the way.

Whether it be new requests (other personal priorities), bugs (issues you didn’t foresee) and changes in requirements (your goals may change) you need a flexible approach. Agile allows this — the ability to evaluate progress as you move towards your goals leveraging short iterative cycles and making adjustments along the way.

I have broken my New Year’s Resolutions into 3 month sprints outlining overall project goals, then specific sprints for each project and finally user stories to fit into those sprints. At the end of the cycle I’ll evaluate my progress and plan out my next sprint accordingly.

New Year’s Resolution/Project: Produce a weekly post on Medium.

Sprint 1- Writing: Jan 1 — March 31st 2017

In order to achieve this I need to devote more time to writing. Instead of my user story addressing the end goal, it addresses what I need to do in order to achieve that goal.

User Story: As an entrepreneur I want to be able to wake up at 6 am everyday so that I can devote more time to writing.

Notice there is a specific task and a reason for that task. In addition the user story creates a framework for me to achieve my goal. The cycle is short enough where it keeps me focused. I can see the next 3 months, it is harder to envision a year from now.

In fact, at this point I am even not concerned about reaching my resolution, I am focused on the current sprint. Once I complete the sprint I’ll evaluate its effectiveness. Is it still worth pursing? Is the system working for me? Should I remove/add something to make it more effective?

I’ll report back in 3 months and let you know how I did.

Until next time,

Nate

Thanks for reading. If you liked this piece, please help me out by clicking the below_. You can follow me on_ Twitter and check out my company, Creative Science Labs.


Published by HackerNoon on 2017/01/09