Why I'm not a big fan of Scrum • Hacker News Board

Re: Why I'm not a big fan of Scrum

#301

Post by douche » Mon, Aug 08, 2016, 6:34 PM UTC

mmattax wrote: post #247

I managed a small team of engineers and synchronous daily standups just broke down with remote teams and timezones. It also just felt unproductive - it became something we did to feel like we had "best practices" when in reality it was a waste of everyone's time. I got the sense that everyone would essentially forget what they said/heard at the end of the meeting (or was simply tuned out). I ended up launching a tool…

You don't need to be remote or across timezones for this to happen. I can't help but feel that standups are a huge waste of time. If it is a thing that really needs to be done, why not do it asynchronously in a slack channel when you show up, rather than interrupting everybody and wasting a collective work-day across the team every day in lost flow time, by doing it synchronously at some always-inconvenient time?

Re: Why I'm not a big fan of Scrum

#302

Post by Chris2048 » Mon, Aug 08, 2016, 6:34 PM UTC

cechner wrote: post #241

Chris2048 wrote: post #226

Earlier quoted context omitted.

Assume each person giving different estimates for their own work, but not up front - ongoing as code is written. How is that the same as not being "required to give any estimate at all"? > he doesn't want to have to commit to it why not? an estimate is an estimate, not a commitment. Committing to an estimate makes it a commitment, not an estimate. I might expect a dice roll to be 3.5, I'm not committing to the next r…

it is totally reasonable for stakeholders to want to track your progress through a project. If you have a good way of doing that then great, you should use that. Scrum people believe that scrum is the simplest way of measuring that. But at some stage you have to estimate the constituent parts of the project in order to get an idea of its size, and for those estimates to be useful in tracking your progress you have to…

> for those estimates to be useful in tracking your progress you have to do it in advance

In advance of what? The only constraint on a useful estimate is that is comes before the task is finished - it needn't be considered as credible at the earliest possible time.

Also, your response doesn't really address my post..

Re: Why I'm not a big fan of Scrum

#303

Post by tener » Mon, Aug 08, 2016, 6:35 PM UTC

beerwulf wrote: post #117

tener wrote: post #93

Earlier quoted context omitted.

Not true. If you have design ready before the implementation starts (as you should unless it is very simple) then you are free to implementation things separately. Just have the interface well specified.

Sounds like you've never worked in a shop where they think "agile" == "no need to plan ahead"

This is sad, but my point still holds. Perhaps being honest with oneself about real tasks that need to be done will help. Planning the architecture/feature, doing proof of concept etc. are all valid tasks even if they don't bring immediate business values. If you claim that you can only do business features without doing any exploratory work then you are effectively claiming to have an oracle giving you perfect solutions out of the blue. In which case you should stop whatever you are trying to do and start selling the services of your oracle.

Re: Why I'm not a big fan of Scrum

#304

Post by tener » Mon, Aug 08, 2016, 6:41 PM UTC

matthewmacleod wrote: post #108

tener wrote: post #93

Earlier quoted context omitted.

Not true. If you have design ready before the implementation starts (as you should unless it is very simple) then you are free to implementation things separately. Just have the interface well specified.

Speaking from a UI developer perspective, this never works :) But YMMV, I suppose…

We always do a brainstorming before implementing any serious feature / change. Once we have the initial design business gets involved (if we can get their attention...). The results usually works without needing any drastic changes, which is still better than no planning at all. It does require involvement from a number of parties though.

Re: Why I'm not a big fan of Scrum

#305

Post by tener » Mon, Aug 08, 2016, 6:42 PM UTC

st3v3r wrote: post #289

tener wrote: post #93

Earlier quoted context omitted.

Not true. If you have design ready before the implementation starts (as you should unless it is very simple) then you are free to implementation things separately. Just have the interface well specified.

But if you design things ahead of time, then you're not "agile"!

See my other comment regarding oracle: https://news.ycombinator.com/item?id=12249897

Re: Why I'm not a big fan of Scrum

#306

Post by tener » Mon, Aug 08, 2016, 6:43 PM UTC

lmm wrote: post #122

tener wrote: post #93

Earlier quoted context omitted.

Not true. If you have design ready before the implementation starts (as you should unless it is very simple) then you are free to implementation things separately. Just have the interface well specified.

Design is better when it's informed by implementation, IME. The only complete specification is working code; if you accept something lower-fidelity then it's very easy to miss ambiguities.

Even code have bugs so it's not perfect. Your design can incorporate high level algorithm to be implemented, ins/outs, or whatever else high level constraints are most applicable to your domain.

Re: Why I'm not a big fan of Scrum

#307

Post by douche » Mon, Aug 08, 2016, 6:48 PM UTC

retbull wrote: post #237

I've been noticing more and more that I code around the stories rather than following the best practices from the beginning. When I am adding a DB connection and we don't have liquibase or fliway in place I can't add it because that is a ticket for next week and I need to get it done now. I write code that sucks so that I don't break from my sprint and possibly work on something else first.

I struggle to believe that people follow a management practice that is broken enough that it encourages doing things the wrong way and slavishly adhering to a procedure. Wait, never mind... I just saw my Dilbert day calendar...

Re: Why I'm not a big fan of Scrum

#308

Post by Udik » Mon, Aug 08, 2016, 6:48 PM UTC

gmarx wrote: post #297

Udik wrote: post #265

Earlier quoted context omitted.

This sounds like a bad organization of the team, bad process or bad design. Clearly team members don't communicate enough, or groups of similar features have not been foreseen during the design phase, and the same code has been rewritten again and again by different people. This is not contingent "technical debt", this is a serious problem that needs to be addressed with changes in the process.

organization of the team and process? You mean the scrum process? Indeed, my point. Of course one can argue that no true scrum process would have such problems...

Yes, totally agree with you. But then, why "technical debt"? No, there is something wrong here and this process needs to be changed. Somebody made the wrong decisions, at some level, and there is a very specific issue to be found, analyzed and solved.

And yes of course, as we all know scrum is by definition successful, and all the teams that fail are not following the true faith.

Re: Why I'm not a big fan of Scrum

#309

Post by fsloth » Mon, Aug 08, 2016, 7:04 PM UTC

clifanatic wrote: post #201

maxxxxx wrote: post #146

Earlier quoted context omitted.

True, but don't forget that non-broken organizations are very rare :-)

Do you know of one? I've been looking. For 25 years.

There are several in the Helsinki area (that I'm aware of - that have been at some point at least - sane in this regard. Many broken of course as well).

Re: Why I'm not a big fan of Scrum

#310

Post by DougWebb » Mon, Aug 08, 2016, 7:05 PM UTC

ktRolster wrote: post #290

patothon wrote: post #288

Earlier quoted context omitted.

I guess if you understand what is going on as a manager, then you might prefer the 10 points team? I know I do.

If you understand what is going on, you will get rid of points altogether, and look at the git log from time to time. If you are a leader, and not just a manager, you will help your programmers improve their skill, so over time you spend less and less time managing them. Your programmers will appreciate it because with greater self-management comes greater happiness and job satisfaction.

The points are (also) an estimating mechanism. They let you estimate a new task in points (effort measurement) instead of hours (time measurement), and then use history to predict a likely timeframe based on your typical rate.

The extra layer of indirection helps to account for uncertainties in the task, imprecision in the estimate, and chaos (in the scientific sense) in how long individual tasks take relative to aggregated historical metrics.