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)
"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."
This really sums up my experience with scrum meetings..
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.
The biggest problem is that many larger corporations have trouble implementing true agile development. It isn't because IT doesn't want to do it.....it's business partners or management or accounting or what have you. So in those instances, agile turns into some hybrid of waterfall and SCRUM that isn't as effective as it could be
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.
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.
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.
If i wanted a devotion meeting I'd join alcohoolics anonymous thank you.
yes, this can happen alot, when this happen then the important thing is to have a competent scrum master\project leader who can say no
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.
a dirty snowball of design layers with no overall architecture produced
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 was fired from my last job for taking sixteen days to finish a JIRA issue. I almost got it done and out of QA in time. In our Sprint planning meeting, we scored it as a forty and used twenty as the basis for a Sprint. Even though the issue had to be completed in order to deliver to a customer, the certified scrum master that worked for our board of directors would not allow it to be worked on. He was doing good Agile, but it ended-up killing the company since we lost our biggest customer.
Agile cannot produce good software since by definition you can't do anything that takes longer than a Sprint. And, if it wasn't for the nearly an hour a day we wasted in Scrum, I might have finished it on time. Of course, there were more JIRA issues that would have taken more than one Sprint so I would have probably just failed later due to Agile.
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
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
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'
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 want to also add that even though scrum says that the scrum leader should be rotated, the project manager always tends to insert himself into the scrum leadership role (because, they wouldn't have a role otherwise). So rather than the scrum team being a team of purely developers leading developers, we have the programmers leadership abilities suppressed just so that the project manager can be visible as a leader/
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.
I always enjoyed the conversations
Manager: "honestly, how long will this take"
Dev: "I imagine 2-3 days"
Manager: "WHAT NO WAY, if I could program I could do it in a few hours"
Dev: "Yes, but there are some unknowns I need to research, I said "I imagine", it could be less it could be more"
Manager: ARE YOU FUCKING WITH ME, this scrum thing was meant to get you to work quicker and harder with less bugs, now you are telling me you need 2-3 days for this little feature
Dev: Honest yes, remember you have me doing support, doing those little odd jobs you wanted investigating and mocking out so you could see how it would work as you couldn't picture it till you saw it, then you would know what you didn't want and could think about what you did want
Manager: This just isn't working, it has to be done in less than a day ok?
Dev: Ok, I'll do it in less than a day
Manager: ok
Next day:
Manager: What is this piece of crap code you submitted
Dev: It is the feature you wanted coded in the time you wanted
Manager: But it crashes all the time.
Dev: Yes, you have to use it just right otherwise, there was no time for error checking
Manager: this isn't good enough, you have to fix it
Dev: Ok, but that will be hard, the code is just a single class / function, it is quick and dirty, I had to cut every corner to submit it in the time scale you wanted
Manager: I WANTED? You agreed it would be done in a day
Dev: *sigh* Ok I will do it again.
Submits working code after 5 days
#joys-of-programming
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.
Hmmmm - Project Manager is a very broad and loaded term. Many professional project managers wouldn't consider themselves Scrum masters and vice versa. In particular, the role of a project manager is specifically to push timelines, but in Scrum the role of the Scrum master is to guide the process - timelines are owned by the product owner. The distinction is subtle but important enough that it matters.
Cheap warm bodies off-shore are a reality of business these days. You just cant produce the volume of content that constitutes a modern product without it. This is one of the modern realities that legacy scrum just can't address.
"... always going forward 'cause we cant find reverse! "
Pretty much sounds like my boss. "We can't sit around waiting for it to get to 100% right, get it to 80% and push it and move on to the next thing"
Seems like I never pick the right 80% to do.
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."
For people that do strict Agile that means nothing can be worked on unless you can verify it in the UI.
Now there's some utter bullshit. I've successfully used an agile methodology to deliver a server application that had no UI beyond basic log files and working downstream systems.
For us, it means we can't work on problems that cause bad data that isn't exposed in the UI.
Of course you can. You're inventing weird difficulties without trying to resolve them. Sounds like work avoidance to me.
I could not say it better myself.... being able to correctly express yourself (and timeframes) is the true gist of all these agile develoment models. I often say that there are a thousand ways to say the same thing, and how you say it (notice it is not what you say, since you are delivering the same information) is greatly dependant upon the listener. This is no different. Unfortunately, interpersonal communication is so nuanced that it is so much more than a language barrier, and unfortunately, so many developers around the world are lacking in this skill. If they weren't, many organizations would simply not use them.
Blah Blah Blah.
Functional (run by department heads), matrix (weak matrix, balanced matrix, strong matrix), and projectized.
In weak-matrix organizations, the project manager is often a facilitator. Balanced-matrix departments start defining the project manager's level of authority, giving him the explicit right to requisition resources under the sponsor's authority: your VP of Engineering gives you the authority to requisition 4 engineers for 16 hours per week from the Engineering departments under him, to communicate with other departments to gather requirements and interface with stakeholders, and to spend money within a given budget, all tied to the scope of the project.
The project manager's job still remains the same in all cases: find the most efficient way to plan and execute the project. If he has no power, he has to take it back to department heads and VPs--to the sponsor--to lay out recommendations for action. That includes who to hire, what to buy, how to schedule, and so forth. The decisions are ultimately made by whoever has the vested authority to make them, which may not be the PM.
This should be obvious, considering "push deadlines" is a meaningless phrase essentially expressing "I don't know what I'm talking about".
Support my political activism on Patreon.
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
FTFY.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I don't mind "daily meetings" with people on my own team (2-4 people). We do them, but we don't call them meetings. It's just us sitting and talking.
If the group is larger than that, then there is likely a high noise to signal ratio on them saying anything I would ever need, and it would be more useful to not sit and listen to it because if I ever need the answer, I would likely go to them and ask directly. So overall stuff, like bi-weekly meetings may be useful but anything more common than that is use time wasting.
Our standups take five minutes for a US-local team of nine. Occasionally, a conversation gets started, but usually the interested parties just meet up afterwards. I think your team is sufficiently small that there's not a lot of structure required, which is great, but not every team is so lucky.
.. pa-ra-bo-la, pa-ra-bo-la, 2 pi R, 2 pi R, where's your latus rectum, where's your latus rectum, 2 pi R
Any big architecture problem that takes more than one Sprint cannot be done with Agile. ...
Agile cannot produce good software since by definition you can't do anything that takes longer than a Sprint.
This is untrue. You create epics, which capture your big architectural issues, which lead to a series of stories for implementation over many sprints.
(My caveat about all SW methodologies - any devotion to a doctrine is a heresy. Methodologies are but tools to help organize work, and must be customized to match the environment in which is used. Organizations vary with size, requirements dynamism, team skill level, quality of management support, etc., etc. and no list of manifesto decrees can properly address them in all circumstances.)
Second class citizen of the New Gilded Age
That's a good place to start, and it's a good approach to resolving the problem technically. Scrum seeks to address the social issues of project collaboration. If you understand your problem domain well enough that you can confidently write that unit-test and your colleagues too, and that the other players outside the team have confidence in your ability to do that, then you're right you have no need for Scrum.
"... always going forward 'cause we cant find reverse! "
Waterfall actually works for tasks that are completely defined and which will not have changing requirements. The farther you get from that, the more problems you'll have. Agile does better on changing requirements, but, to be honest, if the requirements change too fast or too much the project's doomed anyway.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes