Hacker News Reader

Comment by macco | Hacker News Reader

The article mentions Plan->Iterate->Ship a lot.

How is this essentially different from Scrum sprints?

1. Scrum sprints have all sorts of goofy restrictions, that you don't need to waste time on with a true-agile process. You don't need to plan out exactly two weeks. You don't need to worry about having too much or too little work in the sprint.

2. Scrum requires you to break things down pointlessly, when really most teams can execute on higher level goals.

3. Teams do not need to meet for a standup every day.

4. Effort estimates can be extremely approximate and wrong, but scrum tries to force you to spend way too much time on them.

The "plan" in a non-scrum environment is much better at focusing on what matters, rather than ticking all the scrum boxes.

You can do anything badly. Like point one, no you don't need to plan out exactly two weeks. You estimate what you want to get done in two weeks and then at the end you see how close you got.

It's supposed to be a reality check to see how well estimates are matching up to actual effort. Which I don't really see why you shouldn't do something like that.

Our pointing sessions sometimes last 1.5 hours and involve the whole team regardless of expertise. Just imagine how much money we are wasting to determine: is this story a 1 point or 2 point story.

Goes back to the original point. If you do something badly then it's no surprise the results are suboptimal.

Yeah but if we do it well I still have to sit through a 1.5 hour retro. My therapy sessions are shorter.

I'd say 95% of sprint ceremonies I'm in are a complete waste of time. Still, amen for WFH.

Again, goes back to the point of you can do anything poorly. Ours are 30-60 minutes and usually have good conversations about issues the team sees. More often than not meaningful change comes out of it.

You're having 60 minutes of issues every few weeks? And you think something isn't done poorly? That's way too long.

The only meaningful change I ever saw come out of a "retro" was making daily standups async twice a week (done over Slack.) Then the manager didn't like that, so it was rolled back.

Most of the retros I'd just roll my eyes at. "What can we do differently?" cancel the retros...

Haha. Tell them we can't do anything differently because that would mess up the meticulous Jira/Agile flow we've setup in other meetings and have affirmed in retros.

Pretty sure I said 30-60 minutes. We also don't just talk about issues. We talk about wins and things that go well too.

I'm pretty sure 60 is within 30-60.

> We talk about wins and things that go well too.

It's a tactic for managers to feel better about themselves. Look, the team is expressing gratitude! I'm a success as a manager! If you want to thank someone message them on Slack. We don't need a 30 (or 60) minute meeting for an enforced feel good moment.

>I'm pretty sure 60 is within 30-60.

Uh hu, but since I gave a range obviously we don't have 60 minutes of issues every week. If I meant that, I would have said we have 60 minutes of issues every week instead of giving a range for the meeting length.

>It's a tactic for managers to feel better about themselves. Look, the team is expressing gratitude! I'm a success as a manager! If you want to thank someone message them on Slack. We don't need a 30 (or 60) minute meeting for an enforced feel good moment.

You're projecting so hard here.

(1) We didn't have a manager for a couple months now and retros went on unchanged.

(2) Talking about wins isn't an enforced feel good moment. It's about identifying things that worked well so that the team can continue doing them.

Your position is extreme and not everyone feels the same as you.

I am giving my experience and you call it projecting? That’s an interesting debate tactic.

The team doesn’t constantly need to reinforce what is working. That is self-evident and could be an email or slack message.

I’m done with this thread.

>I am giving my experience and you call it projecting? That’s an interesting debate tactic.

Taking your experience and making definitive statements is the definition of projection.

>The team doesn’t constantly need to reinforce what is working. That is self-evident and could be an email or slack message.

So you say. Obviously other people disagree

Plan -> iterate -> Ship is different than scrum. One big difference is that its not usually time boxed into sprints. Another is that there may be multiple independent projects being worked on on one team. So you might have a team with project A being in the final touches, while an engineer leads on the plan phase for project B, as another person might be leading C in Iterate.

Can't even find a blogpost where this is explained. Anyone got any links please?

* What form does planning take?

* Does someone from the business side approve the UX before it's implemented, etc.?

* Is progress not tracked at all or only informally?

* Are people actually treated like adults to ask for help to unblock things instead of needing 8 people on a call so one person can say they're having an issue and need one other person's help?

Planning is what makes sense for the project scope, and can easily be recursive through orgs and teams. Each layer works out the core components needed, then which teams would be needed for those components. Those teams then work out what sub components are most effectively done by which teams, and repeat recursively. Teams may find overlap for components and assign subsets from multiple teams to work together to plan for those overlapping areas. This would seem like the obvious way to plan for anything.

Why would business side have significant input into UX - that’s the whole reason you have hired UI and HI teams?

An effective bug tracker has the concept of related and blocking bugs, along with priorities, etc. Anyone can see how progress is happening in trackers. Occasional meetings between ICs or PMs can identify where things are falling behind or getting blocked, and either work to reprioritise or re-resource as appropriate.

I my experience that has never been significant impedance between ICs and managerial types communicating directly. This feeds into ICs being able to decide what to work on - if another IC comes to you needing help or needing some particular bug fixed earlier than expected you can always in crease the priority or provide short term work around, etc - or talk to other ICs in your team to see if someone else has capacity to get it fixed earlier.

To me this all seems like the sensible way to get software done at large scale. As I’ve said elsewhere maybe it’s different at small or young companies, but the share interminable “process” of scrum, “agile”, etc seems asinine.

Thanks

There is no Scrum Master but Tech Leads. The former in their degenerated but sadly all too common enterprise form know primarily process, shy away from deeper knowledge and focus on enforcing the former. Shipping becomes the side effect of process. It is safer that way as process can always be controlled the challenges of shipping a deliverable not - at least for the scrum master.

Reply on news.ycombinator.com