(1) This is part of blameless culture, and it can't work without everyone being bought in, so once it is established and working culturally it doesn't matter if

(1) This is part of blameless culture, and it can't work without everyone being bought in, so once it is established and working culturally it doesn't matter if one person on the team changes. In the same way that we "hold people accountable for incidents" by reviewing them and discussing what we could learn, we do "hold people accountable for their estimates" by asking what happened and reflecting on whether we could have seen that coming. But we're never perfect and we don't expect to be, we just try to see if we can get better over time. (2) When something unexpected comes in you flag it and report it to everyone so everyone knows the expectations are invalidated. This is super important! I can't even tell you how much easier it is for a PM or other stakeholder to handle learning on Tuesday that the plan is not going to work than showing up for a check-in the next Monday expecting to see some deliverable and only then learning that it's late. The goal is to communicate expectation changes as close to real-time as possible, which builds trust and also helps the non developers see how volatile and unpredictable development can be so they learn to believe you when you say "the range is 10 to 30 weeks, and no I can't narrow it down any more than that."