There is no silver bullet. Never was, never will be.
Scrum disempowers developers
81–90 of 382 posts
Re: Scrum disempowers developers
#82Like 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.
Re: Scrum disempowers developers
#83Earlier quoted context omitted.
You also missed the trade off's for increased speed compared to traditional wf projects. One of the problems with the Scrum model is its used for every thing - just like they used to try and do every project with WF and IS9000/BS5750
Are you suggesting Waterfall projects are faster? I don't think you are, but that's how I read your sentence. Also I don't know what IS9000 or BS5750 are but they sound like they had amazing naming committees.
Oh bum I meant ISO9000 BS5750 is the Uk equivalent (and I worked at my first job on a joint project with the BSI on BS5750)
But and its a big but some times you need the rigor a properly done waterfall process provides Air traffic control for example.
You seriously don't understand the trade offs you make with "agile" vs waterfall? I have done both very successfully.
Re: Scrum disempowers developers
#84I find this article lacking, because it makes all of the same mistakes typical of these bandwagon anti-Scrum articles. Despite working in a a Scrum team, I recognise literally nothing of the problems that are described. Our product owner works closely with both commercial and development groups to build the backlog. Pressure to build good technical solutions is reasonably balanced with commercial requirements. The de…
To hear about better processes, you'd have to time travel back to the 90s, go thru PMI training, work with experienced project managers, earn your sergeant stripes.
Re: Scrum disempowers developers
#85One would expect Scrum to disempower developers. After all, it is a management methodology (yes, I know some will protest at this label), and it emphasizes those things as a result. Any resemblance to software development methodology has long been lost, if it was ever there at all.
That said, an entire industry has emerged to sell this methodology, and it is supporting a vast array of jobs: everything from those selling the certifications, to the software used to track developers. There are too many vested interests now, and no company wants to admit that it burned through thousands of dollars, with dubious results, to "train" managers and subscribe to the usual software bundles.
I expect the comments here will also have the usual comments about how Scrum is great, and everyone who is critical of it is just doing it wrong.
Re: Scrum disempowers developers
#86Earlier quoted context omitted.
The scrum manifesto is not overly verbose. It explains the value and concepts in a manor that does not lend itself to misrepresentation. There is definatly a lot of companies peddling hype around scrum but it has a very lean and strong core which is in no way pulling in that direction.
What's the scrum manifesto?
Paraphrasing: The Agile Methodology is to argue about The Agile Methodology.
Source: Certified Scrum Master training. Three times. Still have no idea what these charlatans are talking about.
Re: Scrum disempowers developers
#87Most of these problems, such as refactoring, lightweight documentation, and tech debt can be mitigated with a good definition of done and a strong understanding of the sprint goal, whatever it may be.
This is a classic "Scrum" v.s. "How We Interpret Scrum" hit piece.
Re: Scrum disempowers developers
#88This sounds not so much like a valid argument and more a thinly veiled tirade against one bad project manager this person has had during their career. Yes, most by-the-book approaches to agile project management are bad because they are by their very nature not pragmatic towards the reality of a given engineering team or product organization. No, that doesn't give you an excuse to claim that the tens of thousands of individuals (more?) who have made a successful career out of project management are all incompetent snake oil salesmen because there happens to be a certification with a low barrier to entry.
Grow up.
Re: Scrum disempowers developers
#89Our 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…
Scrum is antithetical to quality. We're 20 years into this experiment? I have yet to even hear someone tell a compelling narrative about doing QA/test in an "agile" context.
https://continuousdelivery.com/implementing/patterns/ and https://continuousdelivery.com/foundations/test-automation/ would be your starting point there.
Re: Scrum disempowers developers
#90Like 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…
You're describing having a well defined goal, setting a critical path, and then regularly updating your progress. What we gray beards used to call "project management".
But you have to include 'estimates', which ruins everything (in non-trivial cases, yadda, yadda).