Scrum disempowers developers • Hacker News Board

Re: Scrum disempowers developers

#251

Post by conatus » Wed, May 30, 2018, 4:38 PM UTC

mlthoughts2018 wrote: post #192

conatus wrote: post #156

Earlier quoted context omitted.

Seems you are shakey ground, without empirical justification, to say that in the majority of cases when applied scrum goes badly. We are probably at the point of trading ancedotes, but I'd say in the majority of cases where I have seen it applied it has worked more than it has not. Even a poor implementation has yielded some benefits. And those pieces that have not worked there are reasons why.

I agree we might be at the point of trading anecdotes. I would suggest though that there could be the problem that a team works hard to produce good outputs in spite of Scrum, rather than because of it . My feeling, as I have mentioned elsewhere is that this burden of proof is on Scrum and Scrum proponents to back up the claim that it facilitates better business outcomes than would otherwise have been obtained withou…

Well all I can say is that I've seen multiple teams implement scrum and this improve overall team productivity, usefulness to the wider organisation and general happiness amongst all members of the team. I have no evidence to suggest that it was anything but adding the framework to the mix that caused these effects. And the more the processes were adhered to by the letter of the framework (i.e. all meetings were adhered to, stand ups were understood well etc), the better the results have been.

Of course one could argue that the improvements were the result of some other phenomena. But it certainly seems that the equation seems to have worked and turned teams around. Scrum wasn't in the mix before and now it is things are much improved.

By the way I'd in no way advocate a one-size fits all solution. Sometimes other techniques might be as effective or more effective. I'd not say you should agree another way is definitely better if your team is humming along. Why would I?

Re: Scrum disempowers developers

#252

Post by Clubber » Wed, May 30, 2018, 4:38 PM UTC

geezerjay wrote: post #246

specialist wrote: post #195

Earlier quoted context omitted.

"...there is no well defined goal nor can one exist." Consulting is the pejorative we gray beards used for that activity. You reminded me of another pithy throwaway line: Agile didn't improve outcomes, it just reduced the cost of failure, allowing teams to fail many more times with the same budget.

> Consulting is the pejorative we gray beards used for that activity. Those hypothetical gray beards may come up with all the pejorative terms they need, but that only hides the fact that they are entirely oblivious to the reality of running a successful software project, one which actually meets the client's requirements and delivers working products. Therefore, they spend their time coming up with pejorative terms…

>but that only hides the fact that they are entirely oblivious to the reality of running a successful software project

Wow, amazing that the shoulders of the giants you stand on was never a successful software project.

>In the old timey's waterfall world, a waterfall project that's executed flawlessly is a project that ends up delivering the wrong product that fails to meet the client's basic needs, thus leading to a very unhappy client that may even feel that he has been played.

Waterfall was iterative as well, when the needs changed, so did the project plan. You bought that line, but that's not how it ever was in my experience. You know those version numbers software has? Those are the iterations. We'd cut a release about every 3 months.

Based on your comment, I suspect you've never done anything outside of scrum / agile, so you are comparing it to some mythical way of doing things you heard about (undoubtably from scrum consultants.)

Re: Scrum disempowers developers

#253

Post by rwmj » Wed, May 30, 2018, 4:38 PM UTC

simonswords82 wrote: post #240

rwmj wrote: post #208

Earlier quoted context omitted.

My experience is that a good team does a good job. A bad team doesn’t. My experience is that sprints interrupt my workflow to such an extent that I can no longer get anything done. In other words, they make a good team bad.

How so? I'd be keen to hear just in case I'm unwittingly inflicting similar pain on my developers.

Perhaps it's just me, but I need long periods uninterrupted to work. It's not just the regular status meetings, but other meetings which break up the day to an extent that I can no longer get that.

Re: Scrum disempowers developers

#254

Post by dfsegoat » Wed, May 30, 2018, 4:39 PM UTC

mlthoughts2018 wrote: post #243

wpietri wrote: post #113

Earlier quoted context omitted.

