I Removed Task Estimates, Sprints, Planning, and Retrospectives — and Nothing Broke
A team lead shares his experiment of managing a team without traditional Scrum tools — no estimates, no sprints, no daily standups — and achieving nearly 100% of goals through OKRs and motivated team members.
Introduction
This article examines the author's experiment with managing a team without traditional Scrum tools. He demonstrates that "most managers will be left without jobs, and the rest will only find life easier" when abandoning these practices.
The Author's Practical Experience
When the author took over a new UI Kit team at his previous company, he was allowed to work without standard metrics and estimates. Instead, the team:
- Set OKRs (goals for 4-month periods)
- Held weekly comparisons against the plan
- Conducted dailies only 3 times per week
- Worked on major projects without interruptions for meetings
Result: goals were achieved at nearly 100%.
Key Conditions for Success
- A highly motivated team, assembled independently
- A manager who required only the final result, not intermediate reports
Where Scrum Attributes Come From
The author identifies three main sources:
- Legacy: practices already existing in large companies
- New leaders: specialists bringing processes from other organizations without analyzing their necessity
- Pressure from above: managers implement tools to create an "illusion of control" and reporting
Managers Need to Survive
At intermediate management levels, managers "create a system of control illusion." Team charts show the obvious — for example, that the team does less when a senior developer is absent. Many implement Scrum "for the achievement badge, bonus, promotion, or praise from the founder."
Story Points Create an Illusion
"You'll never guess the deadlines anyway," says the author. Complex dependencies, lengthy reviews, and unexpected problems aren't accounted for in estimates. The only value is discussing tasks before development, which "can be done without estimation too."
Alternative: naming a random number of days would be more effective than planning poker.
Sprints Slow Teams Down
The paradox: if a task is given a 2-week deadline, it will be completed in exactly 2 weeks. Without a deadline, the team will spend the actual time needed — 3, 5, or 8 days.
The author references the book "Jedi Techniques" by Dorofeev: "If a task has a deadline, it will always be completed on the last day of that deadline."
Dailies Create Psychological Pressure
Daily standups create a "psychological torture" where a developer fears taking on complex tasks. A person prefers to close a small item in a couple of hours so they have something to report at tomorrow's daily.
The author's platform team had a weekly "weekly" meeting — this allowed them to immerse themselves in complex multi-day tasks without stress.
The Solution: Critical Thinking
Any proposal to add a process should trigger the question: Why?
"— Let's estimate in story points!
— Why?
— To give predictable deadlines
— How exactly will this help guess deadlines?
— ..."
For new meetings: you need to make sure they are truly necessary.
The Key Idea
"If a person is motivated to do something, if they know why and for whom, they will dive headfirst into the task and deliver an outstanding result. If you box a person in with frameworks, hang metrics and processes on them, they will deliver exactly the result expected of them — no more, no less."
