Work – Seite 2 – Here Be Subtlety

I Miss My Commute

I recently read a short blog post at 37signals about the glory of not having to commute. While reading this post and the comments made, I was reminded once more of a feeling I have quite regularly:

I miss my commute.

Seriously, what I wouldn’t give for a solid 30 minute train ride to work and back. The problem that I have is that my commute is too short and I feel like it’s such a waste of time, because I get nothing done except maybe a bit of listening to podcasts.

Now, I have been an avid commuter for the last eight years or so. I had to travel from Bonn to Cologne for about one and a half years, before we moved to Leverkusen, which made my commute to work a bit shorter, but still long enough to spend reading. Even when I worked in Leverkusen for two years, I preferred the longer bus ride to taking the train, because it gave me a bit of time to read or listen to music.

Sure, we moved here because of my job and in theory the idea of only being one train stop away from work sounded great, but I sometimes end up taking the streetcar which takes more than five times as long, but apart from stopping a bit closer to where we live also allows me to sit and relax for 15 minutes.

Now, I know that commuting can suck. I know about having to wait for late trains, missing connections, sprinting up and down stairs to the platform just to get there in time, freezing in winter or being rained upon in autumn. I have never really commuted by car though, so I can’t really share any stories about that. On the other hand, I also don’t get why people would commute by car when there is decent public transportation.

Fact is that I think I never read as much as I did the nine months that I took the train from Leverkusen to Düsseldorf each day. This was a one hour train ride each way – which is also what I consider the longest a commute should be – and I got so much reading done during that time, it was simply amazing. The key to a good commute is not having to change trains more than once (or maybe twice) and spending the majority of the time in one train, so you can just sit down, relax, and do what you want to do.

I seriously feel deprived of this sacred alone time. Alas, if you don’t like to read, listen to music, podcasts, watching videos or playing with your notebook, then a commute might not be the thing for you. For us people who do like these things, 30 minutes on a train can be the time of the day where we can for once relax a bit, because it is the only time where you might not be distracted by this and that and just able to concentrate on these things we like to do.

Oh man. I miss my commute.

Don’t Call it Scrum.

We’ve been practicing Scrum at work for about nine month now. We got from one team to two teams and will be moving back to one team in a short time (although not really, but more about that later).

We’ve been constantly redefining the process. Sometimes it was little changes like coming up with a few easy rules to make daily scrums move along faster. Sometimes it was bigger changes like defining a new way to do estimation sessions.

In the near future we’ll be adding more teams to work on our product, some of which are offshore, which forced us to rethink our process. Currently nearly everyone working on the product is located in the same office, even on the same floor, so communication between Scrum teams, ScrumMasters and product owners as well as others involved in building the system has been easy and uncomplicated. This won’t be the case once we have teams in another country or even another continent.

One key change that has already been made is that the design phase has been dis-integrated from the actual work of the Scrum team. A designer who only recently was a member of one of the Scrum teams is now working with the product owner, defining designs for user stories.

Estimation meetings now take place with the product owner and designer present. Estimations are therefore made based on the existing design. This is not necessarily a bad thing. In fact it takes some of the risk out of the equation for Scrum teams. We no longer have to estimate something without having a design. Also, since the design is mostly made by one person in collaboration with the product owner and whoever else is of help, it ensures consistency throughout the system.

However, it makes me wonder whether we have already stopped doing Scrum and might just be doing agile. Not that this is bad in any way, it’s merely a question that I might ask. How far can you go from the process as it was defined before you have to admit to yourself that – while what you’re doing is Scrum-based – it’s not longer what you started with.

Is this a bad thing? Not really. In fact, it could come as a relief. Once you’ve drifted so far from the defined methodology that have to stop fooling yourself that you’re actually doing it, maybe it’s time to take a step back and review all the things you’re doing , re-evaluating what is working, what might need improvement and what is simply a waste of time.

On the other hand, sticking to a methodology makes you less eager to give up something that you might not like as long as you’re convinced it is a part of the methodology. (I.e. because daily scrums are such a key item in the Scrum process, you’re less likely to skip them even if you don’t like it.)

In the long run, Scrum is just a word. We might be on the brink of letting go of what makes Scrum Scrum, recognizing that we have our own agile process that has no name and probably doesn’t even need one. Whether we get there and how we will go on from there, I have no idea. But I hope it will be fun to find out.

Get Feedback When You Can

We will have a couple of training sessions soon for a bunch of developers and testers coming over from Vietnam to bravely sit through three weeks of (probably pretty hardcore) training with us. All training sessions are held by our very own developers, testers, managers and product managers, so it will be a busy time for all of us.

During the initial meeting to talk about how sessions should run and be prepared the question of having feedback questionnaires at the end of each session came up. It got a bit heated shortly, and I’m not sure where the jury is on that right now.

However, thinking about it and having heard arguments from each side, I can say that I’m still very much in favor of getting feedback after a training session.

Here’s what I heard from the con side. I also did fill in my fair share of feedback questionnaires, so I know where these arguments are coming from:

1. Nobody likes filling out the form. It takes time, you want to go home rather than mark where on a scale from 1 to 6 you’d say the trainer would rank in terms of preparation or being able to answer questions or how you liked the conference room the training took place.

2. The results are usually not very useful. Especially with highly standardized questionnaires answers tend to be on the non-specific side.

3. We’re not trainers, we’re developers. Training people is not part of our daily job, so why should we be taking extra care in getting any feedback in how we’re doing?

There are a couple more arguments and believe me, I get them all. I still believe that we should try to come up with a way to get valuable feedback and here’s why:

