|
Ready for this horror story... The place I'm currently contracting at equates 1 point to something a dev could get done in a day. They schedule 4 points per developer per 2 week sprint.
|
#
?
Jan 31, 2017 02:16
|
|
|
|
| # ? May 11, 2024 21:54 |
|
|
Gounads posted:Ready for this horror story... The place I'm currently contracting at equates 1 point to something a dev could get done in a day. They schedule 4 points per developer per 2 week sprint. Sounds good to me. That's 6 days that you can spend watching youtube videos and playing SNES emulator games at work.
|
|
#
?
Jan 31, 2017 02:33
|
|
|
I had a couple of managers who took the estimate = promise of work approach. It was totally stupid, and I told the first one so, including how the devs would game it, how it would affect overall quality when we did game it, and how it wouldn't actually make us work any faster, just worse. This went over like a lead balloon, so I stopped arguing. Then I proceeded to game it exactly as I said I would, and always ended each sprint between 2-4 points over our "goal" (so like 42/40 points). I figured the PM would call me out (since I was doing exactly what I told him I would do), but he didn't. Weirdly enough, most of the other devs on the team never figured out how to game it. They would still do crap like trying to outdo each other during planning poker for who could have the lowest estimate on things, or avoiding boring text fixes in favor of new feature stories. Then they would get reamed every sprint for not meeting their sprint goals.
|
|
#
?
Jan 31, 2017 02:51
|
|
|
Gounads posted:Ready for this horror story... The place I'm currently contracting at equates 1 point to something a dev could get done in a day. They schedule 4 points per developer per 2 week sprint. Yea thats p good. Do you work for me? Cuz thats what I just described. I'm trying to inch our points back up but every dev is diff and some can do 8 points and some max out at 5 and can't handle a hotfix
|
|
#
?
Jan 31, 2017 03:23
|
|
|
vonnegutt posted:Weirdly enough, most of the other devs on the team never figured out how to game it. They would still do crap like trying to outdo each other during planning poker for who could have the lowest estimate on things, or avoiding boring text fixes in favor of new feature stories. Then they would get reamed every sprint for not meeting their sprint goals. Thats super dumb and counter intuitive. We don't want the bare bones poo poo that you didn't even think twice about writing tests for. We are writing artisinal, hand crafted code here people! Like the god drat amish
|
|
#
?
Jan 31, 2017 03:25
|
|
|
Gounads posted:Ready for this horror story... The place I'm currently contracting at equates 1 point to something a dev could get done in a day. They schedule 4 points per developer per 2 week sprint. My current gig would just say 1 point per dev per day and then schedule 10 points per dev per sprint and wait why is this project behind schedule
|
|
#
?
Jan 31, 2017 03:28
|
|
|
So what is the value of estimating points over estimating hours?
|
|
#
?
Jan 31, 2017 03:32
|
|
|
Gounads posted:Ready for this horror story... The place I'm currently contracting at equates 1 point to something a dev could get done in a day. They schedule 4 points per developer per 2 week sprint. Hah! My company when it started agile had absolutely no idea how much a point should be worth and said 3 points is akin to "Adding a form field to a form > Save the data > Retrieve" so a simple CRUD. Our point scale is also pretty much logarithmic. 
|
|
#
?
Jan 31, 2017 03:38
|
|
|
geeves posted:Hah! My company when it started agile had absolutely no idea how much a point should be worth and said 3 points is akin to "Adding a form field to a form > Save the data > Retrieve" so a simple CRUD. Our point scale is also pretty much logarithmic. One of my previous employers built an entire XML framework based on a financial-industry pseudostandard that was coked up using a combination of SQL trigger based logic, ASP.NET MVC Razor scripts and a precarious stack of undocumented LINQ that would break halfway through a query if any nulls happened. It was the first time I found out that you could insert into a view in MSSQL. There were no automated tests; QA would start each day by manually doing a few laps through the exact same collection of multi-gigabyte CSV sanitized customer data they had lying around on their machines. Inevitably we would receive new data from a target customer a month before release, which always exposed something we didn't track properly and blew everything to hell. The point of the story is, adding a single field could easily eat a sprint, possibly a few mansprints depending on how deep things got. Once, we were a week from customer release when they told us they wanted to be able to arbitrarily reorder the fields in the resulting XML. Rather than just write a quick hack to do it after serializing the XML and get it out the door, we instead added an "order" field to each field definition, which worked except nobody could agree on an order without breaking each others' products... it ended in a multiple-sprint endeavour to completely gut the database layer and rebuild it with more triggers and an OLAP-friendly schema. A DBA was hired, who had ideas about data warehouses and generating output data using SSRS. Halfway through month four of the database refactor we decided to just kind of abandon the idea of migrations and just assumed that the customer in question wouldn't come back for a second version of our software anyway. When the project failed our division of the company was co-opted by outraged business analysts who, convinced we were incompetent, pushed to acquire a drag-and-drop ETL provider for its consulting business and then demanded that we rebuild the product in that ETL software (featuring a single-threaded, SQL-trigger-based, 32-bit-only server process that could not be parallelized, unit tested or served over SSL). At one point we built our own mocking tool in order to isolate components of their architecture and prove that they did not parse XML properly with their handbuilt XML parser (despite the fact that they were on a C#/.NET platform: the HTTP server was also handbuilt which is why SSL never worked). They took the mocking tool and sold it to their customers as part of their consulting arm. After about a year of working with them to replace their unscrollable procedural Silverlight UI generator with an HTML5 UI that could be altered by human beings, the company cancelled the project, fired the lead developer (and founder) of the ETL product and decided to stop making anything with a graphical user interface. They're on some kind of Hadoop kick now, from what I understand. Seat Safety Switch fucked around with this message at 04:04 on Jan 31, 2017 |
|
#
?
Jan 31, 2017 03:42
|
|
|
Iverron posted:My current gig would just say 1 point per dev per day and then schedule 10 points per dev per sprint and wait why is this project behind schedule I've found a problem that most people, devs and management alike, is not taking into account everything that isn't "designing the feature and writing code for the feature." Documentation, testing (and I mean writing unit tests, not dumb testing), communication with stakeholders, deployment tasks, meetings, emergencies, and just general everyday interruptions. "This will take me about a day" usually has an implied "uninterrupted" tacked on, but people don't consciously realize it. Seems that these days most companies would rather run with a skeleton crew, because it's easy to see the cost difference between "3 devs" and "4 devs, a devops guy, a couple of support techs" on the company expense report, but it's not so easy to figure the cost of a feature or product taking three times as long to develop.
|
|
#
?
Jan 31, 2017 03:43
|
|
|
Che Delilas posted:I've found a problem that most people, devs and management alike, is not taking into account everything that isn't "designing the feature and writing code for the feature." Documentation, testing (and I mean writing unit tests, not dumb testing), communication with stakeholders, deployment tasks, meetings, emergencies, and just general everyday interruptions. "This will take me about a day" usually has an implied "uninterrupted" tacked on, but people don't consciously realize it. This is the stuff I would always bring up during planning - spinning up a dev env, writing tests, code review, deployment, QA, and cleanup all needs to be accounted for with every time estimate, meaning that even the smallest fix would never be less than 2 hours from opening the laptop to live on the server. I would still have coworkers arguing that something was a "5 minute fix" even though our CI pipeline took 15 minutes. That's all coding-adjacent work as well. Somehow meetings never counted as time at all.
|
|
#
?
Jan 31, 2017 03:53
|
|
|
lifg posted:So what is the value of estimating points over estimating hours? You better be careful. People have been killed for heresy for far lesser statements.
|
|
#
?
Jan 31, 2017 04:01
|
|
|
Gildiss posted:"Being that we have decided to move from agile back to waterfall development I feel it would be helpful to schedule weekly demos with the business to get feedback on the current progress." "As you can see, nothing has changed, as deployment is the last thing scheduled. Expect something interesting by 2019"
|
|
#
?
Jan 31, 2017 04:04
|
|
|
Skandranon posted:"As you can see, nothing has changed, as deployment is the last thing scheduled. Expect something interesting by 2019" I dropped off my laptop and walked out when they announced 9am stand-up meetings and 5pm stand-down meetings everyday. Last I heard the single remaining dev of 4 was working overtime sometimes till 9pm sometimes till 3am with the managers desperately coding the wildly expanded and out of control requirements we warned them against for months hahaha. Gildiss fucked around with this message at 04:14 on Jan 31, 2017 |
|
#
?
Jan 31, 2017 04:11
|
|
|
Our data model is not that insane, thankfully. But now that you mention it, there has been one field from the DB that the PO wants to expose to one set of our users via a form that could have major ramifications as it deals with stuff on the financial side of things, so you are very correct. And this is all because one of our clients is using our system as an invoice system instead of what it actually is.  vonnegutt posted:This is the stuff I would always bring up during planning - spinning up a dev env, writing tests, code review, deployment, QA, and cleanup all needs to be accounted for with every time estimate, meaning that even the smallest fix would never be less than 2 hours from opening the laptop to live on the server. I would still have coworkers arguing that something was a "5 minute fix" even though our CI pipeline took 15 minutes. Yeah, the value of the points is arbitrary. But I find it hilarious when at agile meetups to see how other companies incorporate agile they ask how many points we do per sprint and I saw something like "50" they look at me like I'm loving insane.
|
|
#
?
Jan 31, 2017 04:14
|
|
|
Gildiss posted:stand-down meetings 
|
|
#
?
Jan 31, 2017 04:28
|
|
|
Jeeeezus frigging Chris guys I came home after night school and find 30 reply to the thread. I found myself laughing out loud, vomiting and laughing again. Make me feel appreciate my work and boss so thank you all. Re : All the Agile talk. I find myself being the scrummaster of a small team as the boss asked me to help introduce Agile to the team. I've been very relaxed about it as I've experienced this transition a few times already. We have daily stand-up and a pseudo-planning every week. We don't demo every week, we don't have post-mortem (but I plan to have some, maybe, eventually), we did start to estimate but no one is held accountable to finish when the sprint is finished, as we understand that unforseen work will happen. It barely feel like agile... and it's great I tell ya. To me Agile is all about being a dev team that can react and adapt better to the business moving targets, planning short iterations and understanding what's really creating value. All the measurement and certification and the stuff the agile consultants say are crucial... Meh I'm not so sure about that. If it work for your team that's what count. I doubt that can be done on a large scale, as it heavily depend on reciprocal trust. AskYourself fucked around with this message at 04:53 on Jan 31, 2017 |
|
#
?
Jan 31, 2017 04:48
|
|
|
lifg posted:So what is the value of estimating points over estimating hours? It is an estimate of hours, but with just a lil magic dust sprinkled in that you can talk in terms that aren't down to the exact hour, Sprint points is literally real_time * sprint_point_fudge_factor MY manager wants to move to kanban, I dunno about it. I like the rigid frequency of a sprint, and also i bitched so long about "iut will be done when its done, why are you imposing artificial deadlines on me like they friggen matter???" But, well, as a professional you gotta deliver on what you commit to, otherwise your word aint poo poo. but also, gently caress em - a real sophies choice KoRMaK fucked around with this message at 05:17 on Jan 31, 2017 |
|
#
?
Jan 31, 2017 05:14
|
|
|
The agile philosophy is good and all but the issue is that you often get That Manager that wants a very quantized, easily measured, highly specified set of expectations from developers, which just isn't possible. Yeah a competent developer can guess how long something will take but a competent developer will also tell you "poo poo will go wrong." That five line change might turn into a week long hunt for a Heisenbug that totally cripples the application from time to time but is so hard to duplicate and oh gently caress this critical system was written 8 years ago by an intern why does this abomination even exist in production? I can't make this change without fixing this and...ugh. ... Not that I had a relatively small thing to do at work that turned into gutting and rewriting an entire system. No. That didn't happen to me at all!
|
|
#
?
Jan 31, 2017 05:26
|
|
|
ToxicSlurpee posted:The agile philosophy is good and all but the issue is that you often get That Manager that wants a very quantized, easily measured, highly specified set of expectations from developers, which just isn't possible. Yeah a competent developer can guess how long something will take but a competent developer will also tell you "poo poo will go wrong." That five line change might turn into a week long hunt for a Heisenbug that totally cripples the application from time to time but is so hard to duplicate and oh gently caress this critical system was written 8 years ago by an intern why does this abomination even exist in production? I can't make this change without fixing this and...ugh. Bake that into the estimate. I call it bluriness or clarity. The blurrier the task, the bigger the estimate. Think through it enough to get the scope ahead of time. Theres a lot of process involved, and also push back. I fight with my managers all the time, sometimes im right and I help them realize it, othertimes theyre right and I'm being to cautious. Point is, keep talking and also fight about it. e: um, but my experience is in a realitivly young codebase, its 5 years old (I've been the lead on it that whole time) and not something that is like 100 developers big. A 5 line change would never turn into a multi week project in my app, so that's the limits of how bad my pain can get. RIP you wonderful idiots that program in oracle or whatever
|
|
#
?
Jan 31, 2017 05:29
|
|
|
KoRMaK posted:Bake that into the estimate. I call it bluriness or clarity. The blurrier the task, the bigger the estimate. Think through it enough to get the scope ahead of time. Theres a lot of process involved, and also push back. I fight with my managers all the time, sometimes im right and I help them realize it, othertimes theyre right and I'm being to cautious. Point is, keep talking and also fight about it. What I work on is over a decade old. It was started by a person who was not a programmer at all. Most of the people that touched it before I got the job were also generally not programmers. I'm the first person with a computer science degree to touch it. The other guy I work with is competent and agrees that our code base is terrible and should be replaced. That's one of our ongoing things and was part of why I got the go ahead to just axe that whole system. It was bad, it was old, and it wasn't scalable.
|
|
#
?
Jan 31, 2017 05:43
|
|
|
ToxicSlurpee posted:The other guy I work with is competent and agrees that our code base is terrible and should be replaced. That's one of our ongoing things and was part of why I got the go ahead to just axe that whole system. It was bad, it was old, and it wasn't scalable. At some point while I was working at Experts Exchange, somebody wrote copy to the effect of, "We rewrote every line of the code from scratch!" and, man oh man, that would have been so much better than what actually happened.
|
|
#
?
Jan 31, 2017 06:20
|
|
|
piratepilates posted:I've never worked at a place that did real capital A agile (closest I've come is a month on a team that has daily standups and your tasks are assigned in JIRA) but it seems crazy over the top. Are people somewhere finding it actually helpful to go through all this effort with the points and all of this tracking and processes? I've never tried it but it seems like so much added complexity and bookkeeping for nothing. When I was a junior, on a team of juniors, at a shop where we couldn't keep a PM for more than a month because of account management's inability to properly corral clients, instituting Agile processes was an improvement over bugfuck chaos. Now that I'm more seasoned and in a different environment that also uses Agile, I think it's a good process for situations where the client/stakeholder is more erratic than the PM. But it has a lot of failure modes, as this thread attests.
|
|
#
?
Jan 31, 2017 06:38
|
|
|
Che Delilas posted:I've found a problem that most people, devs and management alike, is not taking into account everything that isn't "designing the feature and writing code for the feature." Documentation, testing (and I mean writing unit tests, not dumb testing), communication with stakeholders, deployment tasks, meetings, emergencies, and just general everyday interruptions. "This will take me about a day" usually has an implied "uninterrupted" tacked on, but people don't consciously realize it. Yep. We lost our last devops / support guy a month ago and I've yet to see a listing go up. We only hired them at the threat of one our other devs leaving. Same dev also left a month ago. I don't expect we'll ever get another as most of the devs have become cash cows for the "fun" side of the business. Yes,  . I know, working on it.
|
|
#
?
Jan 31, 2017 07:28
|
|
|
vonnegutt posted:This is the stuff I would always bring up during planning - spinning up a dev env, writing tests, code review, deployment, QA, and cleanup all needs to be accounted for with every time estimate, meaning that even the smallest fix would never be less than 2 hours from opening the laptop to live on the server. I would still have coworkers arguing that something was a "5 minute fix" even though our CI pipeline took 15 minutes. In our team we estimate about 8 points per developer per sprint, around one per day. Some sprints, that two point story takes me a week. This sprint, I had 15 points on my name and finished a few days early. Also got moved into a new office and stumbled upon this thing (small x-post): https://qz.com/891537/if-you-dont-trust-your-employees-to-work-remotely-you-shouldnt-have-hired-them-in-the-first-place/ Of course the new office is open as well, it is engrained so deeply into this culture that anything else is considered luxury. Edit because I forgot the best part from the last month. We had a developer here, he left this week. Let's call him Akin as that is his name. He had been working on some framework that would revolutionize our automated testing, this was in the works for a few months by now and for some reason the code lived only on his machine. He would demo things now and then, kicking off scripts in Eclipse that would open some screens and go through some applications in the full chain. Repeated requests by the rest of the team for his code to be put in git was countered with "when it is ready for deployment to git, I wouldn't want anyone to think this is incomplete". The manager who hired him left a few weeks after he was hired, which was about 6 months back. He put in his notice beginning this month and promised a knowledge transfer, I volunteered as I was curious what he actually achieved. First thing we did was agree he would put his code in git in the first week and then he again showed me some things he did. After a week, no code in git. We agreed he would make it run in Jenkins, after two weeks, nothing in Jenkins and nothing in git. Last Friday, three weeks after he resigned, he uploaded some code to git, dropped off his laptop and left not to be seen again. The short of it, everything his code does we replicated in a different framework in two days, these tests we build run in Jenkins and have proper reporting as well. Lesson learned: nobody can work on anything that is not in git, ever. If someone is not a teamplayer and willing to share, fire them immediately. If management won't do that, either ignore the problem and end up like a boiled frog or leave. Keetron fucked around with this message at 08:45 on Jan 31, 2017 |
|
#
?
Jan 31, 2017 08:27
|
|
|
lifg posted:So what is the value of estimating points over estimating hours? Also at the end of the sprint when the forecast was wrong the discussion is "why did we only complete 17 points not the 24 we expected?" not "why did you lazy fucks only work 226 of the 320 hours in the last fortnight?". AskYourself posted:I find myself being the scrummaster of a small team as the boss asked me to help introduce Agile to the team. I've been very relaxed about it as I've experienced this transition a few times already.
|
|
#
?
Jan 31, 2017 08:40
|
|
|
lifg posted:So what is the value of estimating points over estimating hours? Value?
|
|
#
?
Jan 31, 2017 15:13
|
|
|
ToxicSlurpee posted:The agile philosophy is good and all but the issue is that you often get That Manager that wants a very quantized, easily measured, highly specified set of expectations from developers, which just isn't possible. Yeah a competent developer can guess how long something will take but a competent developer will also tell you "poo poo will go wrong." That five line change might turn into a week long hunt for a Heisenbug that totally cripples the application from time to time but is so hard to duplicate and oh gently caress this critical system was written 8 years ago by an intern why does this abomination even exist in production? I can't make this change without fixing this and...ugh. The codebase I work on is maybe 2 months old and we already have weird bugs and a Nazi PM obsessed with quantative measures and timelines and gets really pissed when devs say they don't immediately know how long something will take. We've had standups where she's had entire angry rants about why we suck and how disappointed she is in the team. She's too dumb to realize that the reason the team is failing is because it's poorly organized and does a completely stupid version of Agilefall while she thinks that adding more devs will fix the problem. Gantt charts are involved somewhere. There's already talk of devs leaving. Not before I do, motherfuckers!
|
|
#
?
Jan 31, 2017 15:27
|
|
|
Keetron posted:Lesson learned: nobody can work on anything that is not in git, ever. If someone is not a teamplayer and willing to share, fire them immediately. If management won't do that, either ignore the problem and end up like a boiled frog or leave. This is really important. It's 2017, there's no excuse for this anymore. Git means that you can put a remote branch anywhere with no issues. Even if you're concerned about how your code looks, having it backed up somewhere is paramount just in case your local machine does.
|
|
#
?
Jan 31, 2017 15:43
|
|
|
Destroyenator posted:One reason is to smooth out differences in experience levels. The team as a unit can do X points in a sprint, not every team member is expected to be able to complete each a story in set number of hours. So if you assign story points, does that mean that you don't estimate hours? Do story points eventually become a function of hours?
|
|
#
?
Jan 31, 2017 17:01
|
|
|
lifg posted:So if you assign story points, does that mean that you don't estimate hours? In this thread, yes, they become directly translatable to hours. The goal is for it not to work that way though, they should be a measure of expected effort. That might include things like working with other teams or coordinating with other parts of the organisation that you can't really estimate hours on. If you want to do estimates for the team to coordinate around and to communicate relative sizes to a manager without committing to points or velocities then S/M/L/XL instead of points can work. I should say that on my current project we have a really good PO and we do no estimates.
|
|
#
?
Jan 31, 2017 18:19
|
|
|
lifg posted:So if you assign story points, does that mean that you don't estimate hours? We've always been told points == effort. Effort = Estimated Time + Estimated Complexity (and it's best to just go with loose gut feelings as we adjust points if it becomes a rabbit hole or preferably, new stories that can be done separately)
|
|
#
?
Jan 31, 2017 20:40
|
|
|
Destroyenator posted:One reason is to smooth out differences in experience levels. The team as a unit can do X points in a sprint, not every team member is expected to be able to complete each a story in set number of hours. Yeah you're right this has to be done as a team. Just got to tune the group dynamic a little more, but we're almost there.
|
|
#
?
Feb 1, 2017 03:16
|
|
|
How do you deal with people being late to standup?
|
|
#
?
Feb 1, 2017 17:53
|
|
|
smackfu posted:How do you deal with people being late to standup? Always start on time.
|
|
#
?
Feb 1, 2017 18:03
|
|
|
Run it without them, and when they walk in they should be quiet as a mouse - otherwise they are not demonstrating proper etiquette
KoRMaK fucked around with this message at 18:51 on Feb 1, 2017 |
|
#
?
Feb 1, 2017 18:36
|
|
|
smackfu posted:How do you deal with people being late to standup?
|
|
#
?
Feb 1, 2017 18:49
|
|
|
Vulture Culture posted:Make them wear a suit into work the next day And have them be the best dressed one in the office?? No way!
|
|
#
?
Feb 1, 2017 18:52
|
|
|
KoRMaK posted:And have them be the best dressed one in the office?? No way!
|
|
#
?
Feb 1, 2017 19:00
|
|
|
|
| # ? May 11, 2024 21:54 |
|
|
smackfu posted:How do you deal with people being late to standup? The standup start on schedule. Disciplinary actions and such should be handled by the supervisor/manager indivdually.
|
|
#
?
Feb 1, 2017 19:19
|
|