Scrum disempowers developers • Hacker News Board

Re: Scrum disempowers developers

#361

Post by wpietri » Thu, May 31, 2018, 2:24 AM UTC

mlthoughts2018 wrote: post #265

dfsegoat wrote: post #254

Earlier quoted context omitted.

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?

One example which I actually used to great effect in a previous team was that the team decides the relative allocation of backlog items between new features, fundamental research, maintenance, and refactoring / architectural design. The product owner, no matter how upper management is breathing down their neck, is not allowed to supersede that allocation. Once we got approval for this, it meant that product owner had…

That's great to hear, and I'm sorry it blew up.

I had a less extreme version that still served our needs. My rule was that a fixed percentage of effort, say 80%, would go to business priorities. The product manager could certainly ask about where the time was going, but they couldn't claim it unilaterally. The rest of it could be ordered and reordered as the product manager thought best. We in turn could ask about that.

This worked well for us, in that it let us keep the code clean and make tooling improvements without having to explain to a non-developer what was going on.

It was also helpful that we were good at expressing technical-sounding things in user terms. E.g., all scaling and reliability work was put into the backlog with titles like, "system handles 1000 simultaneous users" or "system survives web server failure". And a lot of research was covered by the product manager buying information rather than features.

Of course, this was at a startup, where there was no "on high". The product manager was the CEO, so in theory he could have fired us, but mainly we just collaborated on getting shit done.

Re: Scrum disempowers developers

#362

Post by struppi » Thu, May 31, 2018, 4:14 AM UTC

tannhaeuser wrote: post #124

struppi wrote: post #45

If you do Scrum like that, you're doing it wrong (I know, no true Sctosman [1], and I know, there are actually dark patterns [2]). I wrote a whole book about "Agile Anti-Patterns" [3]. Most of the book's content is about things that many companies get wrong when they start with agile or lean software development. Because it is very easy to get those things wrong. Yes, those problems are extremely common. Not only wit…

That sounds ridiculously similar to people hanging on to communism/socialism: "the principles are sound, it just hasn't been implemented as intended". Except, just like communism, Scrum has never and will never be implemented "as intended" because that's contrary to our collective evolutionary gifts, and against a developer's desire to find satisfaction in good craftsmanship. A project management methodology building…

Maybe what's missing in my original comment... What I'm trying to say is that there is a certain kind of organization (mostly traditional / old organizations) who would have these kinds of problems with any agile method.

And there are other organizations who can make any agile method work for them.

So, it's not really Scrum's fault when it fails (at least not always). And it's not really (or not only) Scrum's achievement when it succeeds.

As a friend of mine, Samir Talwar, once said: "To be good at software development, you need an organization that's optimized for software development. Most organizations are optimized for something else."

Anyway, if you implement a process, but ignore even the very short (22 pages) guide that summarizes the process, but instead cherry-pick what you think will work well in your org, then don't blame the process when it does not work.

As I wrote in my book: "But changing Scrum so it works within your company will not make you more agile – It will make Scrum less agile!"

Re: Scrum disempowers developers

#363

Post by nradov » Thu, May 31, 2018, 4:42 AM UTC

tootie wrote: post #338

Clubber wrote: post #262

Earlier quoted context omitted.

Shippable quality to me is a full regression test. That's awful hard to do in the few days a 2 week sprint allows.

It's really not possible to take stories from dev to QA, to remediation to release within a sprint without having idle cycles of either developers or testers. It's what make Kanban more appealing. The sprint boundaries can be useful guidelines, but I'd never hold anyone's feet to the fire over sprint commitments. I don't care about carryover so long as we have good rolling velocity.

It's certainly possible to take stories all the way through in a single cycle. I've done it many times and seen others do it as well. There's nothing wrong with having some idle cycles. In order to maximize economic value you should focus on the cost of delay rather than insisting on 100% productivity.

Re: Scrum disempowers developers

#364

Post by AllegedAlec » Thu, May 31, 2018, 8:15 AM UTC

nickelcitymario wrote: post #249

AllegedAlec wrote: post #204

Earlier quoted context omitted.

> Nope, don't understand the trade offs if you're suggesting scrum is slower than waterfall. That just doesn't line up with my experience. "Results may vary," though. The idea is that if you have a well defined problem domain and you know exactly what the software is that you have to deliver, you don't need the short cycles, and all the meetings and pokering and whatnot would just be a waste of time. You know what yo…

I suppose that makes sense "if you have a well defined problem domain and you know exactly what the software is that you have to deliver". I don't have a lot of experience in such areas though, and i can't help but wonder how often that's the case. If my problem domain was well defined, the problem would probably already be solved by someone and I'd use their code. Why reinvent? Am I being too simplistic?

