emeraldd

Seriously though, there's enough energy in those numbers to seriously mess you or your electronics up. It's not quite like a bottle of old nitroglycerin, but it's definitely enough energy/power that you must respect it.

Hope it holds up!

That was a reply to "...but for many the accountability of Scrum..." in the parent comment. There's an idea that Scrum creates accountability by making it possible to measure how well a team is meeting their commitments. It really doesn't. The metrics that Scrum exposes are little more than semi-random numbers. You're asked as a team to "commit to completing" some mostly arbitrary total of these numbers that has been determined to be your teams "capacity".

The entire premise of this kind of estimation is fallacious on face. It completely ignores the skill level, overall capabilities, and specializations of your developers and effectively equates them to an common minimum of mediocrity. Worse, it pre-supposes that your team fully understands all of the places that a particular task can go sideways which is almost never the case.

About the only way I can see it working is a situation where you know exactly what needs to be done, step by step, from or near the very beginning of a project. Otherwise, all you're doing with Scrum is forcing the team to make decisions on a Sprinted cadence rather than at natural break points along the completion of a project. This creates artificial delays, particularly when other teams are also working on sprinted cadences because you're likely to be requesting things that won't make it into some other teams sprint. Creating at least a sprint long delay before your team can complete their work, and well, breaking your sprint goals, etc..

Sigh ... Hence the accountability and predictability that's supposed to come out of Scrum is illusory at best and usually self deception.

Of course, the counter to that is that we're not doing scrum right. The question in my mind then is if I haven't seen a single team do Scrum correctly there's something wrong that makes the methodology so difficult it can't be applied ...

The second example is harder, but not insurmountable. I would probably start with principle/credential reference of some sort that is provided to an evaluator along with a "right" reference rather than adding a method directly to users. If you keep the mechanism mostly opaque to the business code, you can retrofit more complexity into the system as the needs arise. Retrofitting that into a system get's really complicated really fast if you don't have a reasonable API to start with though.

Unfortunately, that means the observer has to be able to understand and follow what the engineers are doing while staying out of the way as much as possible. Tricky, but something you really need if for no other reason than to communicate and look for any holes that the team/person working the problem may not have thought of in the interim.

"Laws often include exceptions for price increases that can be justified in terms of the increased cost of supply, transportation, demand, or storage."

IANL Based on the above definition, it sounds like OP is not describing price gouging. Their business is not setting the price of the goods directly. The buyers are competing for a limited supply and pushing each other to bid higher amounts. That sounds like a justifiable increase.

Now, if the mill saw the emergency and said "we won't take less than cost + 45% ..." or something like that, it would likely fall into price gouging territory.

tank - can soak up damage and keep the big bad focused on them dps - does damage to the target while healer - makes sure everyone stays "alive" through the fight.

Mismatching roles never really works well. You get similar patterns in the "real world". You're people person does well with end users, etc .. It's a more diverse group (sometimes much less defined) but a similar set of ideas to follow.

> Higher fasting insulin and higher c-reactive protein confound the association between BMI and the risk of all-cause mortality. The increase in mortality that has been attributed to higher BMI is more likely due to hyperinsulinemia and inflammation rather than obesity.

From the article:

  "We're talking high-nitrogen compounds here (a specialty of Klapötke's group), and the question is not whether such things are going to be explosive hazards. (That's been settled by their empirical formulas, which generally look like typographical errors). The question is whether you're going to be able to get a long enough look at the material before it realizes its dream of turning into an expanding cloud of hot nitrogen gas."