3 ms·
I like this approach, and have found it useful. One other trick I used, is to have a “tech debt week” at the end of every quarter. 12 weeks of coding per month
by theptip 4y ago
I like this approach, and have found it useful.
One other trick I used, is to have a “tech debt week” at the end of every quarter. 12 weeks of coding per month, then a week for the managers/PMs to evaluate the last Q, and plan the next one. At the same time, while there is this awkward 1wk window where the plan is in flux, the engineering teams can focus on polishing their tools and attacking tech debt that might take more than a day every sprint to make progress on.
Of course, this planning window is probably too short a window for big companies, and too much planning overhead for one-team startups. But for 20-30 person engineering org this cadence worked well.
- kevsim 4y agoThis is somewhat similar to the Shape Up methodology from Basecamp [0] where there's a 2 week "cool down" at the end of every development cycle. So 6 weeks of feature development, followed by 2 weeks of bug fixing, refactoring, etc. I've never done it in practice so I don't know how well it really works and there are some other parts of Shape Up that I disagree with strongly. 0: https://basecamp.com/shapeup https://basecamp.com/shapeup
- theptip 4y agoIf you can afford that level of slack, I think you will build a very happy, long-term-focused org. Worth noting that they build and open-source frameworks like Rails, Hotwire; if you want to polish and share, you need extra bandwidth vs. just building internal-facing products.
- theptip 4y ago^ should of course be “12 weeks of coding per Q”