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).

Fun with Yahoo Pipes

I know that Yahoo Pipes has been around for quite some time, but I have never had a use case where I thought I needed it. Frankly, I only had a vague idea about what it was.

That is... until today. I'm still not totally clear about all the things the pipes can do for me, but there's one thing that I now know they can do: help me build an automatic retweet bot.

Admittedly, this was a fun project whose other purpose was to keep me sane after more than two straight days of configuring security for nearly two hundred objects (don't ask, you just don't want to know), but it was quick and successful and now that I've tried it I wonder what other cool things I could pipe together.

I started with this video, which is a step by step guide as to how to build an automatic retweeter. (Actually, once you've watched this you can pretty much stop reading here. On the other hand, it would be nice if you'd read on.) Fortunately what I wanted to do was even simpler. I just wanted to retweet everything from another tweet account.

Setting up Yahoo Pipes

1. Create a Fetch Feed module and add the feed you want to retweet.

2. Create a Filter module and block everything that has RT or *.RT in the item.title. This prevents you retweeting retweets and risk running into an endless retweet. Also block everything where the item.title starts with @ to prevent retweeting direct mentions. Link this module with the first one.

3. Create a Loop containing String Builder to manipulate the item.title. In my case I added some text and an @ to the start of the string to simulate a retweet with comment. Then assign this to item.title. Link this module to the Filter module.

(Note that I'm pretty sure that using item.description would have worked just as well, since it looks like Twitter doesn't really care to differ between the two.)

4. Connect that last module to the Pipe Output and check it out.

Feeding your Twitter account

Now, there's a handy tool called twitterfeed which will take any feed and route the output through to a selection of services, including Twitter. You just define the feed you want to use as your input, link to it your Twitter account (Facebook and a couple of other services work, too) and you're ready to go.

You can define multiple inputs and multiple outputs, define which part of the feed's items you would like to pass on (title, description or both) and define the update schedule (30 minutes are the shortest refresh cycle). There are also a couple of other settings like setting prefixes or postfixes or filtering the input feed, but I didn't have to use them.

With that all setup I had to be very patient to wait until twitterfeed finally sprang into action, but it worked perfectly.

Now, this was a pretty useless project in terms of actual results. I'm retweeting someone else's tweets. As far as making the world a better place goes, this doesn't help a lot. Still, for a quick introduction to Yahoo Pipes this was a great way to start. Now I keep wondering what else I could pipe together with a more useful output. Any suggestions? Experiences? Ideas?

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.

A Year in Books - 2009 Edition, The Rest of It

You got my favorite books this morning. And now, let's move on to the other categories (in no particular order):

Book That Seemed the Longest (and Probably Was)

That has to be Cryptonomicon. And I won't even discuss why that is.

Best Children's Book

I didn't read a lot of children's books this year, for no particular reason. Obviously the winner here is Madeleine l'Engle's A Wrinkle in Time.

Most Disappointing Books (of Sorts)

 I really can't decide here. Chris Cleave's The Other Hand made the mistake of promising too much. I wouldn't say that it was a bad book, but it just didn't live up to its praise. (The lesson here is: Don't buy a book that won't provide any information on its back and just saying that you should just read it.) Donald Norman's The Design of Future Things wasn't anywhere near as good as The Design of Everyday Things. Scarlett Thomas's PopCo was great in the first half of the book, but it all went downhill in the second half. 

In the end, I think PopCo is the "winner" here. Sorry.

Best Non-Fiction

This goes to Malcolm Gladwell's Blink, a book that left me initially underwhelmed, but which I found myself quoting again and again, so it really did have an influence on me. (It would be very easy to name Dave Eggers's A Heartbreaking Work of Staggering Genius or What is the What here, but they both didn't really feel like non-fiction.)

Most Charming Book

In the end The Little Book by Selden Edwards can proudly claim to be the winner of this category. I'd like to mention The Brief Wondrous Life of Oscar Wao by Junot Diaz and - of course - A Staggering Work of Heartbreaking Genius since they were in the run as well.

