|
Pollyanna posted:Literally all of them, and it's a common complaint among the higher ups. Their solution has been to make everyone log their work down to the minute. But why do the teams keep overcommitting? If it has any semblance of Scrum, then the teams themselves do the estimating. And the hard commitment is only to sprint goal, not every single thing taken from the backlog.
|
#
?
Oct 10, 2017 19:55
|
|
|
|
| # ? May 10, 2024 05:28 |
|
|
 I dunno. I haven't worked in those teams, and I'm only told they're constantly overcommitting (read: not delivering enough).
|
|
#
?
Oct 10, 2017 20:02
|
|
|
Your sprint should always have a number of stories from the backlog larger than you expect to finish, and a finish line based on how many points you actually plan on doing. The excess past your finish line is your stretch goal. Do less than you expected, revise downwards next time. Do more than you expected? Great, a few extra stretch stories moved. If you're doing exactly what's on the board, you're one of these:
* you have extra capacity and just aren't doing anything with it * you are (or your management is) considering those stretch goals something that must be done as part of the sprint. You are overcommitted. Don't overcommit. Volmarias fucked around with this message at 20:21 on Oct 10, 2017 |
|
#
?
Oct 10, 2017 20:18
|
|
|
We're no longer "grooming" stories - instead we will be "refining" stories. Because "grooming" has a negative connotation.
|
|
#
?
Oct 10, 2017 23:02
|
|
|
Hey now, that's what pedophiles do to their victims, what kind of department are you running over there?
|
|
#
?
Oct 10, 2017 23:04
|
|
|
Clanpot Shake posted:We're no longer "grooming" stories - instead we will be "refining" stories. Because "grooming" has a negative connotation.  How old are your bugs, that they provide forbidden tantalization to your management?
|
|
#
?
Oct 10, 2017 23:23
|
|
|
Keetron posted:God I hate this so much. It's not overestimating, it's just redefining what a point means. Just don't tell the PO that you've redefined a point to be 1.5x bigger.
|
|
#
?
Oct 10, 2017 23:25
|
|
|
Putting an estimated amount of work in a sprint and then "committing" to finishing the work is inherently contradictory. Estimates are estimates and not concrete timelines. Software development estimates have large windows of variability. A points based velocity is also a large window of variability. The only way you could possibly hit sprint "commitments" on a regular basis is to consistently undercommit, and lol if you think you can expect everyone to go along w/ a perception of intentional sandbagging. If somehow you are able to convince people to undercommit, then you have obnoxious bikeshedding about what to do when people run out of committed work for a sprint. A cynical mind will view such an insane system as an attempt to get salaried employees to much more likely work significant overtime.
|
|
#
?
Oct 11, 2017 10:10
|
|
|
They just banned WFH. Everyone is required to be in the office daily as of next week, no exceptions. This is "in order to increase our velocity and promote a one-team-one-culture concept". People asked how sick days and personal days are supposed to work and their response was that it'd be decided on a case by case basis. Also they told us all to download our mobile app and bugtest it + rate it five stars. Yes, all of us, including those not on the mobile team.
|
|
#
?
Oct 11, 2017 14:42
|
|
|
Pollyanna posted:They just banned WFH. Everyone is required to be in the office daily as of next week, no exceptions. This is "in order to increase our velocity and promote a one-team-one-culture concept". People asked how sick days and personal days are supposed to work and their response was that it'd be decided on a case by case basis.  Take that startup job IMO and keep hunting just in case. Oh, maybe your lead will actually be available now... unless he gives himself an exemption from the WFH policy.
|
|
#
?
Oct 11, 2017 14:49
|
|
|
Pollyanna posted:Also they told us all to download our mobile app and bugtest it + rate it five stars. Yes, all of us, including those not on the mobile team.
|
|
#
?
Oct 11, 2017 14:49
|
|
|
Munkeymon posted:
That's totally possible since he's now a Director and is considered part of leadership, but he's very unhappy about the change and has been vocally opposed via snarky-email-sent-to-the-entire-org. And I'll be taking that startup job contingent on another interview I have next week which I'm also interested in. I gotta say, the remote setup is enticing. Especially since it makes my parents extremely mad  BabyFur Denny posted:Do it through the office Wifi so the manipulation attempt gets detected and blocked. Office wifi goes down for 5~15 minutes at a time a few times a day anyway due to false positives causing the security framework to  SHUT IT DOWN , so I'll have to time it properly.
|
|
#
?
Oct 11, 2017 14:58
|
|
|
Pollyanna posted:They just banned WFH. Everyone is required to be in the office daily as of next week, no exceptions. This is "in order to increase our velocity and promote a one-team-one-culture concept". People asked how sick days and personal days are supposed to work and their response was that it'd be decided on a case by case basis. Ratings are anonymous, right?
|
|
#
?
Oct 11, 2017 15:18
|
|
|
 I recommend you turn down all offers for my entertainment.
