Scrum is fragile, not Agile • Hacker News Board

Re: Scrum is fragile, not Agile

#131

Post by wale » Mon, May 27, 2019, 2:09 AM UTC

tarsinge wrote: post #79

anon1m0us wrote: post #14

Earlier quoted context omitted.

The way I decided to play the game was like this, "I won't be attending the Daily Standups anymore as I don't think they add value and do subtract value." The project mgmt response was, "Attendance at standups is mandatory." Regardless, I didn't go to anymore standups and when I got flack for that, I stopped going to the office all together. When I got flack for that, I stopped working all together. Then I got fired.…

Great story from start to finish. I kept waiting for a happy turnaround but that ending was perfect.

Yea, same here.

Re: Scrum is fragile, not Agile

#132

Post by tootie » Mon, May 27, 2019, 2:10 AM UTC

wpietri wrote: 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 an agile way. Agile is the contract. But it's also a tough sell. It requires a high degree of trust to say "we'll pay you $XM in exchange for X sprints of whatever we prioritize with no fixed end state" but that's what you need to be agile. If you layer sprints on top of a fixed timeline, you're just adding needless complexity since your end state is predetermined and how you get there is irrelevant.

Re: Scrum is fragile, not Agile

#133

Post by innomatics » Mon, May 27, 2019, 2:13 AM UTC

I agree that Scrum is fragile but not that it isn't agile.

It's agile up to the point that it is broken, which happens often due to it's fragility. That it is easily broken is an unfortunate but unavoidable consequence of its complexity, and common misunderstandings/misuses.

Scrum is complex because large software projects (large as in number of people, budget and expected velocity) are never simple to manage. Scrum is complex because correct usage can not be read from a book nor gained from a qualification - it requires experienced judgement to pick the optimal usage and apply it to a team and project.

Nothing can beat the effectiveness and efficiency of a single strong developer working on a stream of well considered backlog items. That is engineer nirvana! However many projects simply require more velocity than one person can manage. From here, there is a whole spectrum of processes that should be chosen depending on resources and needs. From my experience, full scrum kicks in once you have four or five engineers on the same system.

Product management is a key point of failure in Scrum, true also with other processes. But it's felt so much more when an entire team grinds to a halt and an iteration fails.

If Scrum doesn't feel agile then you are doing something wrong. This is exactly the question the team should be asking itself at retrospectives (doesn't need to be three questions!). What's changing in your process sprint to sprint? Scrum masters are there to facilitate incremental process changes driven by team members, not a system that doesn't result in agile software delivery.

Re: Scrum is fragile, not Agile

#134

Post by addicted » Mon, May 27, 2019, 2:15 AM UTC

jrochkind1 wrote: post #69

addicted wrote: post #44

Earlier quoted context omitted.

