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’ve probably heard of two methodologies; agile and waterfall development. If you haven’t here is a quick run down:
AgileAn agile approach is 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 being 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.
WaterfallAgile’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 the Waterfall method. They’re often large goals with a set roadmap and are likely unable to adopt to changing needs and circumstances.
Building software and pursuing your resolutions are quite similar in that roadblocks and unexpected issues 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. Notice that the user story creates a framework for me to achieve my goal. The cycle is also 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 not even concerned about reaching my resolution, I am just 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,