GH have forks. Those are distributed repos. You can also sync to GitLab and similar, you can front it with the likes of Gerrit, integrate some code review UIs that actually clone code, etc.
You can exercise distributed nature of git with GitHub quite well.
There is huge array of alternatives between git-flow and trunk based development.
Most still miss on benefits TBD and CI bring.
Companies settle in the middle because git-flow is very specialized branching strategy. You almost need physically sold software (but that's still not enough!).
Except they do but just like pretty much every other insurance it does not cover everything and the payout has a maximum.
For example here in Finland the nuclear plants are required by law to get an insurance that covers up to 732 million euros (~1.2 billion euros in Sweden) of "third party damages" (they can buy additional insurances that covers damages to the plant itself). If that is not enough then government will take care of the next 500 million after that. If that is still not enough then the company is liable for the rest which effectively means they will go bankrupt as usually the only assets they have is the nuclear power plants.
This does mean that at the very end government will have to pay for it if the accident is big enough but gets to keep all the left over assets of the company.
They buy the insurance from this company https://atompool.org/en that is a consortium of multiple insurance companies that operate in the nordics. And there is multiple of these nuclear insurance pools around the world and they all reinsure each other.
Another question related to this is why don't big dams etc need similar insurances (at least here in Finland they don't). When things go wrong the damages can be just as big if not bigger.
> If that is still not enough then the company is liable for the rest which effectively means they will go bankrupt as usually the only assets they have is the nuclear power plants.
In my experience and almost without exception large capital projects are "owned" by a single company .. that company having as major shareholders the partners or parent company that put everything together to make the project happen.
Eg. a massive copper mine project in Canada | South America | etc that appears in the Rio Tinto annual finnacial reports is owned and managed by the locally registered RTCopperCutout Company.
No suprise that this happens with nuclear capital also, but worthy of a mention for anyone not already aware.
Sometimes the parent company | shareholders can be held to further account but not always.
Yeah in Finland Fortum owns Fortum Power and Heat that owns the 2 reactors in Loviisa and ~25% of TVO.
TVO is the other nuclear company that owns the 3 reactors in Olkiluoto. The other owners of TVO is Pohjolan Voima with ~60% which is owned by the wood/paper companies UPM-Kymmene and Stora-Enso together with a bunch of smaller municipal power companies. Helen (fully owned by Helsinki city) also owns the last ~15% of TVO though its subsidiary Oy Mankala Ab.
Importantly in Finland this ownership structure also plays into how the plants operate. In the case of TVO it does not directly sell its power to end users but to its owners at cost (who are also mandated to buy it) who then use it themselves or sell it forwards.
Have you tried to just track time on board / time on column on each task on Kanban board?
You just need to keep track of time to trigger those discussions.
You can technically do everything with both tools, but each is optimized for a particular situation. They're so closely related that many people think of them as competing alternatives rather than as situational alternatives.
In Kanban you multiply cycle time by tasks and do some modeling on that value. Only difference is that in SCRUM whole team does produce raw value upfront of work, while in Kanban manager computes raw value downward of work.
Raw value here refers to lack of statistical analysis.
I think you where sold on "scrum is all you need"lie.
Kanban isn't there to dictate process, but as a tool to correctly and truthfully inspect your process.
E.g. we recently used length of UAT column to prove that we need more business people doing testing in next few weeks as we close to feature release and more tests take form of exploratory testing.
Scrum isn't blind to benefits of such inspections either! So doing simplified Kanban board is frequent.
But I do wonder if it just encourages people not to bring up real problems so that they can skip a meeting.
I think having the board up at all times is a great idea though. Just have to have some way to figure out "is it empty because things are fine or is it empty because no one cares anymore".
Relative comparison is exactly the scrum method which is why they don't estimate with time. And I don't think revenue estimation is any less subject to variance.
