The "Expect the unexpected" part of this is, frankly speaking, bullshit. It has sentences that are a contradiction in terms, like "Planning should reflect an unplanned work allocation".
The problem is that if you put aside, say 20% of time for unplanned work, this is effectively broadcasting to all the teams around you "Oh, we have planned 20% downtime", and they will feel extra vindicated in asking you to do stuff for them as part of this "unplanned work". This is in addition to the bevy of middle manager vanity meetings, all-hands, quarterly meetings, and a bevy of other useless meetings that managers seem to be able to put on their developers' calendars seemingly on a whim.
The only correct advice, and one that is not put into this because it is unpalatable to someone posting "thoughts on leadership" is to push back hard on "unplanned work" in addition to leaving some slack time in planning. Otherwise you will end up with the typical developer who feels constantly threatened by management and has one foot out the door.
Another option I like is shortening the planning horizon. That way, you actually get to plan a lot of what otherwise count as unplanned work.
If you try to plan the next three months ahead of time, you'll either be doing a lot of unplanned work or doggedly sticking to a plan that's out of date and ineffective.
If you try to plan for the next two weeks, you actually have a small chance of accounting for what's going to happen in this period. In some industries, you have to make that two days.
I think Reinertsen uses the example of searching for a submarine. The area it can be in after one sighting grows with the square of time (it's a circle whose radius is determined by speed.) If you haven't found it within a few hours of sighting, you might as well give up because by that time the search area expands faster than you can conduct a search. Planning is similar.
I have a similar take on stuff pushed onto the dev team. I think it’s often not the unplannedness of this work that’s at the root of the problem but its low value.
Pushing back against actually important unplanned work would be harmful — and usually nobody does that, which shows that it’s not actually about planning.
The point is, at least in my experience, many orgs have lots of other teams running around with ideas for things the dev team might do for them. Many of those are just not very important in the grand scheme of things. A lot less important, for example, than keeping the codebase healthy. But it’s usually not politically convenient to say that explicitly.
It’s much easier to “shut them up” by citing schedule pressure. Of course, this tactic backfires hard whenever there’s even a hint of downtime.
> Pushing back against actually important unplanned work would be harmful — and usually nobody does that, which shows that it’s not actually about planning.
Well, the problem often boils down to getting people to agree on importance. No, that feature built for a specific customer is not that important. No, the team cannot spend 7 days on a "design sprint" that a director just cooked up. No, maybe we can get those servers running for your team next sprint, they can share their existing servers until then.
The problem is that if you put aside, say 20% of time for unplanned work, this is effectively broadcasting to all the teams around you "Oh, we have planned 20% downtime", and they will feel extra vindicated in asking you to do stuff for them as part of this "unplanned work". This is in addition to the bevy of middle manager vanity meetings, all-hands, quarterly meetings, and a bevy of other useless meetings that managers seem to be able to put on their developers' calendars seemingly on a whim.
The only correct advice, and one that is not put into this because it is unpalatable to someone posting "thoughts on leadership" is to push back hard on "unplanned work" in addition to leaving some slack time in planning. Otherwise you will end up with the typical developer who feels constantly threatened by management and has one foot out the door.