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?
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.
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.
www.sjbaker.org
That is absolutely required by Agile. Agile demands that if something takes more than one Sprint that you must not do it. Any big architecture problem that takes more than one Sprint cannot be done with Agile.
I am by no means an agile expert or advocate but I'm pretty sure agile doesn't say "No work item that would take longer than one sprint can be worked on", rather I think the idea is that any work item that would take longer than one sprint should be broken down into several smaller and more manageable work items.
I wish I were as sure of anything as some people are of everything
The developers here changed from Scrum to ATDD (Acceptance Test-Driven Development). Throughput it up, quality is up, morale is up...
They also ran a couple of tests, with one group solving problems using Scrum and another using ATDD. ATDD won every time (although in some cases just barely).
Just sayin'