Monat: Februar 2010

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.

Game-Base Everything

I recently joined StackOverflow because we had some problems with FxCop that nobody could really explain, so the last option was to register for StackOverflow and ask there. I’ve noticed for some time now that this forum provides what are most probably the best answers to any development problem up to the point where I would add „stack overflow“ to any Google search regarding programming issues.

After asking the question and waiting for the answers I realized how immediately infecting the reputation-based system of StackOverflow is. There I was with my sad little 11 reputation points, 1 single badge and one question with no votes so far. If your the least bit competitive and a tiny bit insane, that’s going to bug the hell out of you. After all, you want more points, more badges, more votes, more reactions. At least that’s what happens with me.

So, I started to poke around the rest of StackOverflow, found questions to answer, added comments here and there and slowly my reputation points went up. Another nice side effect is that this blog gets a bit more traffic. Don’t know how many people stick around, but it feels good to gradually get more hits from all over the world.

The genius of StackOverflow is that reputation points are based on the rest of the community not on sheer input you feed into the system. In other words: StackOverflow rewards quality, not quantity. Most other online forums simply reward the quantity of posts with some kind of reward system. It doesn’t matter whether you post a detailed problem solution or just a „Okay. Thanks. I’ll try that.“ Your posts will be treated the same.

StackOverflow on the other hand won’t give you any reward until someone else from the community says that your answer or comment is actually worth it. Plus, there’s a penance if your fellow StackOverflow users thinks that your question or answer is kind-of-crap. The effect is that people are forced to actually think about what they’re writing (be it a question or an answer), rather than just typing in some unreadable, unclear and basically not-thought-through stuff and hoping that everyone else will just ignore that you obviously weren’t willing to spent a few minutes on thinking about what you’re writing.

It also makes sure that the answers for the most time are a lot better than in most other forums, because an answer that is either wrong, incomplete, unhelpful or just hard to understand will probably not be getting you any points and therefore probably not worth writing at all.

How I think about this, I am pretty much assuming that most users of StackOverflow share the little competitive and game-affine trait that I have. But, yes, I think they do. I think that getting points and climbing up in some kind of hierarchy is something that is addictive to most of us who spent a lot of their time at the computer even when they’re not at work. It just gets us. It’s what makes so many time-wasting small web games so popular. It’s what makes location-aware services like Foursquare and Gowalla work. Because, let’s face it: We all like to play rather than work. And if you make what we would otherwise perceive as work seem like a game to us, you win.

So adding a game-like feature to something that is actually more than a game is pure genius. It makes a forum that probably would have been very good anyway an amazingly great forum. So I salute whoever originally said „How about we make it reputation based, but… different?“ It was a great idea. And it worked.

Should Sprints End on a Monday?

Last week was the final week of a sprint and things were starting to get emotional. We were running out of time and probably the only reason we made it was that people were staying late to finish up stuff. The last day before the sprint demo, we were testing three forms, praying that we wouldn’t find anything that would need fixing and push us into another round of testing.

We were mighty lucky. No major bugs were found, and we only had to do a second round of testing on one form before I could leave on Thursday around 8pm – and out of the four of us I was the first to leave.

Then again, the sprint demo went really well. Everything worked, we could answer all questions, we were prepared, we had a list of bugs that we knew were there but couldn’t do anything about it. Two small bugs popped up during the demo, but that was okay and the sprint was successfully signed off by the product owner.

That was a Friday. We usually have the demo in the morning and the retrospective in the afternoon. However, the team was pretty exhausted, and I was fighting headaches, so I asked for the retrospective to be moved to Monday.

Today we had the retrospective and it went well. We could focus on the problems we had and come up with action items to help us avoid those in the future – just what you should get out of a retrospective. In fact, I personally think it was one of the best retrospectives we had.

I wonder whether it would have gone equally fine if we had dragged our sorry tired behinds to a retrospective after two long nights and nearly one and a half hours of sprint demo. There were a couple of not-so-nice things that had happened during these last days and I still felt pretty emotional about those. I can do pretty well with sucking things up, but a retrospective is all about talking about what went on during a sprint, so I wasn’t sure how well I would hold up.

My feeling is that while you should absolutely do a retrospective right at the end of a sprint it might be a good idea to do it on a Monday instead of a Friday. There’s a whole weekend between the last day of the sprint and the retrospective and it can definitely help calming things down. A weekend gives you time to let go of all the emotional stuff and get a bit of distance while still keeping memories fresh enough for a productive retrospective.

This leads to another idea. What about a sprint demo on a Monday? This could have two advantages:

1. The sprint team and everyone else involved can come in refreshed after the weekend, possibly with more energy than they would have on a Friday.

2. If the team runs into the unfortunate situation of not getting it done, they still have the option of working on the weekend. I know this is not something that people like to do, but in some cases working a Saturday might still seem like the better option than failing a sprint. Basically, having a weekend between the last day of the sprint and the sprint demo gives the team two days they could use if things go very wrong.

I wonder if this is worth a try for the next sprint. If we actually do change the schedule, I’ll keep you posted on whether it really makes a difference (and – if yes – whether it actually is better).