Book With the Most Anticlimactic Ending

Again, Scarlett Thomas's PopCo wins. Anticlimactic endings and disappointment just fits together really well.

Saddest Book

Carolyn Parkhurst's The Dogs of Babel. For some reason, I read this for the second time and again it was really, really sad. 

Best Kind-of-Victorian Ghost Story

Easy: Audrey Niffenegger's Her Fearful Symmetry. (What did you expect?)

Strangest Book

Ultimately, it has to be David Mitchell's number9dream. David Mitchell is such an obvious choice that I'd like to add that Jonathan Barnes's The Somnambulist came in a close second.

Clunkiest Use of a Deus Ex

Jonathan Barnes's The Somnambulist is a clear winner. I still recommend the book, but you'll know what I mean when I read it.

Best Comic

This has to be Jeff Smith's Bone - Rock Jaw, Master of the Eastern Border (Vol. 5). The only comic books I read were volume five and six of the Bone series, and volume five had all the cute animal orphans.

So that was it for the last year. I've already read my first two books for 2010 to make sure that I have plenty of choices for next January.

A Year in Books - 2009 Edition

As every year, here is the best I could do to sum up the highlights and specials of last year's reading achievement. And as always, let's start with the best ten books:

10. Madeleine l'Engle: A Wrinkle in Time: I finally, finally got around to reading these. They were never really popular in Germany it seems, so the l'Engle books weren't part of my childhood reading memories. I finished this in no time, because it's so awesome. (And I'm guessing I'm preaching to the choir here, so this is mostly for those readers who haven't read them. Do. Like, now.)

9. Neal Stephenson: Cryptonomicon: Has a Stephenson book ever made it to my top ten list? Not sure and too lazy to look it up. One reason why it hasn't happened probably is that these books exhaust the hell out of me. However, when I read Cryptonomicon I finally realized how very unique Stephenson's style is and how much I enjoy it, despite all the exhaustion and the relieved sigh you could hear me make when I'm done with one of his books. (This is another classic, so I won't bother with any plot details here. Even if I tried, this is a Stephenson book, so come on... Lots of charaters, lots of places, lots of words. And a treasure.)

8. Stieg Larsson: The Girl Who...: I couldn't decide which book of Stieg Larsson's trilogy I liked most, so I'll just treat them as one book. It kind of is, anyway. Those of you who know me a bit better know that I'm not a big crime or thriller reader, but man, do these books rock. The first one is your basic family mystery crime story complete with your mystery genius girl. Starting with the second book, Larsson starts a saga that dives way deep into the realms of political intrigues and journalistic thriller. All books were great and I still am a bit sad because the saga had to stop long before it was planned to.

7. The Story of Edgar Sawtelle by David Wroblewski: There's a praise by Stephen King on the cover of this book and after I read it I think I know why. The story of a boy who doesn't talk raised on a farm with his parents who raise and train a special breed of dogs. After his father mysteriously dies and Edgar's world falls apart, he runs away accompanied by some of his dogs. It's a perfect and unique setting and highly recommended.

6. Selected Works of T.S. Spivet by Reif Larsen: Similar as The Story of Edgar Sawtelle, this one tells the story of Tecumseh Sparrow Spivet who lives in the smallest town in Wyoming and is a genius at documenting everything in his notebooks. When he gets an invitation to receive a price from the Smithsonian he sets out on a journey east. One of the best parts of the books is all the illustrations and annotations from T.S.'s notebooks. But the story is equally great.

5. Audrey Niffenegger: Her Fearful Symmetry: I knew nothing could top The Time Traveler's Wife, so I didn't even bother to expect anything that reality couldn't live up to. And it's not as great as TTTW. But how could it? Besides, this is a victorian-style ghost story about two twins living in their aunt's flat in London with their slightly eccentric neighbors below and above and their aunt herself living in their flat as a lingering ghost.

