Scrum is fragile, not Agile • Hacker News Board

Re: Scrum is fragile, not Agile

#211

Post by dragonwriter » Mon, May 27, 2019, 7:40 AM UTC

wpietri wrote: post #141

dragonwriter wrote: post #107

Earlier quoted context omitted.

> Scrum is iterated waterfall. No, it isn't. Iterated waterfall is at least as old as the first paper discussing waterfall, but while scrum mandates interations, it doesn't mandate much about how work is done in the iterations, and specifically does not mandate the process steps associated with waterfall; further, it emphatically rejects the role separations and handoffs associated with waterfall during the iteration…

What percentage of Scrum teams do you believe are "properly cross-functional and self-organizing"? And could you point me to examples of people losing their Scrum certifications for not living up to that standard?

> What percentage of Scrum teams do you believe are "properly cross-functional and self-organizing"?

About the same percentage as that of “Agile” software development shops that put people and interactions above processes and tools.

OTOH, at any place that is considering implementing either, there are decision makers who can influence (or in the case of Scrum more than Agile, authoritatively direct) whether or not that's the case, so for them, at least, it's worth distinguishing between problems with Scrum as prescribed and problems which often occur because decision-makers decided to ignore key parts of Scrum-as-prescribed.

Re: Scrum is fragile, not Agile

#212

Post by dragonwriter » Mon, May 27, 2019, 7:44 AM UTC

doomslice wrote: post #64

dragonwriter wrote: post #36

Earlier quoted context omitted.

> Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room It is central to the idea of the daily standup is that it is one team . > Its limited to 15 minutes, so nobody says much of importance, and just parrots what is already on the Jira board. If you have another mechanism for sharing what each person has done and is doing, then the standup should just be for shar…

> As long as you are also doing backlog grooming and have items groomed beyond the current sprint commitments, you can take additional items opportunistically, if there is excess capacity after doing the committed items properly. The powers that be at my work decided that “sprint predictability” is the most important metric here. This means that if we pull in stuff near the end of the sprint but don’t finish, predict…

There's certainly environments where that makes a lot of sense, particularly where the software at issue had immediate effects on external users who require advance notice of changes (I actually work in that kind of environment, and though we do have opportunistic items they generally are restricted to items that don't impact external users.)

Re: Scrum is fragile, not Agile

#213

Post by acd » Mon, May 27, 2019, 7:47 AM UTC

I think that longer term strategic planning is missing from the Agile Scrum manifesto.

Agree with the Software development priority queue part being good thing.

Long term planning was in the waterfall process which does not work that great either since it tends to over focus on planning.

How do you find a good balance between Agile and Waterfall?

I think it can also be different what process works well if you are a startup and need to deliver a MVP minimum viable product as soon as possible. Compared a bit to if you are a long term enterprise company and need to maintain your code base over time. Ie dealing with technical debt from short term solutions vs long term stable.

Re: Scrum is fragile, not Agile

#214

Post by dragonwriter » Mon, May 27, 2019, 7:49 AM UTC

asark wrote: post #94

doomslice wrote: post #64

Earlier quoted context omitted.

> As long as you are also doing backlog grooming and have items groomed beyond the current sprint commitments, you can take additional items opportunistically, if there is excess capacity after doing the committed items properly. The powers that be at my work decided that “sprint predictability” is the most important metric here. This means that if we pull in stuff near the end of the sprint but don’t finish, predict…

My (related) experience has led me to believe reporting to management should be strictly separate from any tools or processes used to track actual work, specifically to avoid dumb shit like this. Team task-tracking should be a team communication tool. If you want to report task-related stuff upstream it should be totally separate, with updates/sync done by a human (project manager would make sense). I also think spec…

> My (related) experience has led me to believe reporting to management should be strictly separate from any tools or processes used to track actual work,

This probably increases the accuracy of the work trackers but increases the B.S. level of management reporting in organizations where there are fundamental problems between management and the working level.(Which is the only reason anyone would want to separate these two things.)

While this probably seems like an improvement from the working level, it's probably bad for the organization. The solution is not dis-integrating communication tools so that management's view is not connected to the actual work tracking, but dealing with the fundamental trust issues. Which is hard, of course, but things that are important often are.

Re: Scrum is fragile, not Agile

#215

Post by BoiledCabbage » Mon, May 27, 2019, 8:05 AM UTC

asplake wrote: post #206

tootie wrote: post #132

Earlier quoted context omitted.

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…

There are in fact two kinds of Scrum (or rather, Scrum implementations), both of them compatible with the Scrum guide: ‘Left to Right’ Scrum (backlog-driven, implementation-focussed) and ‘Right to Left’ Scrum (goal-oriented, iterative). Unfortunately Scrum is too often explained and implemented that first way, leading to the anti-Agile feedback we see on HN with some regularity. The second way is much more compatible…

"Right-to-left scrum" seems like a hollow phrase made up by that consulting firm you linked.

