Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scrum is fragile, not Agile

dennisweyland.net

Post reply on HN
Print view View original

301–310 of 329 posts

Re: Scrum is fragile, not Agile

#301

Post by yibg »

leib wrote: post #210
yibg wrote: post #202

The best place I've worked at as a developer essentially had no process. It's also the place I really saw the benefits of having good managers (or a project manager, but here the manager took this role). Essentially the "process" was: - Someone gets an idea to do something, e.g. PMs wants to add a feature. - The manager (maybe with the help of a dev) figures out which teams need to be involved (e.g. dependencies). -…

But how did you ensure that you udnerstood the requirements if you were potentially just left to it for a few months? At the end was there ever an instance of the client not using what you produced because it wasnt what they wanted?

You have direct access to the PM and work closely with them. If you weren’t clear on something you ask, if you don’t agree with something you debate it out.

Like anything else there is no silver bullet. Sometimes you got the feature right, other times it misses the mark.

Re: Scrum is fragile, not Agile

#302

Post by postfacto »

TeMPOraL wrote: post #250
coldtea wrote: post #231

Earlier quoted context omitted.

> I have almost never seen Scrum sold as magical by developers. Executives? Yes. Consultants? Yes. But developers? In many places, especially smaller ones, project managers are also developers (or lead developers etc), and they often drink the Scrum kool-aid.

Seconded. I've also seen it promoted by developers who are in what one could call a "honeymoon period" of their careers. First or second job, probably learned programming at university so every task is an interesting challenge, SCRUM is their first agile methodology, they don't have enough broad knowledge about programming and the industry to become disillusioned and cynical. I've had such people evangelize SCRUM to…

I’ve noticed this, too. For some reason a junior developer on my team 2 years our of school was made into scrum master, and if we so much as sneeze there’s no JIRA ticket for it he starts whining.

Re: Scrum is fragile, not Agile

#303

Post by Aeolun »

rileymat2 wrote: post #62
Aeolun wrote: post #61

Earlier quoted context omitted.

You can never take a 4 week story in a two week sprint. When would you ever be able to complete it?

By breaking it down into smaller stories?

That would be ideal, but we are devs, we don’t get to touch the stories other than to mark them as done...

Re: Scrum is fragile, not Agile

#304

Post by dragonwriter »

wpietri wrote: post #280
dragonwriter wrote: post #211

Earlier quoted context omitted.

> 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 th…

Most nominally "Agile" shops are in effect doing Scrum, so I'm not sure that answer helps your case. Either way, it sounds like we agree the "good Scrum" shop is at best rare. Given that, I think it's worth considering that the problem is Scrum. Especially given that Scrum is not just a process, but an organization and an army of "certified" people that sell services. When something generally doesn't work for its sta…

> Most nominally "Agile" shops are in effect doing Scrum

No, most nominally Agile shops are also nominally doing Scrum, but actually doing not-Scrum in a not-Agile context, largely due to sabotage of both core principles of Agile and foundational elements of Scrum by management.

It doesn't matter what name and superficial ritual you put on the process if it's all window dressing over top-down disempowering command-and-control by persons who are neither doing the work nor experts on the work.

Which isn't to say that the Agile and Scrum bodies of work aren't part of the problem: neither really addresses as a key point how the team effectuates ownership of process and how interaction with management works, which means those gaps get filled in (or rendered moot, in the first case) in ways which compromise what those bodies of work do prescribe because.

Lean, which comes from basically the same perspective (while they don't cite exactly the same values as expressed in the Agile Manifesto, being Lean essentially implies being Agile and vice versa) and is a good body of knowledge to draw from alongside Agile, is better in this regard, and so places nominally drawing on Lean seen to be more likely to be doing what they say, because Lean doesn't leave as much of the core vital parts without good guidance.

Re: Scrum is fragile, not Agile

#305

Post by postfacto »

diydsp wrote: post #262
taneq wrote: post #67

Earlier quoted context omitted.

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 shou…

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.

I once had a manager who, on the subject of upper management wanting to ship the prototype, would say “the difference between dev and prod is one letter.”

Re: Scrum is fragile, not Agile

#306

Post by tootie »

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

I have almost never seen Scrum sold as magical by developers . Executives? Yes. Consultants? Yes. But developers? I agree that fixed-scope contacts cause a lot of problems for Agile approaches. However, they also cause a lot of problems for non-Agile approaches. If I have to deal with supposedly fixed-scope situation, I'm going with and Agile approach. There are two basic cases. One is that scope is truly fixed (whic…

It was heavily hyped by developers about 10 years ago. Now they've all given up because they didn't learn the right lesson.

Re: Scrum is fragile, not Agile

#307

Post by trickstra »

> In other words, it is a very specific and well-defined process. This does not sound agile and it also does not sound Agile (remember: “Individuals and interactions over processes and tools”)

This is a many times debunked myth about the Agile manifesto. Even the authors themselves explained that "Individuals and interactions over processes and tools" does not mean and shouldn't be taken as "no processes".

Also, agile is not about moving quickly but about being able to easily change direction any time, therefore dealing better with changing environment.

Re: Scrum is fragile, not Agile

#308

Post by postfacto »

alkonaut wrote: post #203
megaremote wrote: post #152

Earlier quoted context omitted.

> Daily standup Change them so that people talk about what is blocked then. > Scrum master Tricky, like anyone who doesn't want to adapt. > Technical debt Create tickets for debt, put them on the backlog. > Poor product owners Tricky.

> Create tickets for debt, put them on the backlog. That will risk making a huge technical debt section in the backlog that will find it hard to get priority. It's better to condition new features/bugfixes on the cleanup that caused them. "I can add this feature in 1 day but will need 4 days to clean it up. So my estimate is a week." I constantly nag developers to do this when they find that they are pressed for time…

That will just lead to stories to change something simple the color of a button taking 3 days because you hit a tech debt minefield refactoring. You don’t want someone looking at JIRA and seeing it took you 3 days to change a simple button color.

Keep technical debt in separate tasks to make the tech debt visible and to keep management accountable for not making efforts to get rid of it.

Re: Scrum is fragile, not Agile

#309

Post by nicwolff »

fabioborellini wrote: post #197
maxxxxx wrote: post #42

Earlier quoted context omitted.

I passionately hate being asked for "commitments". If it's stuff of any reasonable complexity or novelty I will have no idea how long it will take and therefore can't make any commitments. The only thing I can commit to is to make sure that people don't waste time and work towards the goal. The problem is that management has no problem wasting a lot of time with useless meetings or not committing to the final feature…

Even better is being told to commit by the Scrum Jesus (who does not even try to understand the business domain or engineering issues, since he's getting hired for being the Scrum Jesus) to stories with no one available for even defining or discussing them. Our story might have been just a word someone saw at a trade fair. Then, two weeks later, being asked why I did not complete what I committed to.

In that situation I've gotten a lot of mileage (and quiet amusement) from pointing out that Scrum dropped the term "commitment" for "forecast" in 2011. Scrum Jesus has no defense against Scrum itself!

"Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint."

https://scrumguides.org/revisions.html, "Changes between 2010 and 2011 Scrum Guides"

Re: Scrum is fragile, not Agile

#310

Post by verinus »

VonGallifrey wrote: post #136
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…

this.

In scrum the dev teams maintains a technical backlog and fills the sprintbacklog as THEY see fit- from the product backlog AND the technical backlog.

the PO has no say in this! he can complain that he thinks not enough features from his product backlog are planned, but should trust that the team knows what they are doing.

Post reply on HN