Two weeks sprints are terrible, period
There are managers that run their team through 2 weeks sprints. These sprints are just a shaming tool to put pressure on the team that provides little to no value – and might have a negative net impact.
I was never part of a team that used sprints, but I have interacted with quite a few. Here are the issues I observed:
- Sprints create a short term vision/incentive resulting in minor unforeseen issues being ignored as sprints are often super packed. For example teams running sprints tend to accumulate tech debt faster as they don’t have time to properly refactor code/fix small bugs to meet the short deadlines.
- Related to the point above, sprints mean that unplanned requests to the team are often scheduled for the next sprint, adding an additional 2 weeks time to get these issues addressed.
- Sprints create artificial deadlines and unwarranted pressure. Temporary pressure can be occasionally fun but in general sustained pressure over a long period is not healthy and will result in burn out.
- Sprints are a shaming tool – people are called out during reviews/planning when they didn’t complete their tasks in the past 2 weeks.
- Sprints are a form of micromanaging. What’s the point of hiring good engineers if you don’t trust them to do the right thing? I understand how a form of sprint can be useful for new grads but you can make sure junior engineers are not stuck by just talking with them during a weekly 1-1 and having mentors available to them.
I’ve heard a similar and reasonable take about quarterly planning. You should focus on building a roadmap with your projects that may end at different times and OKRs quarterly planning should just be a view of your projects – you shouldn’t have to force your projects to line up with an artificial quarterly boundary.
What’s your experience using sprints or working with other teams relying on sprints?