1. If you’re doing a training and you don’t get feedback, how will you be able to learn? How can you be sure that what you did was okay, maybe even really good? How can you know that what you thought you were teaching really was what came across? Unless you’re really good at reading facial expressions or minds, you won’t. And while it’s true that you cannot be completely sure that anonymous feedback is sincere, it’s most likely your safest bet at getting an honest feedback.

2. You need to give the participants of your training a possibility to give feedback. It’s only fair to them. And yes, you could go around asking each of them for their opinion. One bet says that it’s going to take longer than giving out feedback questionnaires. Another bet says that if it doesn’t take longer then it’s because people are too polite to tell you the truth.

(In fact, if you think you don’t need feedback or that your training participants don’t need it or both, it sounds to me like you don’t really care about your job as a trainer. Which makes me wonder whether you should be doing this. I might be wrong. Or I might not.)

3. Deciding against getting feedback because in your experience feedback questionnaires are boring to fill out and don’t provide any valuable results is just the easy way out. If that’s the problem – and I agree that it often is – then, by all means, come up with good questions. Nobody’s telling you how to get the best feedback you can get, all I’m saying is that you should get it.

In our situation I have suggested coming up with a very short questionnaire that has no more than three or four questions. The first thing to do is find out what the most important thing we need to know is and then ask questions that are impossible to answer with a simple yes or no. One such question could be:

What was the most useful thing you learned in this session?

Another one could be:

If you could change one thing for the next group of participants for this session, what would it be?

Yes, you could still write „Everything“ and „Nothing“ respectively as an answer, but you would have to think about it for a moment. Asking these question also means that as a trainer you’re assuming that you’re not perfect and put participants more at ease with pointing out possible faults. If you’re out to get the truth, try to ask questions that make being a bit critical and giving honest opinions feel okay and natural.

And don’t overwhelm the participants with two pages of boring 1 to 6 scales or intimidating questions with no clear indication of their purpose. Ask questions that are easy to answer while still providing useful feedback to the trainers and giving the participants a chance to give a final evaluation of what they had to sit through for four hours (or more).

It’s only fair. That’s all I’m saying.

More Whiteboards Everywhere

I wrote a post about my deep love for whiteboards a while ago. This is a short follow-up with a revolutionary (well, not quite) idea that I’m proposing to development teams everywhere.

We’ve been jokingly talking about that at work, but I think it has a good point: We have our little office kitchen, basically the heart of the whole office floor because it’s where the coffee is. Often enough, kitchen small-talk turns into a design session, some technical issue gets discussed, a specific problem is brought up and so on. You probably know what I’m talking about.

So, what if we had a whiteboard in the kitchen? It would make total sense and would be perfect for turning a kitchen discussion into a design concept. Draw it up, take a picture with your cell phone, go back to work. It’s the spontaneity that counts here and having an easy way to jot down ideas would bring this to a whole new level.

Meeting Flavors

Meetings are probably a very controversial topic in the everyday company world, and it’s just as controversial when it comes to software development. Meetings can suck the time out of your week and the life out of you if done wrong.

However, if done right, meetings can be one of your best tools for communication and knowledge transfer. In my opinion you just have to remember a few simple rules and think about meetings coming in a very limited variation of flavors.

The purpose: Result or information driven

When I say that meetings can be either result or information driven, I mean that the goal of the meeting can either be to reach a specific result or to pass on information (or both). Working in an agile information, I am in both kind of meetings all the time.

A typical planning meeting is result driven. At the end of the meeting we are supposed to have decided on the user stories the team will we working on for the next couple of weeks. We usually have small design sessions during a sprint, whose intended result is a working and agreed design.

On the other hand, we regularly have meetings where the main point is to get information across. Usually these are cross-team meetings, but daily scrums could also be seen as mostly information driven.

In most every case the purpose of a meeting is a bit of both, but it should at least be one or the other. In other words: Be clear what the goal or purpose of your meeting is and make sure that others understand it. It’s only fair to the people who attend your meeting to know in advance what they’re in for and what they can expect.

The style: Discussion or presentation

The style of a meeting can also vary. It can either be a discussion where everyone is invited to throw in their opinion and discuss a certain topic. Or it can be held in a more presentation-like style, with one or more people presenting while other attendants may discuss key points or ask questions.

Again, there’s not one or the other, but rather a mixture of both styles. A presentation without a bit of discussion will easily bore other people, while a discussion without a bit of a presentation of the issues to discuss will likely get out of hand when nobody knows for sure what the meeting is about.

Just like with a meeting’s purpose, the style of a meeting should be clear, make sense and be properly communicate to the participants.

That’s it.

For me, that sums it up. Sure, you could argue that there’s a lot more to it, and there probably is, but going with these four characteristics – or basic meeting flavors – I find that I can easily describe the kind of meeting that is most helpful for any given situation.

And to leave you with a few more meeting wisdoms from my work experience, how about these two:

Always, and I mean always, end a meeting with a result. Never wrap up a meeting without a follow-up e-mail, a list of action items, a working design or at the very least a set of notes. A result can also be to meet again (that would fall into the action item category) or to ensure that everyone is on the same page (get a short feedback from all participants and send out an email with the main points summarized). Never, ever leave a meeting empty-handed. For me, this is the best indicator that something went wrong with the purpose of the meeting.
Besides, meetings will be regarded less like a waste of time of it’s obvious to everyone that something came out of it. Getting a e-mail with a summary of all the discussed points will remind people that they didn’t waste their time being stuck in a room with too little air.
Make sure someone is the designated moderator for a meeting. Even for a meeting that is mostly a discussion or one which consists of several presentation by several people, there should be someone who acts as the owner of the meeting. That someone should start the meeting, wrap it up and make sure that there are no loose ends. You might be able to bend on this rule for more informal meetings, but be careful if you do.

If you do meetings right, they can be a helpful tool without getting on everybody’s nerves. Following a few simple rules should make that a bit easier.