Don't work more: work better

Sustainable pace is one of the practices of XP; having provided the link, and assuming you know what it is, I won't further indulge on the subject. Why am I talking about it then?

Because, thanks to Paolo, I am reading The Little Big Things by Tom Peters, and I stumbled upon the following sentences (re-translated in English from the Italian version), that according to the author apply in hard times as well as in good ones:

• Get to work earlier than usual.
  
• Leave later than usual.
• Work more.
• Volunteer to do more.

Now. This sounds quite different from sustainable pace. It also sounds different from the slack periods that the very same author reports as very important just a few pages earlier.

Why should we work more? I can understand that arriving earlier and leaving later leaves you some time all by yourself in the office, which is when you tipically can perform better because you can get some uninterrupted quality time. But you cannot count on such a short amount of time to complete everything you're supposed to do during a whole day.

And how about your canonical eight hours? Are they all wasted as "the big slack time between early morning and late evening"? Nope, you're supposed to work. Does this come as a surprise? That's very strange, because it is precisely what you are being paid for. So why add the extra hours? You're not being more productive, you're just spending more time at the desk. No, really, Peters goes as far as saying "work more for less". No way. At least, things being as they are now.

Let's get back to sustainable time. Suppose you're a workaholic: you spend at least 12 hours a day at the office, trying to compensate with brute force for your laziness. You are often so tired that your judgment is hiding somewhere under your shoes, and you can't tell whether you still have to bang your head on the wall on little and useless details or you can pass to something else. Or, better yet, call it a day. This is not committment, this is a physical dependency. How long do you think you can sustain it before reaching a burnout? Not very much. You're doomed. And you've wasted your time, not to mention the money of your employer.

Moreover, this is also very bad for morale: not only yours, as you obtain very little despite your enormous efforts, but also of the people surrounding you. People will start feeling guilty because they work less than you do, so they'll feel compelled to stay just because you do, even if they don't have anything to do but keep their chairs warm. Isn't that absurd? Yet, here in Italy you are too often judged by the time you spend at your desk. Even if you don't produce anything worth your time.

I'm sure Mr. Peters didn't mean "waste your day spending more time at the office", but unluckily it is exactly what is going to happen.

Get yourself a life! Strive for excellence, and work better: if you do it you will achieve the same results in less time. Absurd? Yes, it is: actually you will get much better results in much less time.

A simplified example for programmers? concentrate and try to make your code easily readable, not only by you but also by other people (which also means you, as you will not even remember you wrote that piece of code in a couple of months). Write automated tests. Refactor. Eliminate duplications. Do I hear "it will take more"? Yes, it will take more. But just on the barrelhead. As I read today on twitter:

Programming is like sex: one mistake and you’re providing support for a lifetime. (Michael Sinz)

Do your maths...

Gmail Notify plugin

Let me start with a disclaimer: this post is not against the tool, but against what I see as a toxic habit.

This NetBeans plugin enables notification in the IDE when new Gmail messages become available. I am sure many people will find it very useful, yet I am trying to draw my personal battle line. We are overwhelmed by distractions, and adding another one would only worsen the situation.

Do I really need to check that e-mail immediately, or can I safely ignore it for another 15 minutes? If you use the pomodoro technique you organize your work in short 25 minutes stints, so the average delay is absolutely trifling. The same holds true if you use similar time management techniques.

Interruptions break your flow, and getting back to what you were doing becomes increasingly hard. That's why you should strive to manage interruptions, not to be ruled by them. A notifier is an interruption, and as such should be dealt with.

I normally check my e-mail(s) between pomodoros, and that's not a secret for anyone: I am not at the service desk, so my "flow" periods are not 5 minutes bursts: there are days in which I don't even check the trouble ticketing system. I admit this could sound excessive, but there are many other brilliant people on the responsibility chain before me, and this could loosen the stiffness in your back a little. I am confident that if a pressing situation arises I'll be reached by a telephone call, and if the situation requires it I'll manage the interruption catching it and trying to solve the problem as soon as possible. I'd like to say "as soon as it is needed", but you might have noticed that saying no is not so easy. It is even less so when we're saying no to ourselves.

Yet, if we want to put the most precious resource we have to good use, we have to learn how to do it.

Sustainable pace?

Always been one of my favourite practices. Too bad I fail to practice it more often than I'd like to... 7 extra hours in three days, up to 2 a.m. on Sunday morning and a holiday spent working. There's really a lot of space for improvement!

Sustainable pace

