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.
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.
... 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)
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.
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.
those all sound like examples of doing agile wrong -- at some point if it is a big project - it is a big project and you deliver what you can when you can .... so the Architect issue is out the door as totally bad planning... BA always write bad specs this is a thing... and its the developers not the PM fault
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.
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.
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
All engineering is iterative in nature. If Scrum is dead (read as iterative, incremental development), then software engineering is a myth.
In my last job, scrum-master was a task that was rotated through the team. Each sprint, a different team member takes on the responsibility. This gave everyone a better insight on what the job entails. After doing that for six months, it became clear who the right people were for the job - and it rotated around maybe three or four members of the team rather than all of us. New team members usually got handed the job for one sprint after they'd been with us for a couple of sprints.
Paying someone to be scrum-master is only worth-while when that person masters multiple scrums - and goes to scrum-of-scrums...and so forth. For most small teams, you don' t need that as a full-time role.
As for the scrum master "barking orders"...whoever thought that was what you do didn't read the scrum guide! The scrum master is a clerk - a book-keeper - and a keeper-of-rules - a servant of the team - not some kind of manager. If you give the scrum-master managerial power over the team - then you're not doing scrum anymore.
If you don't do scrum by-the-book, don't complain when it doesn't work. You're perfectly entitled to modify the system - but be aware that when you do so, you're not "doing scrum" anymore - you're doing some kind of pseudo-scrum - and when your pseudo-scrum breaks down like this, you have only yourselves to blame.
www.sjbaker.org
I've still been seeing plenty of jobs for scrum masters, etc. When all those companies find out that scrum is dead, what will happen to these people? Meantime, these jobs are choking out other job roles and one has to wonder should I avoid applying for any of these scrum jobs?
"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...
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?
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
Definitely A.
If your testers, upper management, and customers arn't on board, you end up with exactly what you said.
Personally I think scrum works if you arn't religious about it. Take the bits that work, introduce it slowly, don't get hung up on the "proper" way of doing something. As you said, the core principles are sound, and I'll add that a lot of the management tools built around scrum are pretty decent. Building often makes sense, testing incrementally makes sense, letting the customer see things early (usually) makes sense, etc.
A sole developer usually doesn't need team meetings so rules on how to conduct those meetings would be kind of pointless.
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.
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.
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.
CORRECTOMUNDO. Give the man/woman a prize. I've seen scrum implemented to varying degrees in most of the shops I've worked at in the last 15 years and I'm here to tell you that its like working with an albatross hanging from your neck and adds no perceptible value to the process, at least as far as I can tell. In my last position it was implemented fully (at least to my understanding) which was interesting considering I was the only software engineer on staff at the time, but we had 4 full time hardware engineers. The hardware guys ate it up, but I felt like I had a dead weight around my neck. I don't think its applicable to a guy doing architecture AND implementation; I really felt like it was a complete waste of time to me; I kept getting in to arguments with my manager that he wanted finished code when I was still prototyping and designing, It was ridiculous. Scrum in my experience was too rigid and deadline-driven. Thankfully that situation has "evolved" and I no longer answer to that guy, or that process.
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
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
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...
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.
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.
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.
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.