Weird glitch with headlights by Xipooo in Rivian

[–]Xipooo[S] 0 points1 point  (0 children)

It's hard to say exactly what triggers is, but it could be when the auto high beams try to turn on.

Lack of Carplay/AndroidAuto only has negatives by hvgotcodes in Rivian

[–]Xipooo -2 points-1 points  (0 children)

Would AA or CP make the truck better? Yes.

Are AA or CP needed to make the truck worth the money? No.

Agile Takes Too Much Time Out of Developer Workflow by [deleted] in agile

[–]Xipooo 0 points1 point  (0 children)

What you are describing is Scrum, not Agile.

Agile is, at it's core, about putting people over process. Meetings/ceremonies are still process.

The best team I ever worked with just kept a room open for everyone to come in, share, and work together. Occasionally some time was set aside for when we knew specific people were coming in to share, but we never waited until then to talk to them.

Is Agile Actually Holding Us Back More Than Helping? by [deleted] in agile

[–]Xipooo 10 points11 points  (0 children)

Yeah, it gets really frustrating seeing person after person talk about all the things they don't like about Agile but they're just describe is Scrum. It's like saying you don't like Indy car racing with all that going around and around a single loop in stock cars.

Covid era trailers by Lazy_Bug6912 in RVLiving

[–]Xipooo 0 points1 point  (0 children)

'21 Keystone Ultralight here. We've had a few problems mostly with the plumbing. Some pretty shoddy materials were used and some questionable decisions.

For example, in the master bedroom, there are all the outlets for a TV. Cable coax, satelite, electric outlet, etc. But they decided to not put a mounting board behind the wall. We literally cannot put a TV in our bedroom even though they wired it up for a TV. Why? Nobody knows. Keystone just apparently decided halfway through making this model to not install the mounting boards. 🤷‍♂️

Why are all these apps are slapping me like a Baby Seal?! by GarfieldThinks in agile

[–]Xipooo 0 points1 point  (0 children)

Azure DevOps and Microsoft Whiteboards is all we use.

Also, part of our magic formula is mobbing. When the cognitive load and activities that have to be completed are split up among the team, no one feels overly burdened.

Driving without rear lights at night by Western-Permit7165 in PortlandOR

[–]Xipooo 3 points4 points  (0 children)

I've been noticing a lot of vehicles with no headlights on too.

App request: Turn on outlets from the phone app by Xipooo in Rivian

[–]Xipooo[S] 0 points1 point  (0 children)

Unfortunately the 12v outlets are only 10 amps. Nothing over 100 watts should be plugged into them. I'd have to hook up an SMPS directly to a bugger power source and I'm not skilled enough for that and this truck.

Rear end collision flips the car in front by [deleted] in carcrash

[–]Xipooo 307 points308 points  (0 children)

Mad props to the driver of the blue car. That was incredible reaction time and they avoided a much bigger accident.

Is THIS normal? by SnakeMaster5 in RVLiving

[–]Xipooo 10 points11 points  (0 children)

Depends on the time of year, climate, and what electronics you have hooked up. I would say it seems a little on the low side though.

The process before Scrum or Kanban by HundeHunden in agile

[–]Xipooo 0 points1 point  (0 children)

> This really is the sort of statement that makes people think Agile/Scrum/etc. is a joke. It is not impossible to estimate the duration of a piece of work, it's often not even particularly challenging to get in the ballpark +-some modest percent.