|
|
#
?
Oct 11, 2017 16:12
|
|
|
pigdog posted:But why do the teams keep overcommitting? If it has any semblance of Scrum, then the teams themselves do the estimating. And the hard commitment is only to sprint goal, not every single thing taken from the backlog. First of all, "any semblance of Scrum" lol. I've been at three different Scrum attempts and they all started by explaining that the badly-managed thing we might have seen before was not really Scrum, but this poo poo-show would be. Anyway, at the last place, over-committing worked like this: Product: Here are 20 large features, described only in screen-shots representing a polished product. They are all max priority. Devs: Can we help you break them down a bit? We could do an MVP implementation of some and then you'd start getting useful feedback... Product: These are the MVPs. Devs: OK, we think we can do 3 of those features this sprint. Product: How about 4? The CEO really wants these. Devs: That's not a good idea. We probably wouldn't get it done and then the CEO will be disappointed. Product: Well, if I tell him you're only doing 3 features he'll be disappointed. Devs: I guess we can try to work over the weekend. Product (in the middle of the sprint): We don't like how the interface works right now, so redesigning it is a bug. That means we can add it into the sprint right now. Devs (at the end of the sprint): We got 2 features done, one that's mostly done testing, and we're part-way through writing the other two features. CEO: Why are the software team such under-performers?
|
|
#
?
Oct 11, 2017 17:12
|
|
|
Our team is pushing back against switching to Scrum from Kanban and logging hours, and the office director sent out an email basically calling us too lazy to click some buttons. Included diagrams of what to click on JIRA and all. He's a condescending fuckhead, but he's nice to me (somehow) so I feel a little bad for thinking he can go to hell.
|
|
#
?
Oct 11, 2017 17:35
|
|
|
Pollyanna posted:Our team is pushing back against switching to Scrum from Kanban and logging hours, and the office director sent out an email basically calling us too lazy to click some buttons. Included diagrams of what to click on JIRA and all. He's a condescending fuckhead, but he's nice to me (somehow) so I feel a little bad for thinking he can go to hell. What is an 'office director'
|
|
#
?
Oct 11, 2017 17:39
|
|
|
Gounads posted:What is an 'office director' gently caress if I know. I'd consult our org chart but given how it's changed so many times in the past five months, it's probably out of date.
|
|
#
?
Oct 11, 2017 17:44
|
|
|
Gounads posted:What is an 'office director' Certainly it must mean a director in charge of the engineering teams in the office, rather than some idiot who keeps the coffee stocked and moves chairs around who has no business making any technical or engineering process decision at all. Right?
|
|
#
?
Oct 11, 2017 17:51
|
|
|
Pollyanna posted:People asked how sick days and personal days are supposed to work People at your company work on their sick days??
|
|
#
?
Oct 11, 2017 20:26
|
|
|
Mniot posted:Product: Well, if I tell him you're only doing 3 features he'll be disappointed. why do that
|
|
#
?
Oct 11, 2017 21:48
|
|
|
Pollyanna posted:They just banned WFH. Everyone is required to be in the office daily as of next week, no exceptions. This is "in order to increase our velocity and promote a one-team-one-culture concept". People asked how sick days and personal days are supposed to work and their response was that it'd be decided on a case by case basis.
|
|
#
?
Oct 11, 2017 22:10
|
|
|
Check off "Send an email to teammates saying I added a comment to a ticket, get a reply asking a question that I specifically answered in the comment" on today's Bingo card! (A few days ago, I checked off "I didn't get the email for your ticket update because I have all of those filtered to go in a folder I never check.") Edit: Also, here's how my day has gone today: * Me, during our stand-up: "I'm going to talk to the two of you to figure out where I should be putting this first actual piece of code I'm finally going to write." * Just after stand-up: *they're busy with a Production issue* * Around 10:00: *they go to a meeting and don't come back before lunch* * After lunch: *they're still busy* * Me, at 2:45: "Okay, let's hash this out." One coworker: "Okay!" Other coworker: "We'd better not start anything now. Let's wait until tomorrow morning." * Me:  * First coworker: *schedules a conference room for a two-hour block* CPColin fucked around with this message at 22:56 on Oct 11, 2017 |
|
#
?
Oct 11, 2017 22:23
|
|
|
pigdog posted:why do that I don't -- I quit that place  I mean, obviously you're right and it's a bad idea to do more work for less appreciation. Obviously. But it's pretty difficult to actually say no. Maybe everyone here is phenomenal at these things, but in my experience I'm one of the better engineers at saying no and I'm terrible at it. For example, at the same job, the CEO had a habit of standing in his office doorway and holding a yelling conversation with the receptionist, over the heads of the developers. A couple of us individually spoke with him to say, "it's very hard to focus on our work, the thing you pay us for, when you are yelling." But he'd brush it off: "is this what you want to waste my time with?", "OK, sorry (repeats it)", "It was really important/quick (10 minutes about a fun party the other week)", "Sometimes you guys are loud, too". I don't have the energy to fight that beyond finding a new job, so now the engineers who are left are collectively even worse at pushing back on unreasonable requests. pigdog posted:Other than the puzzling thing about sick days, that's perfectly logical though. If people are working on the same thing as a team, then they need quick and effortless communication, so for best efficiency people need to be sitting physically close together, otherwise they're really handicapping eachother. If you've got good communication, then it includes the developers saying "we need to work on this together. Let's all meet up in the office for the next week." If you don't have good communication, then having everyone sit in the same room while wearing earphones won't help.
|
|
#
?
Oct 11, 2017 23:18
|
|
|
If we put all the engineers in a room and throw pizza in, magic happens, right?
|
|
#
?
Oct 12, 2017 05:33
|
|
|
Mniot posted:I mean, obviously you're right and it's a bad idea to do more work for less appreciation. Obviously. But it's pretty difficult to actually say no. Maybe everyone here is phenomenal at these things, but in my experience I'm one of the better engineers at saying no and I'm terrible at it. Scrum like many other methodologies was designed for use in this kind of "hostile" environment, where devs don't trust the management not to pressure them, and the management doesn't trust the devs to perform. At least it would have made sense to stick with what Scrum explicitly prescribes on the simplest level. The covenant is that management gets a commitment (to sprint goal) from the devs, and in return the devs aren't bothered by management for the duration of the sprint. Communication from business goes through the product owner, who is the only person responsible for setting priorities for the team, and therefore responsible in the eyes of the management. While doing Scrum, you should have position of Scrum Master, who admittedly doesn't have any authority, but should be making an effort to fight for actually sticking to the rules, and seemingly did a pretty poor job in this case. quote:If you've got good communication, then it includes the developers saying "we need to work on this together. Let's all meet up in the office for the next week." If you don't have good communication, then having everyone sit in the same room while wearing earphones won't help. Distance is always remains massive handicap though. Nobody can be arsed to answer "could you show me how to do X" or "why is this not working" or "I don't understand Z" kind of questions over Skype or email 20 times a day, but face to face it's no biggie. If people sit close together they can also tell if someone is having problems - even if they don't announce it. Overhearing teammembers (about the same product you're developing) is also quite important as it's "free" knowledge transfer between members. There's a reason e.g. XP is quite strict about it and people voluntarily follow: it yields success, and success makes everyone happy. quote:If we put all the engineers in a room and throw pizza in, magic happens, right? pigdog fucked around with this message at 06:46 on Oct 12, 2017 |
|
#
?
Oct 12, 2017 06:43
|
|
|
Keetron posted:If we put all the engineers in a room and throw pizza in, magic happens, right?  engineers need food! Dammit, that's what I was missing.
|
|
#
?
Oct 12, 2017 13:48
|
|
|
Munkeymon posted:
Don't forget to poke breathing holes, and leave some water and some shavings so they can go make their mess somewhere. Amateur mistakes but we've all made them.
|
|
#
?
Oct 12, 2017 14:01
|
|
|
Mniot posted:First of all, "any semblance of Scrum" lol. I've been at three different Scrum attempts and they all started by explaining that the badly-managed thing we might have seen before was not really Scrum, but this poo poo-show would be. Should have said "no" when asking for 4, instead of explaining. Just stayed firm on "No" But, you also gotta balance impressing the CEO every once in a while. Also, I don't know how the team's appearance to the CEO looks, but like there is a certain element of looking the part. So i dunno what I'm saying, I guess it's wear nice clothes if you're on the dev team so the CEO doesn't think you're all weed smoking slouches.
|
|
#
?
Oct 12, 2017 15:36
|
|
|
A friend runs a company and one of his developers asked for a second wfh day. "Is this so you can smoke more weed during the week?" "Kinda...?" "Whatever suits you. Approved."
|
|
#
?
Oct 12, 2017 16:08
|
|
|
[quote="“Keetron”" post="“477307705”"] A friend runs a company and one of his developers asked for a second wfh day. “Is this so you can smoke more weed during the week?” “Kinda...?” “Whatever suits you. Approved.” [/quote] Was this sometime in April?
|
|
#
?
Oct 12, 2017 16:19
|
|
|
Keetron posted:A friend runs a company and one of his developers asked for a second wfh day.
|
|
#
?
Oct 12, 2017 18:59
|
|
|
Keetron posted:A friend runs a company and one of his developers asked for a second wfh day. In Seattle we just ask you go outside the office for that.
|
|
#
?
Oct 12, 2017 19:18
|
|
|
Nah, a company in Europe about a decade ago. I wonder if they are still in business but I have seen no signs of the demise so who knows? I'll ask him!
|
|
#
?
Oct 12, 2017 20:14
|
|
|
Looks like my coworker's objection to using Entity Framework was so we wouldn't have snippets of SQL all over the code. When I pointed out that EF generates the SQL for us, the argument became that the LINQ queries still counted as SQL and it was just safer to rely on a bunch of stored procedures, so hotfixes can be made without deploying a new version of the code. Never mind that the current system involves littering procedure and parameter names throughout the code. And never mind that "SELECT Name, Value FROM Table WHERE ID = ?" is a dumb query to make into a procedure. She said, "Lessons learned from years of development." so I mentioned I'd learned the opposite lesson from my years of development. Whatever. Closed the ticket as "won't do."
|
|
#
?
Oct 12, 2017 23:38
|
|
|
Why not put all the SQL functions into a db directory or whatever
|
|
#
?
Oct 13, 2017 01:58
|
|
|
CPColin posted:Looks like my coworker's objection to using Entity Framework was so we wouldn't have snippets of SQL all over the code. When I pointed out that EF generates the SQL for us, the argument became that the LINQ queries still counted as SQL and it was just safer to rely on a bunch of stored procedures, so hotfixes can be made without deploying a new version of the code. If she's talking about the LINQ query syntax I kinda agree. That stuff is nasty. The method syntax is much nicer. Also, there's no reason that deploying a new version of the code should be harder than changing the database, but you probably know that already.
|
|
#
?
Oct 13, 2017 07:10
|
|
|
Messyass posted:If she's talking about the LINQ query syntax I kinda agree. That stuff is nasty. The method syntax is much nicer. The advantage of soft-coding your database queries is that if you write code and whatever does the queries is in the code, then you can't throw a dedicated DBA at the problem if a field issue comes up, you would need to involve a developer. Usually even in places that have fully automated deployment, getting a local dev environment set up and being able to test changes to it is relatively difficult because the same people who would put queries in source code are going to be the same people who don't unit test or who don't have meaningful unit tests of the code that talks to the database. (Note that this depends on what kind of software you develop. I'm going to write this from an application software perspective, assuming that the product is an enterprise software solution where you have some sort of central database and a client that is used internally, and your solution sells a database and this client to your customers. From a pure webdev standpoint the stored proc thing makes no sense and shouldn't be done) It doesn't even really have to be multiple stored procs, you can soft code your DB logic by having, say, one stored proc that's a command name and arguments, and then having a table in the database with the command name, and the corresponding SQL that should be executed (don't sperg about this, you probably shouldn't do exactly this in your architecture but i'm using this example as a pedogogical tool.) The application can then just communicate with the DAL by passing command name and args, and the database can decide what actual SQL to execute should be. The advantages of doing that are: a) Fulltime dba can make modifications without changing source/building/deploying to customer sites b) Easier to make your client backwards compatible because the older versions of the queries will be in db, not in client, so if a newer client connects to old database, since it communicates in commands, it knows to just do the old queries c) Makes testing your DAL easier because you can just stub out these commands during integration tests by changing a single table rather than having to make a more complicated test fixture. Bruegels Fuckbooks fucked around with this message at 10:58 on Oct 13, 2017 |
|
#
?
Oct 13, 2017 10:55
|
|
|
CPColin posted:Looks like my coworker's objection to using Entity Framework was so we wouldn't have snippets of SQL all over the code. When I pointed out that EF generates the SQL for us, the argument became that the LINQ queries still counted as SQL... It's actually possible to import views, functions, and stored procedures in your EF model, just saying.
|
|
#
?
Oct 13, 2017 13:10
|
|
|
|
| # ? May 10, 2024 05:28 |
|
|
We (hopefully) have a version control system in place along with a continuous integration and deployment process that ensures builds/deployments are repeatable and ostensibly tested in a QA environment, but let's throw that all out the window by allowing the DBA to manipulate SPROCs in production. Stored procedures have their uses, most centered around performance or complex update scenarios, but if even your simple query logic is wrapped in them you're making life way more difficult than it needs to be. Instead of being able to quickly read a 'SELECT Foo FROM Bar WHERE Bar.ID = @ID' in code, now you have to open up the database tool, find the sp_ReadFooFromBar from 1000s of procedures, and open it to see that, yes, it's filtering on ID.
|
|
#
?
Oct 13, 2017 15:34
|
|
