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 wanted to be many things. But, wishes don't always come true. Very few ever cared about Scrum. Scrum was never a "thing", so you can't really call it dead as it was never alive. But, those few that love it are still using it.
Just look at the recent version of the Scrum guide. It changed a lot since the 90 and 00. The only problem is that most people didn't notice.
Every article about "is such and such dead?" Is an empty space filler and typically worthless. People who find value in the supposedly dead thing use it. People who don't, won't. But 25 years after "the death of the fax machine" there are still millions of them toiling away at their task. So skip these articles. Get to things with news that matters for nerds.
Yes
Or mortuaries in general?
... 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.
Agile: Code word for Project Managers don't want to be held accountable for meeting deadlines, Business Analysts don't want to have to write good specs and Architects go nuts trying to build a house room by room without knowing whether they are building a ranch or a tudor.
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)
First thought: what the hell does a Lucas Arts interpreter have to do with s/w development methods?
"I don't know, therefore Aliens" Wafflebox1
We were running a Scrum project to replace a very poorly designed software system. The people running the project were very skilled, and the scrum team came together well. This was a large project, and took time. As people rotated off the project do to various reasons, the replacements were not as excited about the method. Finally, the program manager moved on, and his replacement killed the project. We went back to trying to add features to the previous system. Scrum is a major change in mindset, and often hard to maintain over time.
Scrum works best when you break it and make it yours. As with ANY methodology, do not allow process to interfere with progress.
Let's face it, the Scrum Master is usually a mate of a senior member of staff who needs a job that does fuck all but pays a lot of money.
I was in an interview years back and the company was really proud of the fact that their Scrum Master was an ex-army officer, meaning that he could bark his orders at the developers during the stand up.
$100k? That's more than I get paid. What a joke.
Scrum is still used, people dont understand that scrum is to be adapted to the people/software you are working on, many combine scrum or use just parts of it, I know alot of big companies that use a combination of waterfall and scrum when doing safety critical machinery and there is like here in our company were we use just parts of it, we made it fit how we work and what we are developing.
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.
For those PMs and project owners who like to hear themselves talk. For everyone else it's a complete waste of time. Nothing beats a good requirements specification.
Ya ya.. The daily scrum is for reporting. I've heard it all before. Theory and reality are two very different things. 15 minutes/day turns into an hour/day. Blah blah scrum blah blah.
Using the word "Scrum" in any seriousness is a good example of cargo-cult programming [seriously, we had words for meetings and managers before 'scrum' and 'scrum master' (what a joke of a help-wanted-ad)].
There's dozens of methodologies. Most of which supported by religious adherents, consultants, trainers and "evangelists". My experiences is that they are just like software libraries and frameworks in that there are good parts and bad parts. I try and use the good parts and avoid the bad parts. Architecture frameworks like TOGAF and Zachman are similar. Some is useful, most is the wasted emissions of academic masturbation.
I've seen many organisations who have done so called Scrum implementations, but it is usually the classic (management) way of making a change:
'These are the rules and milestones, start moving along them.'
People who do not understand that Scrum is merely a way to get started, not a strict guideline that you shall follow to the end of time are what giving agile development its bad name. Agile development is all about taking a proactive attitude, to work towards results instead of following the nailed down rules.
It is always great to see managers who grew up with Prince2 and other management techniques 'switch' to scrum. You'll typically see a daily scrum as a moment when all the workers have to account for the hours they spend yesterday, instead of a moment to make sure the team understands the product they are working on, to understand where potential problems exist and to look for a solution.
Feedback is shunned, because that would mean focusing on effectiveness instead of following 'the rules' and spending time with a product owner, let alone an end user is too scary to consider. Besides, Manager knows best, so please keep coding monkeys.
But of course, this is all the fault of the method, time to find another guidebook with more rules please.
"Is Scrum still a viable approach to software development,"
Has Scrum ever been a viable approach to software development?
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.
...No 'methodologies' or models of execution plan in comparison to just doing the job your customers pay you for.
I'm a sole developer on a SaaS product that you'd expect at least 3-5 developers to create. There is no scrum, agile, or whatever other lingo word you wanna call it. I gather requirements, write, debug, ship, and move the eff on because it works. And it works well.
If i wanted a devotion meeting I'd join alcohoolics anonymous thank you.
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.
I am starting to suspect the real problem with all these development methodologies is the fact that it's used by programmers.
What I mean is, when was the last time you read about a new innovative way for engineering firms to design a new bridge or building? Is there some "NIMBLE" methodology for car design? Think anyone has a round of power meetings over a new clamshell packaging system?
So why do developers need a codified methodology, let alone dozens?
We know you don't read TFA anyway. So really, why bother linking to it at all?
(For those of you who "are new here" and actually want to read it, the article is available here on OpenSource.com
WE use these at work. They can be useful. We do all work internally. Some projects are larger and it can be a good way to force teams to communicate on daily tasks. Small teams located in a cube though .... it's somewhat pointless.
To be frank, there are usually bigger problems that need to be tackled. I have to deal with. Oh, here is a new project. You are the lead. And you have 2 people under you starting now. And we are giving you two projects starting at the same time with the same setup.
.
Scrum encouraged the development of disposable software because the lifetime of software developed via Scrum was always short. Scrum did not encourage development of longer-life software.
All of these methods are great for keeping communication going and organization happening. Those quick meetings every morning in SCRUM are fantastic to keep everyone on target, up to date and active on their projects. SCRUM was one of the bets ways to identify problems. I'm not saying everything else about it was great, but it sure helps.
Those of you who develop outside of any established practices are probably far less efficient than you could be and often one of the problems with development.
All engineering is iterative in nature. If Scrum is dead (read as iterative, incremental development), then software engineering is a myth.
"What do you think? Is Scrum still a viable approach to software development, or is it time to make way for a different process?"
NO.
It's definitely time to come up with a new, trendy name that hides the fact that most programming is, in fact, a solitary sport, even if done by teams of coders all stuffed into a common room.
I propose "SUCK", "BALLDROP", "HOPELESS", and "VOID" because none of them stand for anything and they all sound cool when uttered in between slurps of brogrammer's favorite energy drinks.
Just cruising through this digital world at 33 1/3 rpm...
There were many before in the industry, and there will be many after. Their common feature will always be the same: if it doesn't work for you, you are doing it wrong.
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.
We're using Scrum. One of the many variants of it.
A simplified version of scrum suitable for agency work.
Simply getting around a board, away from the keyboard, standing, talking (timeboxed) writing cards and moving them around makes things better and enhances team communication and interaction.
That the overblown hype and overengineering and the holy wars about how scrum is to be done is over is a very good thing.
Hype ends, Scrum remains.
I think it's a very good think that this was a big fasionable thing and that Agile (sometimes contradictory to Scrum btw.) brought back the focus on results and regular customer interaction.
We suffer more in our imagination than in reality. - Seneca
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! "
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'
Today's market demands software developed at internet speeds, and Scrum is the magic silver bullet that delivers. Based on interchangeable faceless engineers performing at consistent top velocity and colourful, simplistic graphics that even a top manager can understand at a single glance, new web pages can be delivered at web scale in little to no time with a minimal commitment.
Of course, the elephant in the room is that 80% of all software development is maintenance (remember, every line of code typed by a trained monkey enters maintenance immediately). Also, a web page or other UI veneer is only the top of the iceberg of software development and accounts for maybe 1% of software.
So, while Scrum and other rigid Agile product are great for a lot of managers to grasp because of the slick webinar presentations so readily available while playing that red jack on the black queen, the reality is they don't really deliver. Turns out there is no easy substitute for good planning and effective management for any task of more than basic complexity.
Union or League?
Scrum fosters a competitive environment complete with a scorecard of who is completing the most tasks. This is a great environment if you are looking to get a promotion but your organization can suffer when too few points are assigned to critical tasks. It really sucks to see a well thought out design deteriorate over time as quick and dirty changes are made to it repeatedly.
I've been at two companies in the last six years that are trying to implement Scrum. The first failed miserably, due to massive management interference. The second is in progress now, and seems destined to fail (although I certainly hope not!). This company promotes hyper-active micro-managers, who operate in a mode that is the antithesis of Scrum.
In both these cases, I see the biggest benefit of scrum is that it would prevent the micro-managers from interfering with development that is in-progress, and force them to plan the work in advance, rather than running around co-opting already-busy resources for their latest 'emergency', thereby forcing task switches (expensive) and collateral damage (frustration) to whatever project was last week's emergency.
It's occurred to me over time that Scrum is a way to box out Panic Management from the development process. I just wish I had the experience of actually seeing it work. But hope is eternal...
- The Kessel run is for nerf herders. I can circumnavigate the entire Central Finite Curve in a lot less than 12 parse
The dude is a nobody - with a managed social profile, stays at a job for 2 years and boom
As our workforce world evolves, our software development methods should evolve, too
Well, there's your problem. The workforce world isn't evolving. It's failing at adapting to new software development methods.
Maybe new software development methods would be better served adapting to the workforce world, instead of trying to drive change.
Scrum and Agile development in general, this whole concept of not starting with well defined requirements and building the plane while you're flying it, is rubbish and can't die soon enough.
And we've become all about Scrum over the past year or so. (Except the portions of it management and the Scrum master would rather not deal with because we "work in the real world.") Take that as you will.
.
TFA doesn't seem to have anything to do with Scrum, except to say that they don't like it, and are proposing a working group be gathered from Open Source developers to come up with something to replace it. I've never been at a company that actually "does" scrum, they all just use Scrum, and Kanban and Toyota Lean, and Continuous Deployment and 100 other buzzwords in various combinations. Rallying against Scrum is like complaining about companies using YAML instead of JSON in their config files for their Enterprise CRM system. It's missing the whole point, and nitpicking at what's probably the least important part of the whole process.
Once anything as trivial as a type of meeting or process gets hyped to the point of being capitalized as a proper noun, it's screwed.
No matter how well intended and thought out the underlying principle, once it gets 'adopted' it will bear no resemblance to the vision that it was created with.
If something is more concrete, specific, and is in no way able to be 'interpreted', it has a chance, but words like Scrum, Agile, Epics, et al are screwed.
XML is like violence. If it doesn't solve the problem, use more.
>What do you think? Is Scrum still a viable approach to software development, or is it time to make way for a different process?
Absolutely. Scrum has outlived its usefulness as a technology or methodology for solving the problem of the high cost of successful software projects. Like structured programming, object oriented programming, extreme programming, etc., Scrum also fails to enable clueless managers to use clueless, unskilled developers living in third world conditions making subsistence wages to successfully complete large, complex software projects.
Let's all waste millions of more dollars getting new certifications and learning yet another idiotic framework for managing software projects.
Here's a hint: the much-hated waterfall model works beautifully if you have the right people. For that matter, almost any sane management methodology and almost any sane technology stack will allow a software project to succeed if you have the right people. The only problem is that, in general, you'll have to pay a good wage to attract and retain those people.
Meanwhile, let's get ready to re-learn (in new packaging) concepts that were probably discovered 50 years ago.
Scrum is used all over the place and where it is used it tends to work fairly well - assuming its used in moderation. The problems for scrum is there are a lot of bullshit, harebrained concepts & jargon which heap process upon process and make the whole thing a pain in the ass - e.g. social contracts, waste snakes etc. Keep it simple and it's quite tolerable and productive.
Different groups work in different ways.
My last SCRUM based dev-group was awesome.
A quick stand about at my desk with my colleagues, just spout what you did, did you fix it, what are you plans. Next person.
It allowed us to share any troubles, present suggestions and overall know where everyone is at with things.
My Current group is tried so close together, it's as if we're in a meeting 24/7.
If somethings weird, or you fixed something. Just say it aloud. It just works for us.
Ex. "Well that was F**k up, someone from '94 just put a goto in the middle of an if statement and it was to the next line."
Every time I've seen something like this, it just gets infected by micro managers and ruined. Last attempt with Agile had us using the JIRA Tempo plugin ( http://tempo.io/products/tempo-timesheets/ ) to track by the minute every single thing an employee does so micro managers could be certain 40 hours a week were in there. Our manger wasn't a micro manager, but the others forced the entire department to use it. He was nice enough to say "Just put 40 hours of any crap in there and I'll approve it" but, in the end, it just soured everyone on Agile.
every time i read scrum, my mind automatically inserts the 'ot' in the correct place.
because scrum is balls.
Zappos is correct in getting rid of all the people managers and truly on the edge of how software needs to be developed in the future. Artifical creation of "Teams" does not work in fast moving software environments. Itt worked when software evolution was siloed and slow but fails in real time development that needs fast hitting swat teams. All the team members have to be competent in the stack and be able to step in when needed to pick up slack. I am tired of the not my job slackers, in other works I don't know what to do crew.
Read my title. Says it all.
You want process in software development, you start with industry standard, and that's still Scrum. Unless your project only has 10x programmers (who will get a sprint's worth of features done in a day no matter what). For those types, the better process will always be no process at all. That's the magic behind the genius: nobody understands it, it Just Works. And so does Scrum for the rest of the world.
And the article on the Open Development Method didn't really provide any evidence that it was. I don't think the guy really gets Agile or SCRUM - his whole article was on code quality, test driven development, etc. Those things are complimentary to SCRUM and Agile development. High quality code, limiting technical deficits, is always a goal, and the short sprints, the inspection and adaption of SCRUM, make it easier to produce better code.
We moved from waterfall development, to semi-scrum, to orthodox scrum, and it's been really beneficial. No more long meetings over a week to review requirements, most of which changed, or the feature got dropped. We plan a week's worth of work, and when we start to run out of work, we plan another. Small pieces of work, with short cycles, and lots of communication between the product owner (in our case, Product Management), developers, and testers.
It's made work a lot less boring.
Really when you get down to it it's about 4 things Talking- nobody can go weeks out of communication Trusting - you have to trust that your teammates arnt idiots Respect- don't waste others time or resources Reflect - yes you need to go over what happened and what went wrong and right What I find is agile is some times go fast and stupid and breaks the above ideas but the name agile makes it sound like the point is speed when it's a side effect
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
Where did this article even talk about Scrum? All I saw were a couple of comments about how it's hard to have daily stand-ups when teams aren't co-located.
If my post were a car, this sig would be its bumper-sticker.
Scrum is a fantastic methodology, and you should get behind it if your company adopts it. The sooner you adopt it, the sooner people will start cutting corners and throwing away all the worthless aspects of it (e.g., most of it), so you can focus on getting real work done.
The core idea (break things down so they can be accurately estimated) is a great idea. The rest is crap.
HA! I just wasted some of your bandwidth with a frivolous sig!
I was a dev in a firm that pledged to do things agile/scrum way. However, nobody knew how to do it in the "text book" sense. As you can imagine, it went horribly wrong, especially for large web projects. Same firm, then tried waterfall, similar disaster.
So I conclude, workflow doesn't really matter. If the team you are working is not properly functioning as a team, likely no workflow can help you.
What I call a properly functioning team is a team with members who has a common goal, willing to sacrifice and work hard to achieve it, and willing to help other team members. Unfortunately, most organizations are driven by appraisal systems, which by design down play team work.
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
And it cannot be morally rotten leaders who want to burn people out on their quick-and-dirty stupidness. Then say they "need to improve efficiency" or something shitty equivalent.
The agile thing is just the latest Hamster Wheel incarnation.
Basically I noted that a single type of person loved, as in passionately, absolutely loved SCRUM. This was someone who usually had some certifications or something extra on their degree such as an Masters in CS. These people had supplanted certifications and procedures for productivity. They would look upon ever growing spreadsheets and mounds of reports as equal or even more important to actually delivering a product. And delivering a great product wasn't even on their radar. They would use words like "Greatness" or whatever but they would also then point to some awkward technology or procedure and use undefended terms like best of breed.
Also I found that SCRUM was used as a leveller and credit taker. I watched many projects where there was clearly a single or small number of programmers who could produce a solid highly functional product on time. Usually they had an awesome track record until some SCRUM master would impose their process on an already working team. This way they could report how the project was going to higher ups and take pretty much 100% of the credit.
Seeing that I have seen SCRUM drive away the best programmers on many teams SCRUM could also then be used as a tool to redefine success. Instead of delivering a product of much value they would deliver beautiful reports and make it look like their efforts were heroic to get the product done. So when the product was a huge lump of crap it was despite their best efforts, and certainly not because.
There is only one place for SCRUM and that is in a highly boring development environment where the product is not measured by its actual value but by how well it meets the contracted requirements. SCRUM will make all kinds of claims to being able to pivot on client requirements but the reality is that about the only thing it can pivot on is if the salesman manages to convince the client to change the contract to include more money.
So as someone with well over 20 years of development experience where would I recommend that SCRUM be used? I would only use it in a large corporation where there was a department that I wanted to shut down and be able to lay off all the most useless managers and boneheaded programmers from that and other departments. Then I would use SCRUM as bait to lure them all to their career deaths. I would also insist that two join that department that you have at least two "industry recognized" certifications; preferably in something obsolete such as Novell.
Process is never an issue, people implementing the process are. Also talks a lot about an industry where incompetent fools who take sadistic pleasure in a process abound. Good software, irrespective of the process used, has been developed before agile, and shall continue to be developed long after agile is six feet deep in the ground. The moment you can understand the concept of using the right tool for the job, these debates become meaningless, and you focus on building long lasting and correct software.
It doesn't matter what kind of methodology you use. It all comes down to people. If you have skilled developers and skilled management and skilled testers then you will be successful. If one of those three are missing you will be less successful. If all three are missing...God help you :-)
The mistake that some managers make is adopting a methodology (be it scrum or what have you) and seeing it as some sort of magic potion. There is no magic potion.
I have been a developer for many years and now I am managing a team of developers. One of the things I learned over the years is that developers are a different breed. They generally don't respond well to micro management. Some people view scrum as exactly that. I try to keep things simple. I give them a task and let them accomplish it as they see fit - enforcing standards but not stifling their creativity. My goal is to filter the corporate BS so that they can focus on what they do best - coding. My focus is on quality rather than quantity because if they rush the job to meet some arbitrary deadline it will take more time in the long run due to bug fixes.
I have no idea who this Ahmad Nassri is, but what's he trying to sell?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Problems arise when for instance, you have a developer that has spent the last 20 years specializing in low level optimization and then ask him to fix some python scripts for you. I don't believe you can be a low level expert and also have had the time to learn a bunch of high level scripting stuff, even if it interested you, which it probably wouldn't. You may *think* you can master both, but you cant...
It works on the assumption that scrum ever was relevant.
Democracy doesn't work. Let's stop using it. But what is better?
I've been joining teams for the past couple years providing Scrum coaching and technical leadership as appropriate, as it happens to a wide array of the blue chips in Australia. Dysfunction under any methodology is still dysfunction, and I've seen Scrum completely dysfunctional, and chaos surprisingly effective. It's important to distinguish Scrum from Agile: Agile in short is about feedback, with the primary purpose of surfacing problems early; there is no standup in Agile. Scrum on the other hand centers on a strongly-defined definition of done, and how to get there. I realize the standup may smell like micro-management and I've seen it terribly misused. The actual point of standup isn't the ritual; it's the preparation. When you know you have to have a standup, you quickly realize that any impediments should be addressed now, not tomorrow at 10. If a standup takes more than 3.5 minutes you're seriously doing it wrong. It's similar to code reviews, which are a pillar of DOD: the code review doesn't improve your work, it's the mental process of preparing for a code review which achieves that. The one thing that Scrum and Agile have in strong alignment is the concept of the value proposition: delivered (done) software is the only measure of where the team is.
There is a strong sentiment commonly voiced around larger units of work which may not fit within a sprint. (Incidentally, I hate the two-week sprint: It's too short to get to Done. Depending on the team, three or four weeks works better.) A pillar of Scrum is about the "potentially shippable unit of work" which in most cases is very effective. In all seriousness, if you deliver a sedan to the customer on schedule this quarter and upgrade it with a performance package again on schedule next quarter, but don't quite get to the chrome finishings, everybody's happy. But if you try to schedule a Ferrari in six months and it won't start, and it takes a year to wind up delivering a sedan, nobody's happy. Scrum is about keeping the software in a continuously shippable state, and that concept is here to stay.
That's the one lesson the software industry refuses to learn, poor managers can screw up ANY process
In 16 years of working as a developer for more companies than I can count now, I have never been in a team that used Scrum until my current job. Also the first to use Agile in their process. I've been in small teams and large teams alike, and never had a need for it to meet deadlines. These guys live and breath and bleed agile and scrum. And the original author up above used some words that I think apply. It's a religion to some people. And it gets in the way of following the ideas behind it. Really, Scrum is about communication. Bringing the team together for a quick, "here's what's up" from everyone. That can be really useful. As for sprints, they have been an utter disaster from my point of view. And that may be because management wants everything in the next sprint, but I also notice that the focus becomes the sprint rather than the development itself. It adds what I'm going to call, for lack of a better word, a distraction layer.
I had come back from the eye doctor and my vision was "off". As I passed a library of Agile books, I read: "Master the Scrotum."
So now, I giggle when my calendar reminds me that it's "Scrotum" time.
Winston Churchill said of democracy, that it is the worst form of government, except for all the others.
I'd say the same about Scrum: It's the worst form of project management, except for all the others.
In my experience, people who don't like Scrum or its variants, generally don't like it because it forces everybody to recognize the truth about the cost of software development. It's an open book, compared to all the others, and that makes life uncomfortable for those who want to hide their overly-optimistic estimates in huge, waterfall-type plans.
If you don't unit test agile methods won't work.
Thou shall not keep standing accross timezones.
Scrum calls itself agile but when we started using it our average response time to scope changes went from 5 minutes to half a sprint. There's nothing agile about Scrum unless you're a planet trying to change course. However, it does introduce some concepts that are very valuable, most notably the concepts of velocity, story points and poker planning. After years of doing scrum we've now left it behind and starting doing plain Kanban but left these concepts in place. Couldn't be happier; unlike scrum, which imposes artificial deadlines, kanban - which basically comes down to "do stuff in a certain order" is as natural as it gets.
0x or or snor perron?!
At the University of Pretoria we had two teams develop the same project - the one using a waterfall based development method and the other using Scrum as an agile development process. The project was to add client based secure group chat functionality to the Linphone chat application without making any changes to the server -- i.e. the server did not have any group chat functionality itself. The result was interesting. The waterfall team committed more thought into the software architecture and came up with a distributed architecture without a single point of failure - even if the group creator./owner went off-line, the remaining group members could still continue with the group chat. In the Scrum based project all communication for a group went via the group owner node and hence there was a single point of failure. On the other hand, the Scrum based project came up with a more intuitive and more usable user interface for the application, most probably due to the short client feedback cycles.
Scrum is the worst implementation of any software development process and it is inherently non-agile. Scrum generates so much overhead that it becomes necessary to hire people (Scrum master) just to handle the administrative overhead. Even worse is the artificial time boxing into 2-4 week sprints. After that time work might be deliverable, but it does not generate value. What good does a database schema do without a UI and business logic to go with it? Or an UI that is nothing else than a Potempkin village? What really puts the vinegar icing on one the anchovy cake is the retrospective. I was in plenty where the scrum master asked me how I feel about how things are. We spend hours discussing how we felt, listed tasks, and none of those got done. In fact, the time we spent talking about stuff we could have used fixing the obvious issues. We also spent excessive amounts of time splitting up tasks to small chunks that could be completed on their own. Scrum adds way too much process that yields absolutely no value claiming to reduce process. There are also way too many useless documents while claiming to reduce documentation. And the short sprints are nothing else than mini waterfalls. Scrum and Agile in general give the false impression as that the same work can now magically be done in less time. If there needs to be an Agile process with a name go for Kanban. It focuses on delivering value and quality quickly.
I am amazed at the complete lack of informed commentary. Some very large percentage of posts here are opinions without basic facts. Given the lack of understanding of how to operate a REALLY BASIC FRAMEWORK, I have serious concerns about the level of understanding here of COMPLEX things like Code, languages, architecture, craft, TDD, BDD, CI Dev Ops etc. etc. Then again, if people really understand these COMPLEX things really well, then they would find the question silly and irrelevant.
Do yourself (not me) a favor, and read an article based on research, like the one below. Its not about Scrum, however good Scrum operates using these ideas.
https://hbr.org/2008/02/why-some-teams-succeed-and-so-1.html
Saying Scrum is irrelevant (or dead) is like saying teams and teamwork are irrelevant.