I think you are entirely right that the "sell books and consulting" is a major driver of what Agile became. I got involved in the Agile world circa 2000, but by 2010 or so my main feeling was increasing horror: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how... One of the especially interesting things to me was that at the beginning there were a variety of different methods. People behind them got togeth…

> "If you go by actual behavior, it turns out the highest priority at most companies is not actually to improve, to get better at making things for users. It's instead to make managers and executives feel like something is being done without disturbing the power hierarchy. Low-end Scrum fills that need adequately, letting you move marginally in the direction of agility, apply some new labels, and declare "mission acc…

Would love to hear more about practical examples of "barriers to anti-quality". Would this be things like e.g. "Emplace and enforce documentation & project change control process" -- people may want to make changes - but if they don't go through the change request process - they can't have those changes effected?

Re: Scrum disempowers developers

#255

Post by mey » Wed, May 30, 2018, 4:43 PM UTC

nickelcitymario wrote: post #36

Like any and every business theory, Scrum has one or two core ideas that are awesome, but could be explained adequately in a paragraph or two. This does not sell books and consulting, so it evolved into a field of its own. The fact that there is so much B.S. in Scrum doesn't mean that it has nothing of value to offer, though. Here's what I get out of it: 1. Sprints are a better way to organize than Waterfalls. I've e…

Another observation I have had, it provides much clearer and realistic progress reports to management. You can track the normalized points per day executed by the team to see their overall velocity. You have clear check points about what has been accomplished (which is why a shipped product is critical, it removes any chance for something not to meet DOD)

On the dev side, I have never attended so many meetings. Technical debt being addressed is generally against the feedback loop, unless the PO/Leads of the team make it their first priority. Grooming meetings are a mix of people who care, those who don't, and vague stories. To save time, any new story got sent to one of the devs for a sniff test before grooming, to help ask critical questions early. Typically, the request is reasonable, but may run into a contradiction of the system.

I have also found that, forcing scrum (or waterfall) on a product that is running at a difference release methodology is horrible. Got a customer that needs a new thing built by a specific date? That won't fit, unless the date is flexible and customer stake holders can be deeply involved in the process. Waterfall at least forces the customer to define the project up front and allows for calling out changes to the plan and thus changes to the scope.

As with all the above, this sits on how skilled your project manager/scrum master/product owner are at their jobs. Anti patterns abound.

Re: Scrum disempowers developers

#256

Post by mlthoughts2018 » Wed, May 30, 2018, 4:43 PM UTC

conatus wrote: post #251

mlthoughts2018 wrote: post #192

Earlier quoted context omitted.

I agree we might be at the point of trading anecdotes. I would suggest though that there could be the problem that a team works hard to produce good outputs in spite of Scrum, rather than because of it . My feeling, as I have mentioned elsewhere is that this burden of proof is on Scrum and Scrum proponents to back up the claim that it facilitates better business outcomes than would otherwise have been obtained withou…

Well all I can say is that I've seen multiple teams implement scrum and this improve overall team productivity, usefulness to the wider organisation and general happiness amongst all members of the team. I have no evidence to suggest that it was anything but adding the framework to the mix that caused these effects. And the more the processes were adhered to by the letter of the framework (i.e. all meetings were adhe…

I wish more Scrum-advocates shared your opinion.

Hey, if Scrum is working for some team, I would be the last person to ask them to change it. I know how much I hate it when I have a workflow that is succeeding and then management arbitrarily makes me switch to Scrum. So I would not want to do that to people who are doing great with Scrum.

The reason I feel the need to deeply question it though, is that most managers don't express the attitude you expressed. Most often they see a workflow as something they need to enforce unilaterally, and that it should function to commoditize the underlying teams.

Given that this is how it's practiced almost everywhere, it's fair to ask why is that? Is there anything intrinsic to Scrum that makes that mistake easier? Or at least, is there something Scrum lacks which would make that mistake harder?