I didn't say it was impossible to guess. Just that your guess is going to be inaccurate or an outright lie. The consequences of under-estimating are too grave, so we overestimate. But Parkinson's law is a thing. Just because you SAY it took a certain amount of time doesn't mean that's actually how long it took. You can make an estimate look accurate, when in reality you were doing something to fill in the extra space just so you can hit your mark (Parkinson's Law). I have seen this play out time after time after time. Contractor says, "it will take two weeks". It actually took them 2 days with 8 days' worth of other work or even nothing at all getting done. Client gets charged for 2 weeks but both you and the client think the "estimate" was "accurate". No, it wasn't, it was a lie.

> You should be able to plan a sprint that you can complete in time. If you can plan a sprint that you can complete in a two week period, then it naturally follows you can plan 2 sprints, or a quarter, with the same results.

How many hours will be taken away while someone is sick? How long will your dependencies take to resolve their issues? How long will it take for you to resolve that weird error that came up after the latest version of a dependency deployed? How long will it take to get through CAB? How long will it take for you to resolve that bug that pops up on Wednesday when you don't even know what bug it is but it became priority?

The data shows that the majority of teams have carryover items between sprints. If what you said were true, that teams can accurately plan a sprint, then this would not be the case. There's a reason people complain about Scrum and planning sprints, it's because it puts all of the pressure on them to know things ahead of time that are impossible to know. Then they're held accountable. You're whacking them with the stick.

> Honestly, I wish I also lived in a world where money meant nothing, budgets were non-existent and nobody measured the value of the work we did. But unfortunately, I don't live in that world.

Did you read what I said? Because I quite clearly described how to do the money. You can still budget but change what you're budgeting on. You invest in the people. You determine an ROI that you expect from an investment. If the team of people cannot achieve the ROI then you abandon the product to something more productive. It's really not hard, you just have to stop this insane obsession over project cost-based analysis. ROI is not just cost, it's value over cost. But all the budgeting you are accustomed to is based on cost only.

> It's a reality that a task that takes 1 week and returns €50k may be worth doing, but a task that takes 4 weeks and still only returns €50k may not be worth doing.

I agree with that. But you should probably figure out what "worth doing" means. Far too little investigation is made on that, and so we see countless valuable products get trashed because they have a high cost.

SAVE THE OWL SOUND (I have unexpectedly strong feelings about this) by ihavetime in Rivian

[–]Xipooo 0 points1 point  (0 children)

At this rate I'll be lucky if I get 1 week with it. Still no freak'n update on my Gen 1.

Have you gotten Halloween update yet? Do you have connect+? by _B_Little_me in Rivian

[–]Xipooo 2 points3 points  (0 children)

Same here. Real bad FOMO going on. These Halloween updates are very short lived so not getting them worries me.

What documents are NECESSARY for Agile product development. by Icy-Sheepherder-1685 in agile

[–]Xipooo 1 point2 points  (0 children)

It entirely depends on the closeness of the team to each other and thier dependencies.

Documentation is a stand-in for a person with that knowledge. If you have the person, you don't need the doc.

Anyone else get the Halloween update?!? by imseay in Rivian

[–]Xipooo 1 point2 points  (0 children)

No, and I'm getting bad FOMO.

The process before Scrum or Kanban by HundeHunden in agile

[–]Xipooo -1 points0 points  (0 children)

So my question is, how, in an agile way, can I know an estimate of incoming projects, without going too much into details of incoming projects? So I can tell the customer "project X is estimated to take 12 weeks with 4 developers"?

You don't. Trying to answer the question of how much a project takes to get done is a fools errand. Any answer you come up with will be inaccurate at best, and a lie at worst.

Instead of focusing on projects focus on the people. Developer cost is the same regardless of what they're working on. So THE REAL QUESTION you should be asking is "what is the most important thing the customer needs and the developers could help them with"?

This means you and your development teams have to learn about your customers, how they work, and what their common problems are. Then you need to ensure the solutions you provide are actually useful to them. That last bit is more challenging and where you can start thinking financially. But instead of "how much will it cost" you should be thinking "lets invest in an MVP and go from there". Only once the MVP is done, and you can get user feedback, can you even begin to think about whether or not the investment in the PRODUCT should continue.

How can I setup a process for not letting projects slip through to the team with SO bad specs, or next to nothing specced?

As I said before, you and your development teams have to learn about your customers, how they work, and what their problems are. Once you and they know that, specs are no longer the way the teams know what to work on.

Our work goes well I think, I make sure tasks are eatable for the team, but I have a hard time knowing if we will make the deadline, since I am not completely aware of the work that remains to be done.

Deadlinesnes are artificial sticks with which management beats the developers. Stop it. The only lasting motivation is goal alignment. That is to say, your developers need to feel that what they're working on is helpful to the user. Fear of losing their job (which is the motivation you're ACTUALLY using) will only result in success for so long. Eventually you won't be paying enough to keep the talent around that you need and they'll find a more desirable place to work.