|
https://twitter.com/earth__dweller/status/1218797043763728384
|
#
?
Jan 24, 2020 06:57
|
|
|
|
| # ? Jun 6, 2024 02:00 |
|
|
If you make a list of stories to complete within a sprint then it's a deadline. If you don't then you've given a nonsense name to some number of days.
|
|
#
?
Jan 24, 2020 07:38
|
|
|
Scrum, as sold, is a religion more fragmentary and prone to splinter cults than any actual religion. Everyone uses the holy words 'points' and 'standup' and 'sprint' and hopes for the rebirth of their deity Success. When the goats and black cloaks come out, you know you've moved on into 'Scaled' territory. Like the company I'm currently waiting out my notice period has. Ten straight hours of a 'Big Room' meeting yesterday with around 125-150 people representing the business, marketing, support, and twelve different product teams, most of whom have no dependencies or overlaps. It was amazing.
|
|
#
?
Jan 24, 2020 08:45
|
|
|
Our agile method is our manager telling is to work on this new request he got, and the new work is highest priority. Loop repeat.
|
|
#
?
Jan 24, 2020 10:03
|
|
|
I agree with pokeyman, sprints are just a way to make artificial deadlines for the IT people to put them under more pressure. Personally I prefer Kanban a lot, because it has much less overhead: - having to split every task into parts small enough that they can be completed in a sprint is overhead - having to estimate the story point complexity of every task is overhead (thinking about complexity is good, but not if enforced for every single task and not if it leads to administration) - discussions like "well, this story was not done in sprint 3, we have to move it to sprint 4" are just overhead - changing your way of working only because it makes it easier to report to management is ridiculous and overhead
|
|
#
?
Jan 24, 2020 10:13
|
|
|
Scrum is the compromise you resort to when you don't have the autonomy to do something sane instead.
|
|
#
?
Jan 24, 2020 10:14
|
|
|
We are gearing up to deploy (inexpensive) hardware items to dozens of end-users around the world. The hardware items have to have our software loaded on to them. This can be done by anyone with the right knowledge and hardware, but the hardware vendor offers a service where the hardware comes with the software already loaded, if you submit it to them and specify the ID of the software to be loaded when you order the item. We prepare the software and request that our counterparts (in office in another country) who deal with customers order one or two hardware items, to be sent to customers that they have a close relationship with for trialling. We specify that they must quote a certain software ID to be loaded on to the hardware when it's ordered. Manager guy at the office in the other country goes IT'S READY ORDER ALL THE ITEMS NOW NOW NOW, directs his people to order several dozen (split between his office and another office, in a 3rd country halfway around the world from both of us). Doesn't make sure they specify the software ID to be loaded. Now they have loads of these boxes and someone in each location is going to have to spend hours and hours loading the software on to them. Nobody at either location is employed in a technical role. None of this work even needed to be done because we have an existing business arrangement with someone who's been supplying these boxes to us, kitted out with working software, for years. The higher-ups at the other office wanted us to cut the existing supplier out and do it in-house in the name of cutting costs, even though we prepared a summary of why we believed that the existing arrangement was reasonable value for money and explained that we thought the dev time was better spent elsewhere. (I can laugh about it because I'm not directly involved with this situation, I just hear about it from co-workers)
|
|
#
?
Jan 24, 2020 10:41
|
|
|
Walh Hara posted:I agree with pokeyman, sprints are just a way to make artificial deadlines for the IT people to put them under more pressure. Kanban is awesome but it requires a degree of maturity in supporting processes that a lot of organizations don't have. Going to production once a month is a harrowing, nightmarish experience in red tape and regressions due to poor automation of testing and deployment. The idea of "it goes to prod when it's done, whenever that is" is just not feasible for these orgs.
|
|
#
?
Jan 24, 2020 14:56
|
|
|
Bongo Bill posted:Scrum is the compromise you resort to when you don't have the autonomy to do something sane instead. The big pluses of implementing them are consistent and predictable workload for developers (aka work sane hours/schedule how you spend your time better), product getting "this is a way to get developers to evaluate the rough time it will take to do the stories related to this feature so we can figure out how many features make it into a sprint, cut requirements, split it into two releases, or know which release it could feasibly be in", and management of developers getting "this is a way for us to predict the rough output of our team in a given sprint and for me to assign appropriate workloads to individuals, see how a junior developer matures over time, etc." The point of these systems is to create an iterative process that fosters communication between teams, gives a rough roadmap to everyone relevant in the company, and allows you to modify that roadmap if things don't go as planned. The point isn't "each developer's peak output is 13 points per week and we'll now require that". yes I've had largely positive experiences with agile/scrum/kanban, but it's not because the systems are amazing it's more that people employed techniques from them that solved actual business problems we were having in a way that was appropriate for the company.
|
|
#
?
Jan 24, 2020 15:11
|
|
|
Most of these systems seem to require everyone involved to be good and competent. That doesn't seem like a reasonable expectation.
|
|
#
?
Jan 24, 2020 15:54
|
|
|
New Yorp New Yorp posted:Kanban is awesome but it requires a degree of maturity in supporting processes that a lot of organizations don't have. Going to production once a month is a harrowing, nightmarish experience in red tape and regressions due to poor automation of testing and deployment. The idea of "it goes to prod when it's done, whenever that is" is just not feasible for these orgs. To clarify, I was comparing kanban with scrum (i.e. working in sprints with iterative deployments). Both suffer from a low maturity in supporting processes, but I think it's fair to say that scrum suffers even more. I.e. if you can't release every 2 weeks, then you shouldn't be doing 2 week sprints.
|
|
#
?
Jan 24, 2020 16:03
|
|
|
pokeyman posted:If you make a list of stories to complete within a sprint then it's a deadline. If you don't then you've given a nonsense name to some number of days. congratulations on inventing the calendar
|
|
#
?
Jan 24, 2020 17:44
|
|
|
The real coding horror is watching developers call out their dysfunctional workplaces, smdh.Thermopyle posted:Most of these systems seem to require everyone involved to be good and competent. Ding ding ding!
|
|
#
?
Jan 24, 2020 17:50
|
|
|
This is actually a coding nifty. https://twitter.com/arclight/status/1220574099942072320
|
|
#
?
Jan 24, 2020 18:04
|
|
|
Arsenic Lupin posted:This is actually a coding nifty. Very cool historical find. I heard it in the Narrator's voice from the Look Around You videos https://www.youtube.com/watch?v=FBaVwwuErmU
|
|
#
?
Jan 24, 2020 19:13
|
|
|
Hammerite posted:We are gearing up to deploy (inexpensive) hardware items to dozens of end-users around the world. The hardware items have to have our software loaded on to them. This can be done by anyone with the right knowledge and hardware, but the hardware vendor offers a service where the hardware comes with the software already loaded, if you submit it to them and specify the ID of the software to be loaded when you order the item. I had a meeting with a CM-ish company in China about a short run product, like 5k total. 95% of the meeting was specifying exactly which vendor, who was present in the room, to buy SIM900's from. Said it 6 different ways, emphasized that we did not care about cost savings on this particular part, this vendor only, please for the love of god. This vendor. In the room. This person, who's hand you have shaken and have their business card. Buy from them. They have special software preloaded. You have to buy it from them. Guess which part they cheaped out on and got a generic one without the vendor's software? Guess who had to go back to China to re-flash a bunch of SIM900's?
|
|
#
?
Jan 24, 2020 19:36
|
|
|
Thermopyle posted:Most of these systems seem to require everyone involved to be good and competent. Try it, it makes work really enjoyable. 
|
|
#
?
Jan 24, 2020 22:19
|
|
|
Thermopyle posted:Most of these systems seem to require everyone involved to be good and competent. If your people are bad and incompetent, then it doesn't matter what system you use anyway.
|
|
#
?
Jan 25, 2020 05:07
|
|
|
pokeyman posted:If you make a list of stories to complete within a sprint then it's a deadline. If you don't then you've given a nonsense name to some number of days. It's not a deadline because although the goal is that they'll be completed in the sprint, the whole process comes with the understanding that some things probably won't be. That's why you have retros and so on, so you can refine the process as you go. Scrum is definitely not a good fit for everything, though.
|
|
#
?
Jan 25, 2020 08:29
|
|
|
a hot gujju bhabhi posted:It's not a deadline because although the goal is that they'll be completed in the sprint, the whole process comes with the understanding that some things probably won't be. So it's just a meaningless period of time given a name for ... reasons?
|
|
#
?
Jan 25, 2020 11:19
|
|
|
It's "the time until the next meeting." If you don't have the thing done by the time you predicted you would have it done, the issue is the prediction, not that you didn't get it done in time.
|
|
#
?
Jan 25, 2020 15:40
|
|
|
raminasi posted:If your people are bad and incompetent, then it doesn't matter what system you use anyway. For one thing, there's a difference between what you just said and what I just said. Your statement implies that everyone is bad and incompetent, my statement implies that some portion of the people may be bad or incompetent. Systems are often designed to be resilient to failures. Thermopyle fucked around with this message at 17:32 on Jan 25, 2020 |
|
#
?
Jan 25, 2020 17:30
|
|
|
Kilson posted:So it's just a meaningless period of time given a name for ... reasons? The idea is that the estimates improve over time, as well as being able to track what firefighting stuff pops up and delays new features getting done, until the team can fairly accurately estimate "we can get X points of stuff done" and actually deliver X points of stuff. Plus the business gets to prioritize what gets done and what gets done first, so it's theoretically the least-desired things that end up getting pushed in the case of the team not meeting their commitments. I've seen it work, and dysfunctional teams slowly become functional. I've also seen it fail spectacularly, and dysfunctional teams stay dysfunctional, but with added layers of cargo culty ceremony. The best I've seen was a daily stand up meeting that was out of control. For the uninitiated, these are supposed to be 15 minutes tops, everyone just goes and says "here's what I did yesterday, here's what I'm doing today, here's what's blocking me from getting poo poo done". To encourage actually keeping it to 15 minutes, the ideal setup is that everyone actually stands during this. Say what you need to say, any further discussion can take place between just the relevant people, after the meeting. Some teams adjust stand ups so they're longer (there are plenty of totally valid reasons to do so), but usually at that point people are allowed to sit. One team had 2 hour long daily stand ups where standing was enforced. They could have kept it to 15 minutes, but allowed free-wheeling digressions and arguments to so on. It was like torture.
|
|
#
?
Jan 25, 2020 18:23
|
|
|
Kilson posted:So it's just a meaningless period of time given a name for ... reasons? Once the sprint starts, management is supposed to be unable to fiddle with the team's plans, but I bet that's one of the tenets of Scrum that gets thrown out (by management) right away, in most companies.
|
|
#
?
Jan 25, 2020 18:30
|
|
|
New Yorp New Yorp posted:The idea is that the estimates improve over time, as well as being able to track what firefighting stuff pops up and delays new features getting done, until the team can fairly accurately estimate "we can get X points of stuff done" and actually deliver X points of stuff. This sounds, if nothing else, not ADA compliant.
|
|
#
?
Jan 25, 2020 20:02
|
|
|
Absurd Alhazred posted:This sounds, if nothing else, not ADA compliant. I'm not sure that a tech startup in America much cares about that to be honest.
|
|
#
?
Jan 25, 2020 20:40
|
|
|
Absurd Alhazred posted:This sounds, if nothing else, not ADA compliant. An irl version of the "the dumb manager with a giant bladder gets their way in a meeting because they can just wait everyone out" Dilbert cartoon
|
|
#
?
Jan 26, 2020 03:33
|
|
|
Weekly/regular meetings are fine. Thinking about and refining the process is fine. Sprints are dumb. Deadlines don’t work, they make people slack off at first then burn out racing to the finish line. Doesn’t matter if the deadline is in two years or two weeks. Setting a “goal” to accomplish by the end of the “sprint” is a deadline no matter what words you use. People are smart enough to see through the lingo smokescreen.
|
|
#
?
Jan 26, 2020 04:47
|
|
|
pokeyman posted:Weekly/regular meetings are fine. Thinking about and refining the process is fine. Sprints are dumb. Deadlines don’t work, they make people slack off at first then burn out racing to the finish line. Doesn’t matter if the deadline is in two years or two weeks. Short-term goals are easier to plan than long-term ones. That's how sprints can be useful. An important distinction between "goal" and "deadline" in this context is the intent behind setting them. Agile can be useful for measuring productivity, improving the accuracy of estimates, and identifying reasons for missed goals. It can't guarantee that some arbitrary deadline will be met. I agree that the concept of agile goals can be abused, but I don't think it has to be inevitable.
|
|
#
?
Jan 26, 2020 07:04
|
|
|
DaTroof posted:Short-term goals are easier to plan than long-term ones. Sure, but they're both detrimental to actually getting the work done. quote:That's how sprints can be useful. You're breaking down the wrong thing. When you turn a big feature into smaller tasks, the time to finish each task averages out shockingly well. Then you can extrapolate to figure out when you'll be done all the tasks. Turning a far-future deadline into several nearer-future deadlines maintains the slack off/oh poo poo cycle. You can make a burndown chart without doing a single "sprint".
|
|
#
?
Jan 26, 2020 07:43
|
|
|
It sounds like you've had some terrible sprint meetings and are assuming that everyone else's are similarly terrible.
|
|
#
?
Jan 26, 2020 08:01
|
|
|
Deadlines aren't real.
|
|
#
?
Jan 26, 2020 08:05
|
|
|
Deadlines never die. More like undeadlines.
|
|
#
?
Jan 26, 2020 08:07
|
|
|
pokeyman posted:Sure, but they're both detrimental to actually getting the work done. I might be using a looser definition of "sprint" than how it's typically defined in agile. In my mind, "this sprint" just means "this week's goals." Do you think it's more practical to refrain from setting weekly goals altogether? That's the thing I'm on the fence about.
|
|
#
?
Jan 26, 2020 08:13
|
|
|
It seems like it's about once a year that we get agile here, but this thread is the parent of another one: https://forums.somethingawful.com/showthread.php?threadid=3744073
|
|
#
?
Jan 26, 2020 08:52
|
|
|
Kilson posted:So it's just a meaningless period of time given a name for ... reasons? You ignored everything I said so I'm not going to waste time expanding. Other people have at least been more generous.
|
|
#
?
Jan 26, 2020 08:58
|
|
|
DaTroof posted:Do you think it's more practical to refrain from setting weekly goals altogether? That's the thing I'm on the fence about. That's absolutely something that people do, they usually call it "kanban". I think it's probably better than scrum in that it prevents the jobsworthing some posters in here talk about a lot (i finished all MY tickets in the sprint guess I don't have to come to work the rest of the week  ) but I like having little goals every so often so i can dopamine drip myself into thinking I'm accomplishing things 
|
|
#
?
Jan 26, 2020 15:10
|
|
|
I have had good and bad sprint planning meetings (and good and bad standup meetings). The pleasantness of the meetings (usually measured by how short they are) does not change how ineffective sprints tend to be at marshalling sustained effort in a project.DaTroof posted:I might be using a looser definition of "sprint" than how it's typically defined in agile. In my mind, "this sprint" just means "this week's goals." Yes. Talk about what you're working on, how it's going, all great. Prioritize the daylights out of your backlog, also great. Divide larger features/stories into many small tasks, absolutely. Just skip the deadline ("this week") part. rarbatrol posted:It seems like it's about once a year that we get agile here, but this thread is the parent of another one: https://forums.somethingawful.com/showthread.php?threadid=3744073 I will head over there!
|
|
#
?
Jan 26, 2020 16:26
|
|
|
pokeyman posted:Yes. Talk about what you're working on, how it's going, all great. Prioritize the daylights out of your backlog, also great. Divide larger features/stories into many small tasks, absolutely. Just skip the deadline ("this week") part. To call this naive would be an understatement.
|
|
#
?
Jan 26, 2020 16:34
|
|
|
|
| # ? Jun 6, 2024 02:00 |
|
|
pokeyman posted:I have had good and bad sprint planning meetings (and good and bad standup meetings). The pleasantness of the meetings (usually measured by how short they are) does not change how ineffective sprints tend to be at marshalling sustained effort in a project. You've had good and bad meeting hygiene, but it sounds like you've never had a good product org or project- and program-level management that works with you to set worthwhile goals. Project management is really hard, and there are a lot of people who take "we're doing agile" to mean "we don't have to worry about all that difficult stuff." That's nonsense. But, it doesn't mean that good project planning is impossible. I'm also going to guess that, based on your separation of "getting the work done" from hitting planned targets, you're doing some kind of support/minor extension work in an existing system. There are huge differences between that and a project that's just a money pit until you hit a viable set of features and can roll it out.
|
|
#
?
Jan 26, 2020 17:04
|
|