I read a discussion about Sustainable Pace, one of XP's practices, in which the contributors try to relate the subject with a fixed number of hours per week. Literature (based on extensive studies) shows that there is no linear relationship between productivity and hours worked, and I quite agree with that; moreover, there's a law (you will forgive me, but I don't have the reference at hand) that states that if you have a certain amount of time to do a job this will expand to fill the whole time slot available. Sistematically working overtime does not increase productivity in the long run (not even in the medium run); one of the (many) reasons is that software production has nothing to do with traditional industrial processes. My personal opinion on that is that more hours do not guarantee an extra productivity; nonetheless under exceptional circumstances (which is to say not every week) extra hours can be invaluable.

Here in Italy the "normal" working week is based on forty hours over five days. A contributor enthusiastically sustains that one extra hour a day guarantees "more than one month of extra development time during a year!"... or does it? I strongly disagree.

It's not unwillingness to work, or (better) unwillingness to get the job done; it's about commitments and balance between work and private life. In an agile enviromnemt you only plan for the next (very) few weeks, so the estimates are much more accurate and, as the project goes on, you have a pretty good knowledge of your productivity: that allows you to commit to a fair amount of work without steadily subtracting time to your private life. An extra hour in the office is an hour in which I can't play with my children, talk to my wife, read a good book, oble a new biscum or burble the tramling (Cockburn readers might get the reference) or whatever. That can lead to a burnout, thus resulting in a great loss of productivity. I already spend more time with my colleagues than with my family, and I think there's really no need to make things worse.

Besides... how many people on their death bed say "I regret I have not spent enough time working extra hours..."?

Agile Estimating and Planning

Yesterday I finished reading Agile Estimating and Planning by Mike Cohn. I found it quite interesting, even if id didn't add very much to what I had found in other readings; the good thing is that the whole process is explained, delving into different aspects (some of which are too lightly touched, in my opinion).

Estimating in Ideal days

When it comes to estimating you have different options to pick from; two of the most common are ideal days and story points, each of which has its own strenghts and weaknesses. One of the worst weakness of the ideal days method is that an "ideal day" means very different things to different people; moreover, different team members give very different estimates depending on their relative skills, so you can have a very wide range of estimates for a single item to deliver (call it use case, user story, feature, you name it).

If you're used to ideal days estimating and decide to stick with it, there are some tips that can help you to reduce the risk associated with the method.

The first (and obvious? unluckily not so much...) tip is to let who will actually develop the software do the estimate. Managers do not have enough informations, so they must trust the team. After all, a great slice of management work is to select collaborators, so if a manager trusts himself (and you bet she does) she must trust the people she has chosen as well.

Moreover, more than a single member should estimate the same item; actually the whole team should do it, thus exposing - early - different points of view; more often than not, if somebody estimated an item much less than other members she forgot something or did not considerate all the implications of the item: the key to effectiveness of this practice is the constructive dialogue between developers. A particular way to do it is planning poker: all developers have a deck of cards, each of which indicates a valid estimate; a moderator reads an item from the list to be estimated and each developer choses a card, then everyone turns up their card at the same time. If the estimates are more or less alike there is a short conversation and an agreement is reached, otherwise there can be a deeper discussion, after which there is a new turn.

A deeper problem emerges when developers are differently skilled: they might agree on the relative size of the items, but their estimates will differ greatly; an item which would take an experienced developer two days could require ten from an inexperienced one. On the contrary, if all developers in a team have more or less the same skills they can ignore the problem. If that is not your case (and surely - and unluckily - it is not mine) you have to deal with the problem of scheduling also: if you estimate on the experienced developer's words you have to assume that she will do the work, but you cannot have the guarantee that when the time comes she will be available, so you'll have to spend ten days but you can bill for only two of them; if you choose to take the estimate of the inexperienced developer the customer could complain because your team costs too much. In this cases I normally estimate somewhere in the middle and do all I can to have the two developers pair on the item to leverage knowledge and experience.

Last but not least, ideal days are different for different people: someone consider ideal days as "eight hours focused on a single task", someone else as "six hours focused on a single task, plus a couple of hours on different things". Obviously that brings to different results, and the bigger the project the worse the outcome. That also clashes with scheduling, because people should manage their time but that is not always easy, particularly regarding how to deal with (internal and external) interruptions. To deal with this risk you have to know the velocity of your team members and of your team as a whole, so that you can translate their estimates into sufficiently reliable schedules.

Most of the advices are also useful for estimating with story points.

Where do you (want to) go today?

This morning, like almost every working day, I sat at my desk and wrote down a list of activities, then started my first pomodoro (see here for more informations). Then I got a lot of unmanageable interruptions, and all my good intentions vanished away (CIO beats planned activities list for the nth time running). That lead me to think, once again, how we manage our time and how we're too often distracted from our real objectives.

Objectives can be divided in fundamental, qualifying and desirable. Fundamental objectives often span over a long time period, so we have the tendency to have an "I'll set it aside and deal with it later" attitude. We MUST ensure that our fundamental objectives are reached; qualyfing objectives help us get there, and desirabile objectives are... desirable, but expendable.

Our daily activities fall in two different categories: urgent activities and important activities. Too often we get distracted by urgent activities, which seldom get us closer to our objectives; one common mistake is to decide to deal with all the small urgent matters, "so we'll get rid of all this unimportant stuff", and to postpone important activities. Than can happen for various reasons, but it does happen. And in the end of the day we're not closer to what is really important than we were the day before. Sounds familiar? you're in good company.

We must learn to recognize which activities are important to us, and to delegate or reject the others. That is particulary important if you have a management position: for example, if one of your collaborators comes in your office with a monkey on her back, she must get out carrying the very same monkey. That does not mean you should not help her: you should give everyone the support they need to carry on, but you must not do their job. As a manager, you "manage". And coach, and mentor, and support, and many other things. That will help your collaborators to grow, and they will also know you trust they will get the job done. Learn to prioritize activities not by their urgency but by their importance. And, most of all, keep some spare time in your daily plan to extinguish all those little fires. If you follow these simple rules, your time management will be more effective, and your productivity will improve. Unluckily, sometimes you just have to cope with the circumstances: we cannot avoid all risks, but at least we can reduce threats to our objectives.

The activities I had to perform today are of no importance to me, but they have a great importance to someone else. Someone you can't say no to. That's where the spare time comes in action... I satisfied my manager and went on with my own list. I had to "sacrifice" some of my time, but in the end the outcome required by my fundamental objectives will not be far from the expectations; that also helps you to schedule your activities in such a way to respect your deadlines.

"Deadlines? I love deadlines... most of all, I love the swooshing sound they make as they go by"