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

Scrum disempowers developers

lambdacambridge.com

Post reply on HN
Print view View original

171–180 of 382 posts

Re: Scrum disempowers developers

#171

Post by nickelcitymario »

dvfjsdhgfv wrote: post #82
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…

> 2. It's important to stop what you're doing on a regular basis to evaluate progress and problems. This always seems like a waste in the moment, but failure to do so leads to regret down the line. This point is of general usefulness and applies to many areas of our lives, not just software development.

Preach

Re: Scrum disempowers developers

#172

Post by pigleg »

I wouldn't fault it for lack of technical craft, that's not a specific statement in the original manifesto, except loosely maybe "working software". Largely forgotten now since more than a decade has passed, but even the poor implementation of Scrum has helped shut down the RUP hyper-documentation madness, massive unshippable releases with hundreds of bugs, etc.

When trying to explain "Why agile?" to new devs out of school, I struggle "Well... it helps to have been through a soul crushing waterfall deathmarch. If you read the manifesto after that, you will start to weep for joy." But they don't really get it.

So i could argue that even when badly done Scrum has improved the success rate and business satisfaction across the industry. Every couple of weeks the business gets some new functionality and the devs get feedback. Great! But I would agree, it's been long enough with Scrum, I'm ready for the next evolution in this story.

Much of it does also depend on the type of team, product, environment so that scrumbut customization seems nearly inevitable in my view.

Agree we need a way around the short-sighted prioritization, we've overlain some classical PM roadmap concepts to make sure we also chip away at longer term initiatives and debt.

Re: Scrum disempowers developers

#173

Post by emodendroket »

tootie wrote: post #58

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

When every single failure of a methodology is explained away with "you aren't doing it right," I begin to question the methodology itself.

Re: Scrum disempowers developers

#174

Post by tonyarkles »

vannevar wrote: post #140
mmusson wrote: post #74

Earlier quoted context omitted.

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…

My experience is that a good team does a good job. A bad team doesn’t. 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. Ag…

I accept that he's polarizing to some, but Jocko Willinck's book "Extreme Ownership" has some interesting stories on this topic. One of them is at Navy Seal training camp, where there's 6 teams involved in a multi-stage boat race exercise. Half-way through, team 2 is destroying everyone and team 6 is losing pretty badly. So, to teach a leadership lesson, the instructors decide to switch the leaders from teams 2 and 6.

At the start, team 2 continues doing awesome, and while team 6 doesn't win, they improve. Next round Team 2 isn't doing quite as well, but still good. Team 6 has improved a bunch. After a couple of rounds, team 2 is falling apart and team 6 is now winning (or 2nd place, I forget).

My experience, admittedly anecdata, is that great teams perform well when they're in an environment where they're allowed to succeed. I've worked with great teams who did terrible work, and it was pretty much always due to a bad environment (e.g. an owner who would redirect their efforts every few days, so no feature ever got to done-done). I've also seen (but not personally led) teams that I had originally somewhat written off, who under good leadership managed to do some pretty damned impressive work.

And don't get me wrong, I'm not devaluing the potential contribution from a single amazing person, or a team full of amazing people. My clients hire me because I have a (locally) rare set of skills that their team doesn't have, and help them get over hurdles that their team can't (currently) tackle on their own. But if you take a great set of individuals and put them together in a shitty environment with a shitty leader, you're going to get what you get.

Re: Scrum disempowers developers

#175

Post by GFischer »

PeterisP wrote: post #158
vannevar wrote: post #140

Earlier quoted context omitted.

My experience is that a good team does a good job. A bad team doesn’t. 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. Ag…

The observation is more about people. You take random people from good teams, mix em up and put them in a very different environment, they're still going to do a good job. What if there is no reasonable and reliable way to become a good team, and the only way to go from a bad team to a good team is to replace most of the team?

Look at sports... I've seen both cases, players that are good within one system horribly underperforming in others, and players that don't look that great meshing with other castouts and creating a surprisingly good team.

I suspect the same can happen with software developers.

Of course, there are people that will be bad anywhere and top guys that will be great anywhere.

Re: Scrum disempowers developers

#176

Post by tonyarkles »

PeterisP wrote: post #158
vannevar wrote: post #140

Earlier quoted context omitted.

My experience is that a good team does a good job. A bad team doesn’t. 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. Ag…