And then to finally ask if someone is advocating for everyone to be happy switching to Scrum, and advocating that every possible problem with Scrum is not Scrum's fault but always just the misapplication of Scrum (like they are interpreting a religious text or something), then I think it's fair for me to say, "prove it" and ask for evidence that the extra operational overhead of Scrum is empirically shown to be cost-effective.

Re: Scrum disempowers developers

#257

Post by Clubber » Wed, May 30, 2018, 4:45 PM UTC

srtjstjsj wrote: post #219

dgreensp wrote: post #167

Earlier quoted context omitted.

Having worked at primarily at “informally agile” software companies in Silicon Valley (and I count Google as one), I see an important bit of truth in the article that Scrum ideas have become the embodiment of agile, and ideas from Scrum that may not make sense in isolation have become standard practice in software development and are somehow seen as the alternative to “waterfall” development, even if they have nothin…

Where has management forced Scrum onto a team that was already successful?

Every company I've ever worked at. It's how Bozo managers get points from their Bozo managers. "I can save you a lot of money by converting to Agile / Scrum."

What it really means is, "I'm not really responsible for making deadlines anymore."

Re: Scrum disempowers developers

#258

Post by specialist » Wed, May 30, 2018, 4:46 PM UTC

mmusson wrote: post #242

specialist wrote: post #144

Earlier quoted context omitted.

The CASE motivated tooling got in the way. My go to joke: RationalRose is like an 800lb angry gorilla sitting between you and your work. Alistair Cockburn did a great post mortem about that era. Characterizing people as non-linear, first-order components in software development [1999] http://alistair.cockburn.us/Characterizing+people+as+non-lin... During that time, I strongly preferred lo-fi paper prototyping for UI.…

It’s funny looking back at what we used to call software development methodologies. Booch and Rumbaugh were primarily focused on modeling. Any talk of process meant a dynamic description of the program. Jacobson was a little more method focused. You can see how his introduction of use cases started the idea of talking to your customer about what they need. I remember seeing Rose and thinking this will make a huge imp…

Finally! I get share my Booch story:

At OOPLSA 98, Booch convened the first society of software architects (or some such).

Having read all his writing (ditto Yourdon, Brooks, Rumblaugh, etc), I was super excited.

During the Q&A I finally got to ask “What is software architecture?”

Booch replied “Software architecture is what software architects do.”

Bubble popped.

I gave up seeking the council of the priesthood and blazed my own path.

Re: Scrum disempowers developers

#259

Post by some_account » Wed, May 30, 2018, 4:47 PM UTC

vannevar wrote: post #143

some_account wrote: post #112

Earlier quoted context omitted.

I really dislike agile. A product owner asked me once if I get some benefit from them...and no, I don't. Thry get a lot of benefit from me sharing what I'm doing because they can then keep track of it and communicate it to other people, but I don't get any benefit personally. I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them. I dont want anyone in the mid…

I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them. How exactly does agile prevent you from talking to your teammates and getting feedback from them?

Team mates are the ones I'm working with all the time. I don't need scrum processes to talk to my team. A good team knows how and when to share information.

Re: Scrum disempowers developers

#260

Post by Bekwnn » Wed, May 30, 2018, 4:49 PM UTC

mlthoughts2018 wrote: post #243

wpietri wrote: post #113

Earlier quoted context omitted.

I think you are entirely right that the "sell books and consulting" is a major driver of what Agile became. I got involved in the Agile world circa 2000, but by 2010 or so my main feeling was increasing horror: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how... One of the especially interesting things to me was that at the beginning there were a variety of different methods. People behind them got togeth…

> "If you go by actual behavior, it turns out the highest priority at most companies is not actually to improve, to get better at making things for users. It's instead to make managers and executives feel like something is being done without disturbing the power hierarchy. Low-end Scrum fills that need adequately, letting you move marginally in the direction of agility, apply some new labels, and declare "mission acc…

My experience with scrum at work using VSTS is that you do have the option to mark tasks as closed and fill/dropdown box the reason why. If not on your own, then at a scrum meeting when the story or task comes up. (If you need to discuss whether or not it should be closed.)