"Unlimited" Vacation Misses the Point

Unlimited vacation policies are one of the less traditional management practices that seem to get a lot of talk recently. And I see a lot that seems to miss the point.

Disclaimer: I live in Germany, where laws are a bit different from the US. For example, sick days - even when you get sick during your vacation - don't count towards your regular paid time off bucket. I think the principles that I'll describe still should hold true, though.

What traditional vacation policies really do is define a paid time off budget. Someone, sometime figured out what he thought was a "fair" amount of time per year, and that's what you get. Maybe even a little more, depending on your employer and negotiation skills.

Makes sense? Well, let's do a thought experiment: imagine being self-employed. Imagine that someone - maybe the government - tells you that you should take exactly x days of vacation a year. Still makes sense?

If you are anything like me, you would resist that dictate. You would want to take responsibility for finding the right balance between financial, mental and physical health - of both yourself and your family. Instead of figuring out the right balance once and for all, you would continuously adjust your plans - to your own needs, those of your family and customers, and to the development of the market.

So why does that stop once we get employed by a company? 

I think it shouldn't.

Of course, once you have colleagues and stakeholders, the whole situation becomes even more complex. A fixed time vacation policy reduces that complexity. But it also takes away your responsibility to make decisions that make sense. And that's not a good thing, in my opinion.

What would be needed for a vacation policy to work that doesn't work with a budget? In short, every employee needed to be an entrepreneur who feels equally responsible for himself and his family, his colleagues and the organization. That includes, but is not limited to (pun not intended):
  • every employee having a good understanding of his own needs, the needs of his colleagues and the organization (and being in a constant dialog about it),
  • feeling responsible for creating a good balance between those needs, in cooperation with his coworkers; as a consequence
  • a culture where coworkers hold each other accountable - not only for work results, but also for taking care of themselves, and
  • a culture where the inevitable conflicts are dealt with productively.
So, it's not about removing the limit, letting every employee have "as much vacation is you want", inside a traditional culture of "getting away with as much as I can". It's about creating a culture of "we are in this together", where - as a consequence - such a limit wouldn't make sense.

PS: if your vacation needs to be approved by a manager, you probably don't have unlimited vacation - you have a variable limit that depends on the whim of your manager.


Modeling The Real World vs. Designing Software

Technikmuseum_Speyer_12I started writing a response to comments on a previous blog post, and it turned out long enough to become its own post. The question was on whether you should relationships in the "real world" to decide on relationships in your object-oriented designs.

"Is-a" and "part-of" are concepts from object oriented analysis, where you try to model "the real world" in terms of classes and objects. That is, by looking at the problem you are trying to solve, you could come to the conclusion that a customer "is-a" person, and that a street name is "part-of" an address.

In the early days of object orientation, it was assumed that you could simply transfer the relationships you found in that analysis directly into your design for good results.

There are (at least) three reasons why this doesn't generally work well, in my experience:

  • when we analyze the "real world", we typically model the problem space. When we design software, we model the solution space. Although there are often similarities between the two, there is no direct mapping - in fact, finding a good model for the solution is the most creative (and important) act in developing software. Assuming that an "is-a" relationship in the problem space will directly translate into inheritance in our solution space needlessly restricts our creativity, and thereby leads to inferior solutions.

  • for me, the primary goal of software design is to manage dependencies in the design, so that the resulting system is maintainable and extensible (because successful software is software that will need to be changed). As a consequence, there are forces working on our designs that don't exist in the "real world", and therefore considering just "real world" relationships won't help managing those forces. Just take the famous "a circle is an ellipse" example: while true in mathematics, depending on what you need a system to do, reflecting this relationship in your design can violate Liskov's Substitution Principle, and thereby lead to brittleness and unnecessary complexity. That is, a relationship that is absolutely natural in the problem space leads to problems when transferred as-is into the solution space. Another example: both a customer and an administrator are persons, but that commonality could be totally irrelevant to the solution of your problem, and then modeling it in your design would be a waste, at best.

  • in the English language, there is no unambiguous rule about when to use which phrase, anyway. Yes, you could say a customer "is-a" person. You could as well say that personal information is "part-of" a customer. Or that a person "has-a" role of being a customer. It can even make sense to say that "a person is a customer". So you really can't use natural language semantics to decide which relationship to use in your code.

So, using those relationship names doesn't really take the burden off your shoulder to choose wisely which relationship makes the most sense in your specific case. And an experienced designer will - whether explicitly or by gut feel - choose the relationship that leads to the most SOLID design. and he knows how to refactor to a different relationship when his understanding of the forces in the code changes.


An Agenda for Backlog Grooming

London Zoo - The Hairdresser
When training and coaching teams to use Scrum, I'm starting to put more emphasis on Backlog Grooming - having the whole team maintain the Product Backlog during the Sprint, so that it remains in good shape, the team keeps a grip on the vision for the project, and there are no unpleasant surprises when it comes to Sprint Planning.

Inspired by "Collaboration Explained" and Roman Pichler's blog post, I created a general purpose agenda for backlog grooming, that so far has worked quite well:

  • Opening - help people arrive physically and mentally, review the agenda, do a quick round robin check in, review actions from last grooming.
  • New Learnings - what have we learned that we want to capture in the Product Backlog? Ideas for new stories, obsolete stories, significant changes to content, estimates or priorities?
  • Prepare for Next Sprint - identify the stories that should go into the next Sprint Planning and make sure they will be prepared according to the Definition of Ready.
  • Identify Stakeholders and Dependencies for Next Sprint - focus on the question: looking at the stories selected for the next Sprint Planning, who needs to be invited to that planning meeting?
  • Risks for Upcoming Sprints - looking further ahead, what are the upcoming risks? Which of them should be addressed now, and how - for example by splitting stories, by scheduling investigations, spikes etc.?
  • Closing - any open ends that need to be addressed? Review Action Plan. Mini-Retrospective, e.g. Plus/Delta.
What are your thoughts on this agenda? What do you do in Backlog Grooming? How would you change this agenda for your team(s)?