> If my problem domain was well defined, the problem would probably already be solved by someone and I'd use their code.

Not necessarily. Look for example at the team that made the code for the central computers of the Space Shuttle. They knew exactly what their code had to do, how fast, etc et.

Re: Scrum disempowers developers

#365

Post by axilmar » Thu, May 31, 2018, 8:34 AM UTC

The problem with Scrum is that it tries to solve one problem (the problem being that business processes are dynamic in nature) with a set of tools that is not meant for this kind of development (namely, static processes, static development procedures, static tools).

The actual solution to business needs is to able to create software like a clay sculpture. I.e. build the software in front of the client, using dynamic tools, satisfying their immediate needs. There is no need for sprints, retrospectives, and all the jazz, if we could actually create our software as dynamically as business processes are.

Re: Scrum disempowers developers

#366

Post by pbadenski » Thu, May 31, 2018, 8:57 AM UTC

Milton Friedman famously said that “one of the great mistakes is to judge policies and programs by their intentions rather than their results.”

Re: Scrum disempowers developers

#367

Post by [deleted] » Thu, May 31, 2018, 10:00 AM UTC

[deleted]

Re: Scrum disempowers developers

#368

Post by emilesilvis » Thu, May 31, 2018, 10:11 AM UTC

Let's do a little thought experiment where we try to stay within the scrum universe, but try to solve the main problem (developers being disempowered by scrum) by modifying the scrum framework. As the author states, "So Scrum has a master, product has an owner, but no-one is empowered to advocate for development priorities." Let's add another role to scrum called the craft master. This individual has excellent technical leadership skills and deep technical knowledge. The craft master's goal is to defend what the team is doing as a craft (much as the scrum master would defend the process of scrum itself), making sure that the craft's level of quality is manifested through a Definition of Done that takes way more of a center stage than it currently does. Would this be empowering developers?

IMHO, the answer to this question is "yes".

Re: Scrum disempowers developers

#369

Post by MrBuddyCasino » Thu, May 31, 2018, 10:50 AM UTC

sprky wrote: post #63

MrBuddyCasino wrote: post #3

Are you working in feature factory? Chances are you're doing Scrum: https://hackernoon.com/12-signs-youre-working-in-a-feature-f...

Great article, but but none of it has anything to do with scrum.

True, but they're synergistic - Scrum is the natural choice for a Feature Factory and reinforces all the bad aspects of it, Kanban much less so.

Re: Scrum disempowers developers

#370

Post by knightofmars » Thu, May 31, 2018, 12:25 PM UTC

consp wrote: post #161

specialist wrote: post #101

Earlier quoted context omitted.

Estimating is my Achilles heel. Always has been. I'm way too optimistic. My workaround was to do jelly bean estimating. Get guesses from everyone, then use the average. Worked surprisingly well. We did other things to meet that target date, honor that estimate, of course. But that's a longer story.

What I've learned in engineering (any form, including software) is take the estimate (acquired in any decent enough way like averaging) and multiply by PI (or 3 if that suits you) to get a reasonable amount. In practice it works more accurately for larger sums than smaller ones so your mileage may vary. I guess it is easier for everyone to guess smaller workloads more accurately. In my practical experience, I multipl…

Here is the "chart" that I use when determining how accurate an engineer's estimate will be. The left column is the hour estimate to look up the volatility from. The right column represents the potential volatility (probability of increasing in time) of the work item based on the hour estimate.

Hour Estimate : Volatility Level

    1 - 5 : Little to no volatility.

    5 - 15 : Small volatility (a day, maybe two).

    15 - 30 : Medium volatility (multiple days).

    30 - 60 : Medium to High volatility (days to weeks).

    60+ : High volatility (multiple weeks).

The reason behind this chart is that when determining what goes into a release there is a tendency to treat all items as static in size. What I mean is that most people will say, "Three 15 hour work items are equal to one 45 hour work item." or "Six 5 hour work items are equal to one 30 hour work item." The worst offender, "Four 15 hour work items are equal to one 60 hour work item."

Additionally, as a work item increases in size the amount of "knowable things" increases as well. Of those "knowable things" there are many known knowns, known unknowns, unknown unknowns (thank you DR for that gem). There's a near 0% chance that a team will get all of the requirements in place up front on a 60 hour case.

If a scoping team is told that they have 240 available hours to work with, then they will pick a combination of items that fit within the 240 hour box. If they have four high priority 60 hour estimate items then they may pick all four for the release. In the event that four 60 hour items are chosen I would place a near 100% guarantee that the release will not go out within the 240 hour time frame. I would even wager that will be up to four weeks late.