The observation is more about people. You take random people from good teams, mix em up and put them in a very different environment, they're still going to do a good job. What if there is no reasonable and reliable way to become a good team, and the only way to go from a bad team to a good team is to replace most of the team?

I wrote more in my sibling comment. I generally agree that there aren't any strict guidelines for becoming a good team, but I disagree that replacing most of the team is the solution in any but the most extreme cases. I would venture a guess that, most of the time, there's one person to remove and one person to add: a new leader. If that doesn't solve the problem, potentially looking at developer contributions and seeing if there's someone who isn't pulling their weight and has no interest in learning how to. (I've only encountered these types of people a handful of times in my career. Most of the time it was shoddy leadership)

Re: Scrum disempowers developers

#177

Post by jon-wood »

dagw wrote: post #164
kevstev wrote: post #148

Earlier quoted context omitted.

My quip on scrum/agile is that it "ensures mediocre results from mediocre teams." Its just a methodology in the end. It can help keep those that tend to have wandering minds focused, but for high performing teams the overhead slows them down. The assumption of a standard programmer is just never a reality as well. I actually saw a startup try to go full religious agile and only hire "full stack" developers to try to…

My quip on scrum/agile is that it "ensures mediocre results from mediocre teams." And honestly that is all that most companies actually want/need. Most teams are mediocre and most projects only need a mediocre result. Getting something as good as a mediocre results out of your mediocre teams would be a massive improvement for a lot of place.

I would rephrase it from "mediocre results" to "good enough results" - not everything needs to be a work of art. Especially in the startup world, where there's never enough people to go round, there's a huge value in knowing when you've done enough that the project you're working on is no longer the thing that'll deliver the most value.

What agile does when executed right is to fully embrace that, and wrap it in a process that ensures that when you reach that point you're able to finish the current iteration, ship what you've got, and move on leaving things in a good enough state. For me that's the core of agile, and in my experience at least you can't pull that off with a mediocre team. You need a team where at least some members have the experience and the pragmatism to know the difference between delivering a minimum viable product and cutting corners in a way that'll hurt in the future.

Re: Scrum disempowers developers

#178

Post by peder »

nwhatt wrote: post #99
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…

Great job distilling the essence of scrum into three bullet points, I wouldn't disagree with those. Here's the common pitfalls as I see them: 1. Sprints offer flexibility but unless you educate the whole company waterfall + gantt charts are what the business side wants 2. Unless you educate all members of a scrum team on what the retrospective is, and let the developers drive it, you won't be effectively improving pr…

That last point is simply working software _over_ documentation, meaning that in a world of finite resources what would you rather have? A pile of requirements and technical design docs _or_ a working product? All teams need to determine the right amount of documentation that maximizes total output of working software, but agility was--in part--a response to analysis paralysis and high overhead of many software implementations of the time.

Re: Scrum disempowers developers

#179

Post by jon-wood »

Retric wrote: post #169
vannevar wrote: post #166

Earlier quoted context omitted.

How do you know they are coming from "good" teams? And if so, isn't it reasonable to suppose that they might carry over good practices in their new environment? I don't doubt that there are bad developers---I've definitely encountered them. But software development is a team sport, and it makes no more sense to just "recruit good people and leave them alone" in software than it would to do the same in basketball. Gre…

Because people regularly do "recruit good people and leave them alone". At my first job I was the only developer working on the project and I rarely spoke with my boss. He came back from a month long vacation and I had not noticed he was gone. That's surprisingly common across the field. Most developers work on small teams doing small but often very long lived projects. Code staying in production for 30 years is surp…

Those people, in those positions, probably don't need much in the way of process. If you really can just sit down with the owner of the business, hash things out with them, and then go build something that does what they need then you're golden. And guess what, you're probably doing agile without even knowing it, because agile is attempting to reproduce that in organisations where you can't just put a single developer and a the CEO in a room and expect that to happen.

Re: Scrum disempowers developers

#180

Post by nickelcitymario »

zwily wrote: post #114
HolyHaddock wrote: post #80

Earlier quoted context omitted.

What's the scrum manifesto?

Maybe they meant the Agile Manifesto? It’s short and hopefully not controversial: http://agilemanifesto.org

But... my eyes. They burn. Thank heavens for developer tools and the ability to delete backgrounds.

Jokes aside, good call linking that. Super short, super influential, super relevant to the conversation at hand.

Post reply on HN