4. China Miéville: The City and the City: I had a hard time getting into this book, but then it was absolutely worth it. Leaving London and its variations behind, Miéville invents the strangest place, two cities occupying the same geographical space, but politically separated. And then a crime happens and a detective stumbles into the world of his city and the other one and then one in-between. Part fantasy, part detective story, part film noir, this was everything I love about Miéville's weird imagination.

3. Dave Eggers: A Staggering Work of Heartbreaking Genius: I wondered whether I should put two Eggers books on my top ten list, but then I figured, what the hell. The introduction alone makes this worth a spot in the top ten and the rest of this kind-of-autobiography easily makes it a top three. If you want to read a staggering work of heartbreaking genius from my favorite author of the year, this is it.

2. David Mitchell: Ghostwritten: Don't make me try explaining a David Mitchell book to you. This doesn't work. I'm still not sure if I understood everything, but I also don't think that's the point of any Mitchell book.

1. Dave Eggers: The Wild Things: Oh oh oh oh, my god! How terribly great is this book! After You Shall Know Our Velocity this book convinced me that Dave Eggers is just one amazing writer. I couldn't stop reading and that had nothing to do with the fact that I was stuck on airplanes and in airports. It had everything to do with the book. It was also kind of helpful, because after reading this, I knew that I wouldn't have to worry about deciding on my favorite book of the year.

That's it for my personal top ten books of the last year. As for the other categories, they will be discussed in detail in the next post. And while we're at it, what were your reading highlights of 2009?

That Calm Before the What?

Today was an oddly relaxing day at work. Tomorrow will be the last sprint demo of the year, and my team and I are pretty confident about the results.

However, it's always a strange feeling you get so close before the finish line. You half expect something big to show up and show its nasty face, just like it happened last time - and that wasn't a great experience.

But today I realized there are a few things you gotta learn to stay at least half relaxed through the whole Scrum thing. 

First, I'm sure that no matter how well everything is going, you always expect something big to happen at the very last minute. We had three bugs popping up in the last 48 hours and dealt differently with each of them:

• The first one was fixed by a developer yesterday evening and had unforeseen consequences. Basically, the original bug was fixed, but in its place a new bug appeared. Since the developer is on annual leave for the rest of the year, we decided to roll back the changes and get back to it in 2010. The original bug really was an edge case "only-happens-when-somebody-screws-with-security-settings-anyway", so it seemed like the right call to get everything back to how it was before and tackle the problem with fresh energy.
• The second bug turned out to be an already known bug in slightly different clothes, so we could move it to a different team's queue and just check it off our to-do-list.
• The third bug was brought to our attention by someone from another Scrum team and that one was also moved to the queue of bugs to fix in the new year. It actually was something left over from the sprint before this one. Plus, another developer on my team was smart enough to whip up a small test project and realized that it actually was a bug in the standard Silverlight control, and not in our code, so the solution might be to just file a bug report with the Silverlight guys.

What I'm trying to say is that the first thing I tried to find out about each problem is whether it would affect the sprint demo. In each of these cases the answer was "no". Yes, some of these bugs need fixing, but none of them were critical and rather than letting panic reign the day before the demo, we decided to just keep our cool and assess the importance of each bug.

And yes, each bug fixed is a good thing. But sometimes, a bug hastily fixed in time for a demo is no good at all. We learned our lesson the hard way four weeks ago and we all agreed we would never make that mistake again.

So I'm still crossing my fingers and hope that we didn't miss anything big. And I realized that I need to get used to the feeling to be afraid to have missed something. Apparently it doesn't go away. However, if you learn how to deal with it, it's not that bad. First, accept that this is how you feel if you care for what your team has done. Second, let go of the little things. There will always be bugs. But, if you've done a good job, there will be less.

What Code Coverage is Good For

There is a common misunderstanding regarding code coverage of unit tests. To make it short: Code coverage doesn't tell you anything about whether your unit tests work. The only thing they tell you is which code lines are covered with the unit tests in place.

A lot of times it is very, very easy to achieve 100 percent code coverage with a few simple unit tests. If the unit you're testing doesn't have any conditions you might get away with one test which will execute every code line and get a perfect code coverage score.

