Have You Tried: Hack-It Days?
On the product and developer advantages of taking a day to deliver a set of two-hour features and bug fixes.
Yesterday we took a day-off from delivering features, and had a hack-it day. For that day we were free to pick anything to work on anywhere in the application. The only requirement was that each ‘sprint’ could only take a maximum of a couple of hours.
From a product perspective, the aim of the day was to help tackle those thousand paper-cuts that build up in the user’s experience over time. It also gave us time to sand the edges of some of the rougher architectural decisions that get made when you are a small team trying to quickly deliver features.
In the end, the two of us made nine improvements. From squashing front-end bugs to tiny features that put a bit more shine on the finished product.
From a developer perspective it succeeded in two things. It was a dopamine rush to end the week with. There are few things I enjoy more than achieving a completed feature; something which can become days or even weeks apart as scope increases. To be able to take a day and rapidly deliver was good for the soul.
The second advantage was more subtle. It was a day to hone the skill of agility. The point of the two-hour constraint wasn’t to create a pressured environment, it was to make you think hard about what you can achieve, and what you need to do to fix or deliver.
The lesson: Taking a day to rapidly deliver micro-features and bug fixes not only improves your product, but creates a great practice environment for developers to hone their agility.
