Retrospective: Week One

‹prev | My Chain | next›

One of the last Agile practices that we adopted at my day job was retrospectives. In retrospect, it should have been one of the first. It was entirely my fault for not introducing them sooner, fortunately my team pushed me into it.

Simply put, you will not improve unless you strive to get better. You will not improve unless you:

• look back on what you accomplished
• reflect on what prevented you from doing even better
• try to apply lessons learned the next time around

It almost seems so obvious that it's not worth the 15 minutes that it takes your team. But, as anyone that has ever practiced regular retrospectives knows, they are an invaluable tool for identifying group problems that might have otherwise gone unnoticed.

I am not entirely certain how retrospectives will work in the context of a chain. After all, the chain is more about education than ruthlessly delivering quality software. Still, if I am going to be spending all this time on my chain, I ought to make an effort to make it as effective as I can.

With that in mind...

What Went Well

• Started the chain, which is always the hardest thing to do.
• Got the app running on CouchDB 0.10 and couchdb-lucene 0.5 (pre-release)
• I no longer have to fork my my own couchdb-lucene—recent versions support the token analyzer that I prefer.
• If this were an actual project with a deadline, I would have to put couchdb-lucene as an obstacle—it took the bulk of my first iteration's work. I list it here because I enjoyed working with it and picked up a few new tricks along the way.
• Speaking of couchdb-lucene, Robert Newson (the maintainer) has been fantastic about fixing any issues and offering advice as needed
• Even in the original implementation, I had some qualms over a map-reduce that blew right through the limits of acceptable reducing. Just today, a helpful reader offered a promising alternative that feels more idiomatic CouchDB.

Obstacles / Things That Went Not So Well

• The not-fast-enough reduce. As nice as it is to get feedback, it is clear that there are still some aspects of CouchDB that I do not know as well as I would like to at this point.
• Specs on the netbook—I am doing all of my coding and writing on a Lenovo s10-2 netbook. I really like it so far. It is light, compact which cuts down on distractions. The only thing that is not clicking is my testing workflow. I BDD, so I normally write my specs in the left pane of my emacs window and make the tests pass in my right pane. This left-to-right flow suits me. The netbook screen is a little small for this.
• Have not tried Sinatra 1.0 yet. I had hoped to be ready to redeploy with CouchDB 0.10, couchdb-lucene 0.5, and Sinatra 1.0 starting next week. I have the first two completed but have yet to even look at Sinatra 1.0. This was more of a stretch goal for the first week, but still.
• Need a better balance between real life and the chain. Too easy to get absorbed.

Suggestions for Next Iteration

• Pomodoro—maybe 2 or 3 per link in the chain. For this next iteration, I will aim for two full pomodoros a day. To keep myself honest, I will start each pomodoro in a new git branch, date-stamped and with a label for what I hope to accomplish in the 25 minutes (e.g. 2010-02-10-explore-couchdb-lists). I also hope that this will provide a better balance with family life.
• Will try the Liberation Mono and Terminus (if I can find on Ubuntu) fonts in an effort to get my edit buffers displaying just right.

Day #9