Live data from Hacker News

Scrum is fragile, not Agile

dennisweyland.net

261–270 of 329 posts

Re: Scrum is fragile, not Agile

#261
post #40

Earlier quoted context omitted.

It's similar at my office. We also use it to let the rest of the team know on occasions when you're blocked on something.

Why wait until a meeting to air that you are blocked, just sort it out when you become blocked. Where is the agility?

This is a very important point that's often forgotten. You shouldn't wait for the appropriate meeting, but address it right away. The next stand up meeting is more of a backstop. It's the time to admit: "I guess I really am stuck here. Can anyone else look at this?"

Smoothly running teams don't need this, but many teams don't run that smoothly, and then it's better to address it at the stand up than not at all.

Re: Scrum is fragile, not Agile

#262
post #67

Earlier quoted context omitted.

The biggest problem with Scrum is it lacks any sort of design phase. You do the minimum. Oh, it doesn't work quite right? We'll fix it in the next sprint... The "spiral" model is closer to a true iterated waterfall. I've seen it used successfully in more mature companies.

It's like "build one to throw away", in that the goal is to rapidly explore the feature space and discover useful features, but what actually happens is that it's a trap and you won't throw away something that works no matter how poorly implemented.

absolutely. If you ever see a group afraid to produce a prototype, it's because they're afraid management will try to ship it as a final product.

The effective strategy is to build an oblique, fatally limited prototype, which can not possibly be mistaken for a shippable product. The bad prototype can only be used to test the hardest parts of an idea and must have major holes in it with no way of filling them. It should also have a largely fixed timeline to ensure it is put to bed before it gets "hamstered" into the shipping product.

Re: Scrum is fragile, not Agile

#263
post #112

Earlier quoted context omitted.

Why wait until a meeting to air that you are blocked, just sort it out when you become blocked. Where is the agility?

Generally if things can get unblocked as you go, that's better, and so this isn't particularly common. But sometimes you need your manager to go kick down a door for you and it's a handy time to let him know. Sometimes it's more benign and it's just easier to ask the group in person when everyone's together sipping their coffee together than it is to fire off a bunch of Slack messages or a group email or whatever. An…

There are different ways something can be blocked. It's possible something is too complex to wrap your head around and you need an extra set of eyes and brains, or it might be blocked by outside impediments. It doesn't really matter, all obstacles need to be addressed and solved somehow.

Re: Scrum is fragile, not Agile

#264

Earlier quoted context omitted.

> "How could it possibly take that long? How do you not know how long it will take?" Well, if they really said that, you can just dismiss the comment as incompetent. A witty retort may be in order if a non-technical manager is in earshot, e.g.: "How long would it take for you to earn a green belt in karate?" "Hmm, what does a green belt entail?" "Exactly, you don't even know what you don't know, yet."

They did, and I replied "We don't know because we've never done this before, and we can only compare to the most similar work we've done, and any existing data." Before I could say more, they I interrupted: "You have to know, it's your job, or you don't know what your doing," or something along those lines. It was the most heated I've felt. I know what I'd reply with today, but I was younger and more naive then.

I commented above that the initial questioning was fine.

> "or you don't know what your doing,"

That though was unprofessional, and should be addressed as such.

Re: Scrum is fragile, not Agile

#265

Earlier quoted context omitted.

Waterfall was coined by a paper discussing why waterfall wasn't a good way to do software projects. You aren't wrong, either. I found Scrum to be a series of waterfalls that weren't well thought out. "Iterative Design" essentially meant, "We aren't sure what the button should do exactly, but we know we need it there and it kinda has to do this and we'll figure the rest out for the next iteration." That caused so many…

For every example of scrum operating badly there are examples of scrum working well. The common denominator in all of those situations - good and bad - is the project and middle/upper management.

> good and bad - is the project and middle/upper management.

Yep. People do not realize that the whole company has to adopt agile/scrum for it to work. It's a shift that many companies can not or will not make. They are tied to fixed deadline, fixed scope for various reasons.

Re: Scrum is fragile, not Agile

#266
post #20

Earlier quoted context omitted.

