Slashdot Mirror
Slashdot Asks: Is Scrum Still Relevant? (opensource.com)
An anonymous reader writes: In an article titled "Scrum is dead: breaking down the new open development method," Ahmad Nassri writes: "Among the most 'oversold as a cure' methodologies introduced to business development teams today is Scrum, which is one of several agile approaches to software development and introduced as a way to streamline the process. Scrum has become something of an intractable method, complete with its own holy text, the Manifesto for Agile Software Development , and daily devotions (a.k.a., Scrum meetings). Although Scrum may have made more sense when it was being developed in the early '90s, much has changed over the years. Startups and businesses have work forces spread over many countries and time zones, making sharing offices more difficult for employees. As our workforce world evolves, our software development methods should evolve, too." What do you think? Is Scrum still a viable approach to software development, or is it time to make way for a different process?
Scrum works best when you break it and make it yours. As with ANY methodology, do not allow process to interfere with progress.
The biggest problem is that many larger corporations have trouble implementing true agile development. It isn't because IT doesn't want to do it.....it's business partners or management or accounting or what have you. So in those instances, agile turns into some hybrid of waterfall and SCRUM that isn't as effective as it could be
When done right, scrum is fantastic methodology. I know this from my own experience. However, I have not see many teams master it. They usually cut corners, or "adapt" it to their own preconceptions that end up breaking the process. They often don't do the retrospective meeting, or do it improperly so they are not able to get better at it, and get stuck carrying over user stories iteration after iteration.
I don't think scrum and open development have a lot of overlap. They are each suitable for different types of projects. Open development works great for open source projects that a lot of people would have interest on. Scrum works great in small teams developing for particular verticals within a company that would have limited application outside.
Things can always be improved of course, I would not say scrum is the ultimate methodology, but it is a pretty darn good one, and we are yet to see better ones.
Scrum was very useful. It was one of my imbecile tests for a long time. If an American said "scrum" instead of huddle, they were either just parroting what some idiot boss had read in a book or they themselves were the idiot. Americans have no idea what a scrum is unless they were one of the few who played rugby at some point.
The other imbecile test is the use of the word "A3" to describe a summary printed on tabloid-sized paper. Again, we do not have A3 paper in the US, so this was always a good indication that a person is using the word because they have to work under an idiot, or they themselves failed to grasp the lessons in the Toyota book that they read.
Another good one is a whole meeting room filled with sticky notes. Welcome to the 1980s.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
It's sad how quickly the No True Agile fallacy rears its head in any /. thread that points out how fragile and limited the methodology is.
yes, this can happen alot, when this happen then the important thing is to have a competent scrum master\project leader who can say no
Imho, the biggest "flaw" with agile development, is that it is - if not selling itself, seen as by many as - being everything to everyone. You can take a bit of this or leave a bit of that, but this is the right way of doing things. And it all gets wrapped up in terminology (agile, velocity, etc.), that suggest that the process will be faster and better.
But different processes have different strengths and weaknesses. Sometimes it's more important to put in design effort upfront. Sometimes it's most important to make the most efficient use of resources (e.g. not wasting time doing things based on a narrow requirement knowing that you'll need to change it later), sometimes it's important to be able to adapt to changes, and knowingly change requirements based on feedback. Agile methodologies only really address the last one.
The best results will come from understanding what the project needs, and choosing the methodology that best addresses that, not from always trying to fit one methodology to every project.
This is the main reason people hate scrum - the awful boredom and lack of humor in it's promoters. You take a great joke, let it woosh over your head, suck the life out of it and think you''ve added to the debate. Here's a hint - you haven't.
That is all.
I always enjoyed the conversations
Manager: "honestly, how long will this take"
Dev: "I imagine 2-3 days"
Manager: "WHAT NO WAY, if I could program I could do it in a few hours"
Dev: "Yes, but there are some unknowns I need to research, I said "I imagine", it could be less it could be more"
Manager: ARE YOU FUCKING WITH ME, this scrum thing was meant to get you to work quicker and harder with less bugs, now you are telling me you need 2-3 days for this little feature
Dev: Honest yes, remember you have me doing support, doing those little odd jobs you wanted investigating and mocking out so you could see how it would work as you couldn't picture it till you saw it, then you would know what you didn't want and could think about what you did want
Manager: This just isn't working, it has to be done in less than a day ok?
Dev: Ok, I'll do it in less than a day
Manager: ok
Next day:
Manager: What is this piece of crap code you submitted
Dev: It is the feature you wanted coded in the time you wanted
Manager: But it crashes all the time.
Dev: Yes, you have to use it just right otherwise, there was no time for error checking
Manager: this isn't good enough, you have to fix it
Dev: Ok, but that will be hard, the code is just a single class / function, it is quick and dirty, I had to cut every corner to submit it in the time scale you wanted
Manager: I WANTED? You agreed it would be done in a day
Dev: *sigh* Ok I will do it again.
Submits working code after 5 days
#joys-of-programming
That's called a Project Manager, and a decent one is worth having.
You can't beat face to face communication, especially between developers and subject matter experts. The productivity gains and risk reduction far outweigh the cheap-warm-bodies offshore. Design is never efficiently replaced by brute force.
Hmmmm - Project Manager is a very broad and loaded term. Many professional project managers wouldn't consider themselves Scrum masters and vice versa. In particular, the role of a project manager is specifically to push timelines, but in Scrum the role of the Scrum master is to guide the process - timelines are owned by the product owner. The distinction is subtle but important enough that it matters.
Cheap warm bodies off-shore are a reality of business these days. You just cant produce the volume of content that constitutes a modern product without it. This is one of the modern realities that legacy scrum just can't address.
"... always going forward 'cause we cant find reverse! "
Pretty much sounds like my boss. "We can't sit around waiting for it to get to 100% right, get it to 80% and push it and move on to the next thing"
Seems like I never pick the right 80% to do.
It is fragile, and it is limited. That doesn't mean it can't be successfully used to add value.
The issue is people doing it badly then blaming the methodology, not their shite implementation of it. Any fucking methodology is going to collapse when faced with the average programmer - see also: IT project success rates