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.
... we develop software the old-fashioned way: incremental improvements to an ancient codebase with fundamental flaws in its core that nobody's brave enough to tackle, with irregularly-scheduled releases set into the production server without automated unit testing.
At home I develop in a more refined fashion: diving right in without much prep or research, working on it for weeks to months, then finding that the project is 100 times more complex than I expected and someone else has already done it.
Hello from Sputnik 2. I am receiving you.
https://www.youtube.com/watch?v=oyVksFviJVE
Watched this with my wife, who, while also in tech, never worked at a workplace that used Scrum. She cracked up and thought it was the funniest thing she'd ever seen. I sat next to her, stone-cold silent. She asked why I wasn't laughing, and I said, "Dude, that's MY LIFE." All that's needed to parody Scrum is... an accurate description of Scrum.
Of course, in that episode was that Scrum actually worked for them (it probably helped that all the devs worked in the same office)
Scrum works best when you break it and make it yours. As with ANY methodology, do not allow process to interfere with progress.
While scrum could be effective to prioritize a lot of small tasks that can be complete in a few hours, we found it useless in situation where a long task must be developed. In the later case the peoples try to say the minimum because there are afraid of hitting unexpected difficulties that will slow there work, and scrum is not a place to change the design, so there feel like in a trap.
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
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.
The core principles are fine:
1) Frequent communication means nobody drifts too far out of scope
2) Breaking a large problem into small problems is something you should have learned before you even started university
3) Gives nervous business stakeholders an insight into the development process
But it doesn't work in most settings for these reasons:
A) The broader business doesn't engage (becomes sprints within waterfall)
B) The engineering organisation doesn't engage (usually because they don't feel they own it)
C) It's too complicated - it's the core principles that matter, not rote adherence or form filling
Too many moving parts; too many new concepts; too many new ways of doing things; for too many people; who aren't necessarily interested and/or sufficiently trained and informed.
You CAN make Scrum work - if and only if - everybody gets on board and you take a large hit up front while everybody adjusts to the transition.
Most businesses can't and won't do this.
"... always going forward 'cause we cant find reverse! "
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.
Well I've worked on a lot of successful scrum-based projects (full disclosure: I'm a certified scrum master). Done right it's a very effective and enjoyable way to work. But there are some pre-reqs if you are going to succeed.
If you do it right, then you can be very productive and have fun doing it. Unfortunately, there are a lot people who have made half-assed attempts at "agile" and then rubbished it when their projects failed.
I personally found Scrum and Kanban annoying in this respect:
1: The meeting to tell your "stories" is a time-waster when done more than once a week. Daily, it is pointless.
2: The "what you did" scenario. It becomes listing everything, relevant, or non, so your manager doesn't think you are slacking, and pits you against other developers or IT people.
3: The "what you are going to do today" crap. SSDD is the proper answer for that.
4: The "what is blocking". This translates to "point the finger." As a dev, I learned the hard way that "blocking" means a game of "hot potato" where if you or your code can, in -any- way be used as an excuse for others to not do their work, expect to be training a H-1B fresh off the boat to take your job soon. The "blocking" phase turns into a "The Apprentice" boardroom meeting right before someone gets tossed.
As for code quality, look at the garbage coming out on average. People thought waterfall coding was bad... but code quality when that was the main method was, in general, far better than the Scrum based systems, just because Scrum mainly is used to pit devs against each other, as opposed to actually creating something.
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.
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
Mythical Man Month talked about this. It points out that with a small team, any development methodology can work.
Scrum is fine, but let's not pretend it's some kind of miracle.
"First they came for the slanderers and i said nothing."
Can't resist pointing out that, despite its stated objective,Scrum usually makes things take longer, not shorter. That means working Overtime, known as "OT" . Thus:
ScrOTum
https://app.box.com/WitthoftResume Code: https://github.com/cellocgw