6 ms·

My previous employer used to plan "express checkout" weeks for developers. In between two larger projects, you'd get the chance to spend two weeks doing nothing

My previous employer used to plan "express checkout" weeks for developers. In between two larger projects, you'd get the chance to spend two weeks doing nothing other than picking low-hanging fruits off the bug-tracker tree. It worked miracles, with minor-but-irritating bugs getting solved much faster, and with features for niche groups getting implemented as opposed to laying in wait for a bigger project it would thematically fit in. Some devs even went out of their way to spend those two weeks on a single, irritating, deeply-rooted bug that nobody in their right mind would even want to fix.

Cthulhu_ 4y ago
This is a great idea and every company should set time aside for it. Not just a "oh we reserve X percent for issues", but a dedicated, "nothing on the todo list" period. I worked at a place once where my favorite time was at the end of the year; most people were off on vacation but they needed a skeleton crew in case of issues. This was when we did tons of small bugfixes, improvements and refactorings, and honestly that's the best part of the job IMO. Screw building features and adding customer value, just let me do janitorial jobs :D
keyle 4y ago
That's a great idea. Sounds like they cared about the product long term.
kioleanu 4y ago
We do that after every sprint and it does work wonders. So 2 or 3 weeks sprint then a week of this, sprint again, a week on the list, which can also be features - we maintain some 40 internal projects and not all projects get (or need) a sprint. I personally like it because the issues are more diverse and I get to pick. For example, my last task was something a colleague complained about in a reporting tool that was also bothering me and I also got to learn something new
Jenk 4y ago
I've been at a few orgs that do this kind of thing and most have found it valuable - but it is a double edged sword that will need to be managed. For the time not specifically allocated to "fixing bugs" or "removing tech debt" or whatever choice of phrasing there is, the rest of the time there is a (misguided) implicit pressure to permit quality to drop to make gains in delivery because "we have time allocated to fix things like this" - so the moral of this post is it is possibly more important to keep encouraging maintenance of quality throughout your team's cycle, and not let maintenance be ring fenced!
- giantg2 4y ago
  Yeah, our "gap sprints" end up just working on stuff we didn't get done in the regular sprints. Really nothing different.
sph 4y ago
That works as long as there's no scoring system, no leaderboard and won't affect your performance review at the end of the year, or you'll just create another version of the Cobra Effect. "The British government, concerned about the number of venomous cobras in Delhi, offered a bounty for every dead cobra. Initially, this was a successful strategy; large numbers of snakes were killed for the reward. Eventually, however, enterprising people began to breed cobras for the income. When the government became aware of this, the reward program was scrapped. When cobra breeders set their now-worthless snakes free, the wild cobra population further increased." https://en.wikipedia.org/wiki/Perverse_incentive https://en.wikipedia.org/wiki/Perverse_incentive
- Heyso 4y ago
  I know the story, but still find myself smiling everytime I read it.
  - howaboutnope 4y ago
    > Hacktoberfest is an October-long celebration to promote contributions to the free and open-source software communities. In 2020, participants were encouraged to submit four or more pull requests to any public free or open-source (FOS) repository, with a free "Hacktoberfest 2020" T-shirt for the first 75,000 participants to do so. The free T-shirts caused thousands of frivolous pull requests on FOS projects. A large volume of pull requests made by users amounted to counterproductive changes to code, including: changing project names from "My Project" to "My Awesome Project"; changing bullet points to dashes; and in some cases, even breaking working code :/
    - lupire 4y ago
      It's a good resume filter though. "Hacktoberfest" => No Hire.
      - htkibar 4y ago
        This is a ridiculous idea; if anything goes on to show how random hiring processes are imho. Check the contributions obviously but why flat out say "you joined a hackathon we don't like your kind here"?
withinboredom 4y ago
I was on a team that did three week sprints separated by a one week “do whatever you want” while the manager and tech lead planned the next three week sprint. I lived for those weeks! It was great for fixing bugs, refactoring for the hell of it, or adding new internal features. I probably learned the most during those one weeks, because someone would inevitably refactor something and we would all learn from the approach. Sometimes we didn’t even commit the new code, but would steal successful patterns for future code. Sometimes, we would “invent” something novel and truly impressive that would open doors to future features that were previously impossible.
- lupire 4y ago
  How awful were your main sprints that were foisted on your without you being involved in the planning?
  - withinboredom 4y ago
    We were involved in the planning, but the tech lead and manager were dealing with the details and priorities from stakeholders. So the last/first couple of days were usually us giving feedback on their plan. But it actually worked out quite well. We were a small team (4-5 of us total), so there was constant communication and no dictation, but someone had to order the cards around and keep things organized.
