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

251–260 of 329 posts

Re: Scrum is fragile, not Agile

#251

Post by yitchelle »

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). -…

Not saying that this is not a good way to go, but I rarely see this happening in large complex projects, especially those that are on their way to delivering v1.0. v2.0 and beyond have a better chance of these types of "process" to work where the product evolution is not so volatile.

Re: Scrum is fragile, not Agile

#252

Post by Chris2048 »

wpietri wrote: post #191
anon1m0us wrote: post #34

Earlier quoted context omitted.

I was explicitly told not to write unit tests because they took too much time, which required me to spend entire days retesting almost 100 scenarios when the business logic changed. Of course the business didn't know all the scenarios at the beginning of the feature development and didn't care because: iterative development means we'll figure it out later.

As you've discovered, good automated testing is mandatory for iterative development. If execs tell you to do something unprofessional, it's ok to say no. Indeed, if we're going to think of ourselves as professionals, I think it's mandatory.

> if we're going to think of ourselves as professionals

We need to unify around these principles, possibly revoke memberships for unprofessional behavior. One dev getting himself fired changes nothing..

Re: Scrum is fragile, not Agile

#254

Post by JimDabell »

klyrs wrote: post #84
rileymat2 wrote: post #62

Earlier quoted context omitted.

By breaking it down into smaller stories?

My experience shows that proper testing and documentation is the first thing that management wants taken out of the story, often with the excuse "We can handle that in a later sprint." But since your life is a neverending series of sprints (note: that's actually an ultramarathon), and management gets to pick priorities, you may never return to the technical debt.

> proper testing and documentation is the first thing that management wants taken out of the story

That's not breaking down a story into smaller stories though, that's simply not doing some of the tasks necessary for a story to be complete. "Story" is not a synonym for "task"; a story is user-centric not about internals. "Write the documentation for this feature" is not a story and "write the tests for this feature" is not a story, they should be part of your definition of "done".

Re: Scrum is fragile, not Agile

#255

Post by mcv »

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…

Standups with multiple teams, or simply very large teams, are a terrible idea. I'm currently in a team that has very quick, fun and productive daily standups (despite not even having a good standup space for it), but we have only 3 devs and a handful or other people involved.

But I've also been in projects where standups drag on and on and on, and they're hard to get under control. Usually, those projects had much larger teams.

I suggest smaller teams, and if you have this kind of multi-team standup, discuss with your team to have your own independent standup instead and send one representative to the big one.

Re: Scrum is fragile, not Agile

#256

Post by matwood »

xiphias2 wrote: post #205
keypusher wrote: post #153

Earlier quoted context omitted.

Have you seen any methodology work consistently when dealing with fixed deadlines? The reality when dealing with large contracts, as you mention, is that there are almost always timetables with expectations. This poses an inherant problem due to the unreliability of estimates, so either quality or features must be sacrificed if the timeline is in jeopardy. My only experience in such an environment was using some hybr…

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.

Re: Scrum is fragile, not Agile

#257

Post by solatic »

Scrum only works if you need sprints, and you only need sprints if you have non-engineering stakeholders whose mandatory approval can only be attained in one meeting per sprint length.

Some large orgs really work like that, where the approval of one ham-fisted iron-gripped executive is deemed more important than hundreds of thousands of dollars of engineering talent going to waste. I don't think this is very effective but alright then.

Everybody else should just be using Kanban boards with periodic review.

Re: Scrum is fragile, not Agile

#258

Post by mcv »

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…

One of the points of Scrum is that you don't estimate hours at all. You estimate intentionally vague and abstract "story points". You don't need to know what that is in hours, just try to make sure that two stories of roughly equal complexity have roughly equal points. Run a few sprints, check what velocity you actually end up on, and you've got the averages you need to give a slightly more long term planning.

But without the feedback of actually having done the work, any estimate is bound to be wrong.

Re: Scrum is fragile, not Agile

#259

Post by asark »

dragonwriter wrote: post #214
asark wrote: post #94

Earlier quoted context omitted.

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

I get why they want it, but I think it's a case of false improvements from adding more computers. If the reports to management are such BS that they don't usefully resemble reality they should be able to figure that out before long and sort things out, one way or another. If they want insight into the tools the bottom-of-the-ladder workers are using to coordinate then that coordination will suffer, greatly, and those tools themselves will be full of BS, for sure, gaining little aside from some pretty "real-time" BS graphs for management and worse communication for workers.

[EDIT] more to the point, I think if it worked we wouldn't still constantly see management surprised when things aren't delivered "on time", and yet, that still happens all the time. IMO the team needs someone "on their side" to report reality upwards, diplomatically, not their own work tools reporting up directly, or they'll lie to their tools, which leads to more surprises, not fewer.

Re: Scrum is fragile, not Agile

#260

Post by matwood »

xyzzy_plugh wrote: post #54
anon1m0us wrote: post #32

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…

This mirrors my experiences to a tee. The most upsetting experience in my career thus far was being belittled by an incompetent project manager. "How could it possibly take that long? How do you not know how long it will take?" The happiest times of my career have been when we're lacking a PM -- coincidentally the most successful!

In these situations I shift the conversation to what is the PM really after. I explain that I can tell them any estimate they want (or they can make it up on their own - no need to even discuss), but does that really do them any good when it is missed? There is usually some pushback at first, but when items are delivered within estimate a few times in a row they realize it's better to take whatever hit up front than it is to miss and adjust.

Also, someone asking how could something take so long is not a belittling question. I don't see any problem with either question.

Post reply on HN