Managers need to justify their jobs. Reading off a slack report every day seems too simple and not worthy the salary they're paid. Compare that to a large meeting and live status updates, everyone stands, etc. Now that is some "serious work" happening. Think of it from the point of view that managers have mangers they report to. When shit goes wrong they have to cover their asses. "So it's late. But did you check on…

It's not like it's a requirement that "managers" be at a standup meeting. Some of the best teams I've worked on have done daily standups without managers, and I dare to say most of us enjoyed them and found them productive!

I have never been in a team where managers were present at the standup meeting. In fact, sometimes I have no idea who my "manager" even is. We've got a team, we've got stakeholders, we do the work. If a manager wants to join, that's fine, but he's not in charge of that meeting.

All this talk of standup meetings being primarily for managers is really weird. It's not for managers, and they have no reason to be present. It's for the team, to improve cooperation within the team. If the team has a better way to accomplish that, then they should use that.

Re: Scrum is fragile, not Agile

#267
post #162

Earlier quoted context omitted.

If something is self-organized, there is no need for all this ceremony and bullshit that comes with capital-A Agile or Scrum. You just shoot the shit and talk about what you're doing. Stand-ups and all the process attendant appears to be universally imposed from on high as a micromanagement technique, or because they were sold the idea as some kind of silver bullet by a talk or a snake-oil consultant.

I agree. Scrum is training wheels. If your team is mature and knows when to talk to each other then awesome, let the team do what works for them. I feel like Scrum is for teams that suffer Stockholm syndrome from poor management and need to be taught how to human beings again.

I think Scrum provides a good baseline of working for new teams, but ultimately the team is free to shape it however it works best for them.

The main value of Scrum as an official process, is that it gives you a stick with which to chase toxic management out of the room. They're not sufficiently Scrum if they crash your meetings and demand to be in charge. Though in my experience, most companies that do Scrum have a management that keeps their distance unless invited.

Re: Scrum is fragile, not Agile

#268

At the company I work at, we have the following scrum anti-patterns. I wish I knew, whether we could "do scrum right" or just move onto something simpler (fta; priority queue) * Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room. Some people stand, some people sit. Sometimes the front-end team goes, sometimes the back-end team goes. Its limited to 15 minutes, s…

> One gripe I have about scrum, is there is nobody representing engineering, as the product owner represents the business. That is definitively not be the feeling you should have. In "proper" scrum the Team is supposed to represent engineering. If you, for some reason, don't feel like you can represent these concerns then that is a huge issue. The PO shouldn't be your boss either. At least it isn't so in the company…

Yeah, that's an odd complaint. You are engineering, are you not? The meeting is already about engineering. If you have more engineering as an outside stakeholder that the PO isn't able to represent, by all means bring someone in to represent them.

Re: Scrum is fragile, not Agile

#269
post #132
post #12

He's not wrong. Having been involved in the Agile movement since before the term Agile was coined, I think of Scrum as the least interesting of Agile processes, but also the most successful in terms of adoption. I used to think that was a contradiction. Now I think it's almost inevitable. I wrote more about it elsewhere [1], but the basic deal is that most companies have other priorities than being effective, so the…

Scrum is badly misunderstood and maybe that's a failing in and of itself but it's really a victim of the developers who sold it as a magical process. Scrum simply can't be implemented as a purely developer process. The backlog exists as a rolling contract between dev and product owners and sponsors. The most common failure I see is when project leadership agrees to a fixed scope and timeline then tries to execute in…

>> developers who sold it as a magical process

If I ever find a developer who can sell, selling is not a developer's USP in general, there are exceptions and I would hire those exceptions instantly!

Re: Scrum is fragile, not Agile

#270

Earlier quoted context omitted.

DHH has a nice methodology that works with fixed deadlines: his basic rule is that features can be dropped/simplified, but deadlines must be met. https://www.amazon.com/Doesnt-Have-Be-Crazy-Work/dp/00628747...

He's applying an old concept. The Iron Triangle has been in use since the 1950s. https://en.wikipedia.org/wiki/Project_management_triangle If time is fixed, then scope and/or cost must change.

This is true, but fixing the deadline and not committing to the scope requires clear communication by the project management / sales teams with the clients about it, and this is rare.
Post reply on HN