lifeisstillgood 4y ago
I have a theory that if you did away with the "big projects" and just maintained a clean environment you would find that most of the big projects suddenly become "oh yeah, we could do that with a couple of scripts now" It's amazing what we live with in tech debt and what a clean environment would enable.
hammock 4y ago
Love this idea. How many total weeks of the year be spent in such a way on average?
- once_inc 4y ago
  It varied, but it was often 2 weeks after a 3-6 month project. Not a lot, but enough to really make a dent in backlogs.

Cthulhu_ 4y ago

This is a great idea and every company should set time aside for it. Not just a "oh we reserve X percent for issues", but a dedicated, "nothing on the todo list" period. I worked at a place once where my favorite time was at the end of the year; most people were off on vacation but they needed a skeleton crew in case of issues. This was when we did tons of small bugfixes, improvements and refactorings, and honestly that's the best part of the job IMO. Screw building features and adding customer value, just let me do janitorial jobs :D

keyle 4y ago

That's a great idea. Sounds like they cared about the product long term.

kioleanu 4y ago

We do that after every sprint and it does work wonders. So 2 or 3 weeks sprint then a week of this, sprint again, a week on the list, which can also be features - we maintain some 40 internal projects and not all projects get (or need) a sprint. I personally like it because the issues are more diverse and I get to pick. For example, my last task was something a colleague complained about in a reporting tool that was also bothering me and I also got to learn something new

Jenk 4y ago

I've been at a few orgs that do this kind of thing and most have found it valuable - but it is a double edged sword that will need to be managed. For the time not specifically allocated to "fixing bugs" or "removing tech debt" or whatever choice of phrasing there is, the rest of the time there is a (misguided) implicit pressure to permit quality to drop to make gains in delivery because "we have time allocated to fix things like this" - so the moral of this post is it is possibly more important to keep encouraging maintenance of quality throughout your team's cycle, and not let maintenance be ring fenced!

giantg2 4y ago
Yeah, our "gap sprints" end up just working on stuff we didn't get done in the regular sprints. Really nothing different.

sph 4y ago

That works as long as there's no scoring system, no leaderboard and won't affect your performance review at the end of the year, or you'll just create another version of the Cobra Effect. "The British government, concerned about the number of venomous cobras in Delhi, offered a bounty for every dead cobra. Initially, this was a successful strategy; large numbers of snakes were killed for the reward. Eventually, however, enterprising people began to breed cobras for the income. When the government became aware of this, the reward program was scrapped. When cobra breeders set their now-worthless snakes free, the wild cobra population further increased." https://en.wikipedia.org/wiki/Perverse_incentive https://en.wikipedia.org/wiki/Perverse_incentive

Heyso 4y ago
I know the story, but still find myself smiling everytime I read it.
- howaboutnope 4y ago
  > Hacktoberfest is an October-long celebration to promote contributions to the free and open-source software communities. In 2020, participants were encouraged to submit four or more pull requests to any public free or open-source (FOS) repository, with a free "Hacktoberfest 2020" T-shirt for the first 75,000 participants to do so. The free T-shirts caused thousands of frivolous pull requests on FOS projects. A large volume of pull requests made by users amounted to counterproductive changes to code, including: changing project names from "My Project" to "My Awesome Project"; changing bullet points to dashes; and in some cases, even breaking working code :/
  - lupire 4y ago
    It's a good resume filter though. "Hacktoberfest" => No Hire.
    - htkibar 4y ago
      This is a ridiculous idea; if anything goes on to show how random hiring processes are imho. Check the contributions obviously but why flat out say "you joined a hackathon we don't like your kind here"?

withinboredom 4y ago

I was on a team that did three week sprints separated by a one week “do whatever you want” while the manager and tech lead planned the next three week sprint. I lived for those weeks! It was great for fixing bugs, refactoring for the hell of it, or adding new internal features. I probably learned the most during those one weeks, because someone would inevitably refactor something and we would all learn from the approach. Sometimes we didn’t even commit the new code, but would steal successful patterns for future code. Sometimes, we would “invent” something novel and truly impressive that would open doors to future features that were previously impossible.

lupire 4y ago
How awful were your main sprints that were foisted on your without you being involved in the planning?
- withinboredom 4y ago
  We were involved in the planning, but the tech lead and manager were dealing with the details and priorities from stakeholders. So the last/first couple of days were usually us giving feedback on their plan. But it actually worked out quite well. We were a small team (4-5 of us total), so there was constant communication and no dictation, but someone had to order the cards around and keep things organized.

lifeisstillgood 4y ago

I have a theory that if you did away with the "big projects" and just maintained a clean environment you would find that most of the big projects suddenly become "oh yeah, we could do that with a couple of scripts now" It's amazing what we live with in tech debt and what a clean environment would enable.

hammock 4y ago

Love this idea. How many total weeks of the year be spent in such a way on average?

once_inc 4y ago
It varied, but it was often 2 weeks after a 3-6 month project. Not a lot, but enough to really make a dent in backlogs.