<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>akudha</author><text>The problem with any system is that people try to enforce it, military style. In my previous job, we did scrum, but not too strict. We had two week cycles, not-too-strict deadlines (most of the time) etc. If I finished my task early, I was free to pick up tasks from the planned list, without having to get permission from my manager. We also didn&amp;#x27;t agonize over story points, retrospective etc. We did it light hearted and quick. The only thing we religiously followed was daily, quick 15 min stand-ups. Everything else was flexible.&lt;p&gt;My current job is the opposite. Some tasks take 15 minutes of discussion (no, they aren&amp;#x27;t complex tasks) with people debating whether it is worth 5 points or 8. It is just tiring and pointless. And retro - gawd, I hate those. There are all kinds of stupid shit (people using references from music, movies etc, trying to make it &amp;quot;fun&amp;quot; and &amp;quot;hip&amp;quot;). I can&amp;#x27;t bring other tasks into the sprint, even if I finished all my current tasks, without my manager&amp;#x27;s permission. And on and on.&lt;p&gt;I was thinking the other day why this is so painful and awkward. I realized that it all comes down to &amp;quot;metrics&amp;quot; - end of every sprint, my manager has to present it to his bosses, with pretty graphs describing &amp;quot;velocity&amp;quot; and other buzzwords. So he has to do all kinds of jugglery to appear competent to his bosses and not alienate the team at the same time.&lt;p&gt;All of this could be avoided by treating the team as adults, instead of trying to &amp;quot;processify&amp;quot; or quantify everything.&lt;p&gt;However hard we try, human beings can&amp;#x27;t be slotted neatly into buckets nor can they be precisely quantified. However hard we try, estimating software projects will never be an exact science.</text><parent_chain><item><author>lordnacho</author><text>The thing about Scrum is the observations and principles make sense, but then to sell it as a course they&amp;#x27;ve turned it into very specific prescriptions.&lt;p&gt;I went on a scrum course and the takeaway was basically that feedback is a big deal, and you should try to get some repeatedly and quickly. It&amp;#x27;s also common sense that you should have tasks written down somewhere, and that some of them are more important than others.&lt;p&gt;You certainly need to think about how long tasks will take, but there&amp;#x27;s no reason why you need to do planning poker, that just seems to be one among many ways to think about how long something might take. Tracking velocity is another one of these things that seems replaceable.&lt;p&gt;If you have a team of people that more or less adheres to a few principles, there&amp;#x27;s no reason you can&amp;#x27;t get things done.</text></item></parent_chain></comment><story><title>How big tech runs tech projects and the curious absence of Scrum</title><url>https://newsletter.pragmaticengineer.com/p/project-management-in-tech</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>bennysomething</author><text>It also fits very well with feature factory shops: a story fits nicely into a single feature. God help you when you are trying to build a system from scratch with scrum overhead. Not everything is a story or a ticket. It&amp;#x27;s painful.</text><parent_chain><item><author>lordnacho</author><text>The thing about Scrum is the observations and principles make sense, but then to sell it as a course they&amp;#x27;ve turned it into very specific prescriptions.&lt;p&gt;I went on a scrum course and the takeaway was basically that feedback is a big deal, and you should try to get some repeatedly and quickly. It&amp;#x27;s also common sense that you should have tasks written down somewhere, and that some of them are more important than others.&lt;p&gt;You certainly need to think about how long tasks will take, but there&amp;#x27;s no reason why you need to do planning poker, that just seems to be one among many ways to think about how long something might take. Tracking velocity is another one of these things that seems replaceable.&lt;p&gt;If you have a team of people that more or less adheres to a few principles, there&amp;#x27;s no reason you can&amp;#x27;t get things done.</text></item></parent_chain></comment><story><title>How big tech runs tech projects and the curious absence of Scrum</title><url>https://newsletter.pragmaticengineer.com/p/project-management-in-tech</url></story>