Well, duh. That doesn't mean your code is thoroughly unit tested.

However, there are good reasons why you should look out for code coverage and reach for the best coverage you can get. I usually only check my code coverage at the end of a unit test writing session. If I thought of everything I should get a 100 percent coverage. If the code coverage is less than expected it's a good chance I missed something.

In other words, just because your code coverage for a tested unit is great doesn't mean that you've tested everything. It also doesn't tell you whether your tests are actually correct. The brainwork is still up to you and any code coverage analysis can't help you there. However it's a nice way to make sure that you didn't forget something obvious, like forgotten to test the other condition.

I regularly run PartCover to check code coverage of implemented features and I regularly find untested code lines. Most of the times these are due to small changes or bug fixes, when we just forgot to add a test for that simple change we made.

So, while code coverage tells you nothing about the quality of your unit tests, it is a great way to find any open gaps - however small or big - in your existing tests.

Everybody Loves a Code Review

Today we had an impromptu code review during a meeting which is actually intended for our feature teams to get together with the platform team to discuss any issues, ask questions or just address anything that might be of interest to others.

This time it was mostly our team trying to get some input on problems we already had discussed within our team but felt we could need more people to chime in on and collect new ideas.

My main issue was that I felt that I was stuck implementing the UI for a pretty straight forward feature. Unfortunately, though it was straight forward, it was also fairly non-standard. The good news was that we had implemented similar features already. The bad news was that we had implemented different parts of what I needed (or thought I needed) in different features, so I was taking code from three different features and trying to mesh it together for what I needed. I had come to a point where it was kind of working, but not really.

I had also come to a point where I didn't know where to start looking to solve the issues I still had. Our team lead told me that she'd take a look at it with me to figure out where the problems were. That was pretty much what I was looking for, but since I was pretty frustrated already I went on a bit more about... well... basically about how frustrating it was that I was digging through code that I felt I should understand, but really didn't. I guess my frustration showed, because the next thing I knew, I was asked to bring my laptop so we could all have a look at the code and figure out where the real issues were.

There were six of us and it took us about an hour to get through the main parts and leave me with a pretty good idea what was still missing and how to solve it. As it turned out the code wasn't half as messy as I thought it was, but I had made a couple of stupid mistakes, mostly due to my inexperience with frontend development. We got to tidying up the code a bit and got the feature up and running (with a couple of things missing, but still).

At the end I wondered whether I should feel bad for taking up five developers' time to look at my code. But you know what: I think I shouldn't. Both my team lead as well as another developer from my feature team said that they actually liked the small code review session and I got the impression that everyone else liked it as well.

Here are a couple of thought on why code reviews are good for everyone:

• Everyone looks at code differently. Everyone thinks differently, so you get a lot of new ideas you would have never though of.
• Everyone has different experiences, so it's a simple way to learn new stuff. It's also a good exercise for explaining things to others.
• You'll see problems and issues popping up that you didn't know where actually a problem. This also goes for pretty small and random problems that otherwise would have never been mentioned. So now you have a chance at solving them.

Basically, code reviews are a good way to solve an actual problem, but it also might reveal a couple of underlying problems that people weren't aware of before. It's a nice and communicative way to get your brain working, whether you're more of an expert in the matter discussed and are suddenly forced to explain concepts to your colleagues or whether you're the one with the questions trying to find a solution to the problem at hand.

If you're someone who doesn't like to present your messy code to others for fear of being thought of as stupid or if you're someone who doesn't like to throw ideas around the room while purely looking at code projected on the wall, code reviews might not be thing for you. For a code review to work you can neither try to hide your coding mistakes not can you point fingers and laugh. It can turn out to be a challenge for everyone, but it can be a pretty rewarding challenge at that.

I guess my main point is, if you feel like a code review could help, do it. If you're the one with the problems, don't be shy. Everyone makes mistakes, everyone has problems understanding different things. People understand. If you're someone with more experience, share it. Explain. And for everyone involved I would just say: Ask. Help. Suggest. Try. Enjoy.