Earlier quoted context omitted.
Well, sure it stumbles into this fallacy but so does the roll out of any process involving humans that has a set of normative criteria with a given critique in hand. I always feel this fallacy is a weak response as norms can always be applied well or less well. This is what makes them norms. I've seen it work very well. I've seen it work badly. Where it has worked badly it was because the process was not fully unders…
But if a given norm is always applied badly, it’s disingenuous to say it’s not the norm’s fault. It obviously is. Even if it’s a good norm in theory, if it doesn’t survive contact with human sociology in practice, then it’s disingenuous verbal gymnastics to say “but the norm itself is good, it was just misapplied constantly and nobody, despite huge effort, could stop it from being misapplied.” And Scrum is misapplied…
Scrum disempowers developers
131–140 of 382 posts
Re: Scrum disempowers developers
#132If 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…
Re: Scrum disempowers developers
#133Our weekly "why scrum sucks" post that's really a "why my company does scrum wrong and I don't know how to fix it". Product owners push customer value. Of course. You should too. Code quality and refactors have business value. Reduced maintenance cost, fewer bugs, faster future dev. If you can't explain that to your product owner then maybe it's not worth doing. I think your big missing piece is the collective owners…
Who is the “you” here? Who is supposed to explain to the product owner that code quality and refractors are worth doing? The real issue the article brings up is that Scrum has an individual who takes ownership and responsibility for the product backlog, it has an individual who takes ownership and responsibility for the project management, but it has no individual who takes ownership and responsibility for the non vi…
The development team!
Re: Scrum disempowers developers
#134This is a good article, but I disagree that Scrum's major flaw is a lack of hierarchy on the development teams. I've worked on some great self-organizing teams, and they're more than equal to the product manager. They outnumber the PM, after all. The problem only comes in an organizational culture of "whatever the boss says". In that context, teams rarely learn to self-organize. Instead, the previously existing contr…
That's what happened at my place. Instead of having only product owners, scrum masters and Dev teams we now have project managers, business analysts, line managers plus product owners, scrum master and Dev team. And all of these roles have some level of authority and want their own personalised reporting.
So instead of less management we now have more.
Re: Scrum disempowers developers
#135Earlier quoted context omitted.
> This does not sell books and consulting, so it evolved into a field of its own. It's funny how it turned into UML
UML comes out of a different culture of development, that of the Rational software crew. They had their own much more heavyweight process than the Agile folks: RUP, or the Rational Unified Process: https://en.wikipedia.org/wiki/Rational_Software#UML_and_RUP There was a little overlap; in particular, Martin Fowler wrote an intentionally thin book called "UML Distilled". But the UML world was generally heavy on both up…
This particular comment, the "UML Distilled" reminder, triggered a few hindsight notions.
Much like XML and J2EE tainted Java, I'm now having trouble distinguishing between UML and OOAD. Though I preferred Fusion to UML, I'm now wondering if any OOAD based methodology had a chance.
"...thinking that the main value of UML was in having a consistent language..."
Guilty. For a long time, I very much wanted executable models, roundtripping. I got over it. Now I place more weight on concision, DSLs.
But here's the new (to me) notion:
Maybe UMLs (and RUP) greatest benefit was the idea of having a list of questions to ask. You know, a methodology.
Writing this out, it sounds stupid, so please forgive my stumbling.
But two things stand out from the 90s, which I'm missing terribly today.
I miss Joel Spolsky's 12 steps to better code. What's today's equivalent? I haven't found it.
I miss strategy, strategic thinking. With all this agile stuff, I have no idea what anyone's talking about. Yes, UML & RUP were terrible. But at least we were trying to bring order to chaos. With agile, it feels like we forfeited, that we should just accept the chaos.
Re: Scrum disempowers developers
#136Re: Scrum disempowers developers
#137Earlier quoted context omitted.
This just trades one non-falsifiable defense for another. First it’s “no true Scrum implementation would have property X.” Now it’s “any observable badness of Scrum was just ambient badness of an already bad company bleeding into Scrum.”
> no true Scrum implementation would have property X. That's not the point. Scrum does not say anything how good your organization is. Scrum won't fix these problems. Thus you can have a great Scrum setup and still fail. Of course you can have bad management and a 'true scrum implementation'. Your mistake is to assume that Scrum fixes all kinds of management practices or that 'true scrum' also means all kinds of othe…
I'm saying adding Scrum to already-bad management practices is like throwing gas on the fire. Scrum doesn't help.
Also, if Scrum is only some kind of special snowflake process that only works when applied in sociologically perfect companies, well then it's useless.
I'd rather use custom, ad hoc, duct-taped together management practices that get the job done even in the midst of bad corporate sociology.
Re: Scrum disempowers developers
#138Earlier quoted context omitted.
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…
I've seen it work to the benefit of everyone before (I'm a developer). It's not a pipe dream.
Re: Scrum disempowers developers
#139"Valve is the other famous poster-child of radical freedom. And just as soon as they release Half Life Episode 3, I'll be happy to take lessons from them on getting software delivered."
Re: Scrum disempowers developers
#140Like 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…
My experience is that a good team does a good job. A bad team doesn’t. I think the focus on methodologies is to get a good result from an uneven team. Companies desperately want to treat programmers like standardized workers that can be mixed and matched as needed. The siren song of the methodology is that maybe it can achieve that goal. I have never seen this work in practice. There are no quick fixes. People can im…
Of course that's your experience. If you judge teams based on outcomes, then you're going to conclude that teams that succeed are good, and teams that don't must be bad. Unfortunately that offers no guidance in how to become a good team. The goal of software management as a practice is to find patterns of positive behavior that make good teams. Agile, in general, is a collection of those patterns.