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?

Comments

Re:Scrum Was Never Alive

[gtall]

I can see where it might be useful in certain situations. However, when it gets used with other Agile fluff to simply produce a dirty snowball of design layers with no overall architecture produced, then it becomes a headless snake. It also tends to get misused by management who see it as a way to micro-manage developers thereby pissing off the very developers upon whom they are depending.

Re:When done properly it is fantastic

[sbaker]

I'm still a fan of scrum. I love that it gives the engineer the final word on schedule. No more "You have three weeks to do X."...now it's "How long will it take?"...and the truly awesome part is that it gives lazy team members no place to hide - and gives the team the incentive to meet the deadlines they imposed upon themselves - or have a damned good reason why they didn't.

I agree - in the last couple of jobs I've had that did scrum well - it really helped. I think it can be adapted to fit individual team's needs - but the huge mistake most people make is to start off by adapting it. My advice - jump in with both feet, use the standard scrum methodology - and after you've been doing it for several sprints, decide where you want to dial it back, amp it up or modify as needed. For example, in my previous job, planning poker worked really well - it was a way for the team to look at stories and say "I think you've missed a shortcut that would save you some time"....or...."I think you're missing a potential problem *here*.". But in my current job, the team is full of specialists in different fields - and that cross-pollination doesn't happen - so planning poker just doesn't work.

The point here is - try the whole thing - THEN customize as needed.