From what I can tell, it has all the meaninglessness of an empty buzzword used primarily as a method of trying to engage people and give an opening on selling their services by stating "oh if you don't understand the difference sit down with us and let us show you how different and better it is."

It looks like if scrum doesn't work they call it "falling left to right scrum", and if it works it's their "brilliant right to left scrum".

Even by their own definition they both have a backlog that gets prioritized and selected each 2 weeks into a sprint backlog, and executed during the sprint.

The rest is just hand waving. "One is goal focused vs the other is backlog focused. Oh yeah but we do put our goals in the backlog." So they're both backlog focused then? The only thing they're really sayings is "When prioritizing tasks, make sure they accrue to something and aren't just random work." Which is both obvious, and of course too simple to write and sell a book about, so instead this whole other terminology is made for it.

Thanks for sharing the link though.

Re: Scrum is fragile, not Agile

#216

Post by maxxxxx » Mon, May 27, 2019, 8:11 AM UTC

seer wrote: post #188

sopooneo wrote: post #114

Earlier quoted context omitted.

If you can say more than a minute, but less than a decade, you've already got SOME idea of the timeframe for a task. Granted that sort of estimate would get you called to HR for insubordination. But can you pull the bounds in from either direction at all? I say this as someone just moving into project planning and management. From that perspective you start to see that some level of estimation s critical. My preferen…

One manager I’ve worked with had the brilliant notion of “x2+1” time of what the dev says. Anecdotally this has worked out remarkably well throughout my career - from single dev to cto - even stuff that I _new_ was going to take for example 2 days, if done properly ended up in like 5. Didn’t matter if I was doing the estimate or someone else. At some point I just gave up and started doing the “my gut says 3 hours, so…

I also generally have had good success with guessing a number and then multiplying it by 5 to get the time when it’s completely done, tested and documented.

Re: Scrum is fragile, not Agile

#217

Post by sgt101 » Mon, May 27, 2019, 8:24 AM UTC

Scrum is a communication contract between customers / stakeholders, managers and dev teams. It is a poor cure for social and managerial dysfunction, but it is a cure.

Scrum is a problem when it is mandated and imposed on functional organisations that do better and more fluid communication. This is often done as a way of flexing corporate power and does huge damage.

A key problem is that we do not have ways of auditing and measuring the performance of software teams no matter what methods they are using - until then this is all anecdote.

Re: Scrum is fragile, not Agile

#218

Post by jon-wood » Mon, May 27, 2019, 8:24 AM UTC

acd wrote: post #213

I think that longer term strategic planning is missing from the Agile Scrum manifesto. Agree with the Software development priority queue part being good thing. Long term planning was in the waterfall process which does not work that great either since it tends to over focus on planning. How do you find a good balance between Agile and Waterfall? I think it can also be different what process works well if you are a s…

Strategic planning doesn’t belong in a process designed to provide constant iteration on a two week basis. In successful organisations I’ve worked with strategic planning is one of the things that feeds into the backlog of features to be developed, and runs in parallel to development.

Re: Scrum is fragile, not Agile

#219

Post by brazzy » Mon, May 27, 2019, 8:25 AM UTC

gchucky wrote: post #126

forgotmypw wrote: post #41

I've worked on more than 10 different Scrum teams, and have seen it done well exactly once. When it was good, it was very good. But we spent one entire workday (7 hours) on each sprint follow-up meeting, and then another entire workday planning the next sprint. That is what it took to write the stories, break them down into one-point pieces, prioritize with the PO, pass the stories out to the devs, etc. Most places j…

I'm on a team that started doing Scrum a few months ago, and we're still figuring it out. To be clear: are you saying that the one team that did Scrum well did so because they spent more time on the process? Reading what you wrote, spending two full days every two weeks to plan sounds, well, terribly dragged out. Does it feel like the time was well spent, or was it a slog?

> are you saying that the one team that did Scrum well did so because they spent more time on the process?

Creating fine-grained, detailed user stories and making sure that everyone understand them and agrees on the prioritization is not time spent on "the process", it's requirements engineering.

Re: Scrum is fragile, not Agile

#220

Post by goatinaboat » Mon, May 27, 2019, 8:26 AM UTC

tootie wrote: post #132

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…

it's really a victim of the developers who sold it as a magical process

Developers may advocate small-a agile, but I have never heard of an actual developer pushing for Scrum, SAFe, or any of the name-brand "agile" methodologies, that come with expensive consultants and certifications and "coaches" and conferences and a whole ecosystem around them. These are things for project managers for the benefit of project managers who see project management the main deliverable l in and of itself. The same with JIRA actually, it's not a software development tool, it's a project management tool, sold to the same people who previously bought MS Project. These things are all overheads in the software development process, not enablers, as another poster says, the goal of most organisations is not to be effective at their stated mission, but to maintain their internal power structures.