Agile Management | NOOP.NL

My Time Registration Experiment

I learned that personal time registration didn't add much value to what I already do every day.

Two weeks ago I told you I was going to measure the time I spend on my work, in the hope of learning a bit more about myself. And so I did. For two whole weeks I tracked all my activities and the time I spent on them.

It was harder, and more annoying, than I thought. My original plan was to do this for a month. But after two weeks I was sick and tired of clicking the start/stop timer on my smartphone, and I decided to cut the sample size in half, hoping that the data I collected so far was useful enough already.

These are the (aggregated) results:

Eating	5%
Communicating	10%
Socializing	11%
Traveling	14%
Learning	16%
Teaching	23%
Publishing	5%
Presenting	6%
Other	10%

Learning from Experimentation

These are my conclusions:

• I spend 10% of my time communicating online (email, Twitter, chat and phone). This is just what I expected, and it’s fine as it is.
• I spend 11% of my time socializing with people face-to-face, in meetings, conferences, and hotel bars. No problems there either.
• About 14% of my time is wasted on traveling. That is time I actually waste doing nothing. (When I read during my travels I counted it as learning.) The waste of traveling is more than I expected!
• About 16% of my time is spent on learning. Most of that is spent on reading books. A small part consists of conference sessions.
• I spend no less than 23% of my time teaching. That number is a bit high because I did 2 courses in these 2 weeks, while I do 3 on average in a whole month.
• I spend only 5% developing and writing materials, including courseware, games, articles and blog posts. This is not enough!
• About 6% is spent on presenting at conferences, and everything that is needed to prepare the presentations, and provide aftercare for my victims audiences. No problems there.
• The remainder, about 10%, involves many tasks that are too diverse and small to categorize separately. Some of that stuff I could probably do more efficiently, but there’s little to gain from this category.

So, what did I learn?

The time I waste on traveling is too high, while the time I spend on publishing is too low. Everything else is more or less fine. This means that I now have a new challenge: find more effective ways to write and develop materials while I’m traveling, so that the time I spend writing blog posts in security lines, and drawing illustrations in taxis, counts as publishing and not as traveling. Your suggestions are appreciated! :)

Meta-level Learning

On a meta-level: Though the findings are interesting, I find the results of my time tracking not as revealing and surprising as I had expected. The effort of time tracking did not give me the return on investment I had hoped for. And it also did not help me to achieve better levels of self-reflection, which was my original intention.

Important: Time tracking can be still useful for you! My friends know me to be a very focused and disciplined person. (Sometimes even too much so.) The fact that I didn’t get much out of personal time tracking might mean I’m already quite efficient and effective at what I do. But I don’t know about you. ;-)

I thought this experiment could work for me, but unfortunately it didn’t. I’ll move on to the next one…

So, how do you try and learn how to improve your daily activities? 

(Jurgen Appelo is author of Management 3.0, a best-selling management book for Agile developers. It has a picture of a monster in it.)

The Timing of Requirements

Monitoring the customer's wish list (or the backlog of requirements) is an important part of a project manager's job. Agile methods have taught us to defer decisions and to keep inventory low, meaning that you should work only on a few requirements with highest priority, and keep other feature requests at bay when people are still uncertain about their necessity. However, you must take care not to ignore the other part of the story: don't wait too long!

I'm a book maniac. My Amazon wish list is like a second home to me. I buy so many books that I'm surprised Amazon hasn't yet named one of their buildings after me. This week my shopping spree has reached a new climax, with 19 new books now on their way to The Netherlands. (I apologize for any problems my order might cause in regular transatlantic air traffic.)

The reason I placed such a large order is that, for a couple of other books on my wish list I simply waited too long! Some books I wanted appear to have been sold out by now. This means I will have to buy them used (which I hate) or I must try to find them on other markets, which is likely to cost me more. And for other books on my wish list Amazon has increased the price significantly, either because the books are becoming rare, or else because because Amazon is evil-minded and they know --from my earlier shopping behavior-- that I'm going to buy them anyway.

In software development projects we can experience similar situations. I have seen the licenses of 3rd party components suddenly becoming much more expensive. This usually happens two days before we decide to buy them. Other times the implementation of features cost us significantly more time than they would have cost us originally, because of new interdependencies with other parts of the projects. In these cases a different order of implementation could have saved us a lot of time.

It is often hard to determine the proper timing for anything you do. I not only buy my books too late. I usually buy them too soon. It's a pity I don't have a fireplace, because there are a couple of books that I would gladly throw in. (I would even want to piss on them first, but that would make them harder to burn.) Unfortunately, based on raving reviews --apparently written by raving lunatics-- I had already bought the sequels to these soon-to-be-burned-and-possibly-pissed-on books. A clear case of bad timing on my part.

Monitoring a wish list (whether it is a requirements backlog or a wish list on Amazon) is like monitoring a stock market. Acting too soon is costly, but you must take care not to underestimate the cost of acting too late.

Tell me, when did you act too late?

MoSCoW Priorities

We are giving up on MoSCoW. And by that I mean the prioritization approach promoted by DSDM, not the Russian city. -- I had already given up on the latter many years ago. -- The MoSCoW approach in software development is used by many to decide which requirements should go into which timebox. The letters stand for the following priorities:

M - MUST have this.
S - SHOULD have this if at all possible.
C - COULD have this if it does not affect anything else.
W - WON'T have this time but WOULD like in the future.

The argument for using MoSCoW over an old-fashioned numbered system, according to the DSDM evangelists, is that simple priorities like 1, 2, 3 and 4 are flawed as it results in all elements being assigned priority number 1 by the customer.

However, after having tried the MoSCoW method for about a year, the feedback I got from our consultants is this: "It doesn't work because all features are being assigned the Must Have priority. Our customers are of the opinion that everything is essential."

The problem is not much different in our support and maintenance arena. There we work with priorities named ShowStopper, High, Medium and Low. Now guess which priority our customers often assign to their issues... We could just as well use priorities named ExtremelyCrucial, IgnoreThis, IgnoreThisToo and SmellyBananas. It wouldn't make much of a difference, I'm afraid.

We already know that most ShowStopper and MustHave requirements usually turn out to be not crucial at all. But there's a big difference between knowing and telling the customer. In Moscow (the city, not the method) it is quite normal to tell others (particularly other nations): "Well boohoohoo... too bad you think you need gas, you're simply not gonna get it!" Unfortunately, the approach in our part of the world needs to be a bit more subtle.

The best solution might be to use some sort of a priority ladder, or priority queue. Customers can rearrange the requirements in the queue at any time, but as soon as the next iteration starts we take the top X items that will fit the timebox. Of course, this is very similar to the planning game exercised in XP. But with the added benefit that, of those X items we take from the queue, we still know their relative priorities.

We are going to try this idea and I will let you know someday if it worked. But for now I'm going to stay clear of Moscow for a while (both the method and the city)...