thekua.com@work

At Thoughtworks we run regular rounds of reviews (at least twice a year). We also try to collect project roll off reviews although collecting feedback at these points sometimes proves difficult as people move on to other projects. The last few rounds, I’ve used the list that Jason Yip wrote a while back here. It’s served me well on the most part, and thought it’s about time to review them to be slightly more relevant. Here’s the latest one I’m using for my current project.

• How do you feel about how I’ve listened to you? Tried to understand you?
• Did I provide you with enough guidance and support? Did I give you enough freedom? How would you describe my approach?
• What things made it easy for you to work/pair program with me? What things made it hard to work/pair program with me? How do you think we could collaborate better?
• In the role of a technical lead, do you think I was effective or ineffective? How could I become more effective in my role? What do you see as my greatest strengths? What do you see as my greatest weaknesses?
• Describe how my style differs from other technical leads that you’ve worked with? What would you change? What would you keep?
• What things have I done that have had a significant impact (positive and negative) on the project?
• What areas do you think I can improve or grow in and why?

I’d be interested to see if you have any more that you ask yourself? If so, please leave a comment.

Comments(3)

Last week I attended the XP2007 conference (I hope to write more on that later), and found myself asked on several occasions by “newbies” to agile about “what they should do in xxx situation”. Happy to offer an ear, I found it nice being able to share my own experiences, and offer some guidance and a number suggestions they might take. Their responses varied and seemed to fall into two camps.

Some people gave my words some thought, and thanked me for my suggestions. They asked a few more questions about the suggestions and at least I felt they might try a few of them.

Others had a very different response, claiming that in their situation none of my suggestions would work. They went on to explain their situation in greater detail, asking many leading questions so much that I almost felt being cornered into giving a yes or no answer. Wary of the consequence of a definitive answer, I persisted in only giving them suggestions and the positive and negative impacts they might or might not have given my experience.

Unfortunately I didn’t feel like the latter camp took many of my suggestions on board, and I am sure will be eventually disappointed to find the elusive silver bullet does not exist. Although agile methods, their practices and values offer a lot, like many things in the real world, takes both effort and courage to make them really work.

Comments(0)

Speed, speed, speed… I wish MS tools would give me faster and faster feedback.

My lesson from last week - stay far away from ItemGroup elements in MSBuild files for most normal fileset equivalents (most especially if they only get used once). They are far better as CreateItem elements (though unfortunately only declarable within a Target element), taking almost the same syntax.

The result - instantaneous execution of any other targets outside of the one that uses these items, and a quicker ability to fail faster if you mistype the target name. Maybe it’s time to convert all of our targets to Nant?

Comments(1)