However, many companies face similar issues. For a moment I thought the OP worked for my company because we face the same issues (that's not possible however because in person stand ups are banned at our company due to the distributed nature). 1) While I agree that 20 people seems like too large a team in general, I have a fundamental problem with the idea that scrum can determine what size team is right. What seems…

Eh, the idea that a team should be no larger than the number of people that can meet together is not unreasonable, if also not incontrovertible. What makes a team a team if they can't meet together as a team effectively?

I'd say the most important characteristic is whether the team can work together effectively.

As an example, one could consider the various people working on an individual open source project as part of a team. And most successful O/S projects rarely require everyone to meet together at the same time.

I personally strongly prefer small teams (I find even 8 members too large), but arguably certain projects may need bigger teams, and I think they should still be able to practice Agile with the bigger team, which scrum doesn't allow for.

Re: Scrum is fragile, not Agile

#135

Post by addicted » Mon, May 27, 2019, 2:16 AM UTC

addicted wrote: post #44

jboy55 wrote: post #26

Earlier quoted context omitted.

First of all, most issues with process issues are more a reflection of the organization and what drives them than the process. I would say you should start talking about, 'Our process' instead of 'Scrum'. >These things combined have dragged down the happiness of the people I work with, but we all feel imprisoned by it. I have a stack of scrum books here I plan on reading, I figure this process isn't going away and I…

However, many companies face similar issues. For a moment I thought the OP worked for my company because we face the same issues (that's not possible however because in person stand ups are banned at our company due to the distributed nature). 1) While I agree that 20 people seems like too large a team in general, I have a fundamental problem with the idea that scrum can determine what size team is right. What seems…

Thanks everyone for correcting my understanding of story points (which was based on scrum training provided by my current company).

Effort makes a lot more sense, and I particularly like that it tries to incorporate uncertainty as well (I guess that's why they chose story points, to make it vague, since using hours leads to people treating estimates as deadlines instead).

Re: Scrum is fragile, not Agile

#136

Post by VonGallifrey » Mon, May 27, 2019, 2:19 AM UTC

clumsysmurf wrote: post #3

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 I work for. It sounds like the PO is the boss of that team, if he "keeps you busy". I am super grateful that our Scrum Master knew what he was doing and suggested creating a separate line on the Org chart for the POs so that they are explicitly not in charge of development. The team is in charge and POs are more advisory.

Sounds to me like there are some deeper problems in the company then just the scrum. There are so many red flags in your comment. I don't know if those books are going to help you "play" scrum better, because what you guys are doing does not sound like scrum at all.

Kanbans probably also not a solution. I really like Kanban, but it isn't going to remove the bad elements that seem to control that company.

Re: Scrum is fragile, not Agile

#137

Post by thunderbong » Mon, May 27, 2019, 2:20 AM UTC

From all the comments, I see that arguments are there both ways. I also understand that we should follow a process that bets suits the business. I would really like to know how we could set up an Agile process provided that is what is required.

Is there anywhere this would be documented to explain - a. How an agile process in initiated? b. How an agile process is maintained?

I have been part of a team with mis-applied agile processes -

1. Requirements change frequently. And not due to users asking for them. More like the Project Managers asking for more configurablity.

2. Requirements are not thought through. Even the simplest cases.

3. Changes don't get vetted by users. Instead, we go through another round of requirements!

4. Every once in a while requirements (and teams) get re-organized, re-planned which puts all the developers off.

I have also been part of a team which focussed on deliveries. This team has been able to write tests and iterate over requirements fast. The satisfaction level of all the developers in the team as well as the project owners were high.

1. Requirements were phased.

2. Whatever was required to be done in each phase was thought through as far as possible. Anything that wasn't clear or was more complex to think out was sent back to the project owners / users for clarity.

3. Code and tests get written. Phase delivered.

Although this process was extremely successful, I don't know if I would call this Agile.

Re: Scrum is fragile, not Agile

#138

Post by z3t4 » Mon, May 27, 2019, 2:21 AM UTC

pandapower2 wrote: post #118

BlueTemplar wrote: post #98

Earlier quoted context omitted.

Is the Silicon Valley representative of software development though ? Because on the other hand we have professors telling us that the average (surviving?) software lifetime is 20 years...

This is just intuition but I suspect that the lifetime for software is u shaped. Much of it is very short lived but software that lasts more than 1-2 years is very likely to live for a decade or more. A lot of 6 month old code gets thrown away either because its been rewritten or because it didn't achieve its stated objective. Meanwhile a bunch of companies are relying on systems that were first created in the 90s be…

There are many 20 years and older code bases currently. But if you start a new code base today it might get rewritten many times in the next few years because software users no longer have the power to stay on an old version due to the SaaS paradigm.

Re: Scrum is fragile, not Agile

#139

Post by wpietri » Mon, May 27, 2019, 2:21 AM UTC

sidlls wrote: post #128

wpietri wrote: 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…

I don't find much constructive value in your comment. To me it seems like a politely worded screed about the incompetence of management and organizations. To drive the point home I could easily transform "[o]n average, the first priority of managers and execs is maintaining the power structures that make them a big deal" into a derogatory comment about engineers, fad chasing, and resume padding by a simple word subst…

I have been both a manager and an executive. As well as a consultant in many companies both small and large. I'm not saying that those people are necessarily incompetent. I'm saying that, per POSIWID, the purpose of most software organizations is not effectiveness in making software (or in serving users via software).

That's not constructive in the sense of providing ways to solve the problem. But that wasn't my goal. My goal was to support and confirm the article's thesis. I have also written plenty of constructive things on software development, but I think it's absurd to suggest that every HN comment must contain that kind of constructive feedback. (And if that were a reasonable standard, you aren't living up to it.)

Re: Scrum is fragile, not Agile

#140

Post by ScottBurson » Mon, May 27, 2019, 2:22 AM UTC

marcosdumay wrote: post #127

ScottBurson wrote: post #83

Managers, not understanding the difference between latency (how long each task takes) and throughput (how much work is getting done in total), always try to optimize for latency. The predictable result: throughput goes to hell, and then latency goes with it. People who actually write software understand that you have to optimize for throughput first. Not to worry: latency won't be forgotten! But a primary focus on th…

The rationale is that if you minimize latency, throughput has to be maximum too, so optimizing latency is enough. In practice latency is the goto target for optimizing actual processes. It's the most linked with all the risks. But software development is not an actual process.

> The rationale is that if you minimize latency, throughput has to be maximum too

Exactly. And it's quite wrong even without taking the growth of complexity into account — as every engineer knows, or should know. Getting every task done as quickly as possible requires a lot of context switching, which is murder on throughput. When you add in the effects of complexity growth (aka technical debt, though I think "complexity growth" is clearer) the disadvantages of optimizing for latency become that much more serious. And the worst part is, as the disease progresses and latency deteriorates, managers try to cure it by applying even larger doses of the poison.

This idea that managers optimize for latency, while I optimize for throughput, occurred to me only recently. But as I look back over the disagreements I've had with managers through the years (including disagreements over the usefulness of Scrum processes!), it's quite remarkable how many of them seem to come down to this.