That policy is crap.
Any time someone takes vacation their team is going to move a bit slower on the current project. Commitments should be built around vacation, not the other way around.
Any time someone takes vacation their team is going to move a bit slower on the current project. Commitments should be built around vacation, not the other way around.
Why we know this isn't "crap".
Commitments are built around Vacation AND Vacations are built around commitments. It doesn't have to be an either/or proposition and here is why:
We apply Agile and the management aspect of our company uses Scrum. The teams are self-organizing. This even includes who is hired into the team and who is fired from the team. The team commits to an amount of work (it isn't forced on them by management).
This commitment process is very well defined in Scrum through the iteration planning meeting. If someone wants to take time off to go on vacation, then during the planning meeting (and hopefully they talked about it with their team members before), they let the team and product owner know at the start of the planning meeting (every team member, as Scrum requires, let's everyone know the number of hours they have available to commit directly to the current log).
In this case - Commitments are built around vacation.
On the other hand, the team has been given the authority and responsible of getting out potentially shippable product increments (a part of Scrum). The team, as a whole, has taken on this responsibility so, as a whole, must take that into consideration when taking time off.
In this case - Vacations are built around commitments.
Our approach to time-off and vacation aligns quite nicely with the Agile process and, in my opinion, is an other example of why Agile (and Scrum in this case) is such an amazing way to manage the production of software.