Comments for Refactor

Comment on The new IPhone by RabidDog

RabidDog — Mon, 19 Jul 2010 10:58:54 +0000

I think Steve and Bill should get a room looking at those smiles

Comment on I’m not a child… by Parth

Parth — Thu, 15 Jul 2010 12:31:58 +0000

If the branch you are sitting on does not have a songbird that will listen to your song, fly higher up the tree, and find one that does. As a bonus, the higher up the tree you go, the less chance you’ll have of getting hit by falling shit…

Comment on The new IPhone by Rick Tonoli

Rick Tonoli — Tue, 13 Jul 2010 13:31:14 +0000

Classic, I love it… so much for machine testing devices, maybe it’s time for less “automated” testing and more “manual” testing of stuff…

Comment on Implementing an Effective Build Dashboard (for Hudson) (Part 3) by Nic Willemse

Nic Willemse — Wed, 10 Mar 2010 07:45:36 +0000

Thats to awesome!

Comment on Trust… by Rick Tonoli

Rick Tonoli — Tue, 23 Feb 2010 16:44:57 +0000

No I haven’t had a look at Michael Covey’s work but will make a note of going to. As a team facilitator I see the impact of lack of trust on the team effectiveness quite clearly, and it’s actually quite sad because I’ve worked with teams where there IS a decent trust relationship internal and external to the team, and seen what teams in that environment can do, but how do you convey this to people, that’s the tricky bit. I guess quantifying it in rands and cents is the logical approach.

Comment on Continuous Integration with Hudson and .NET by K Arun Mariappan

K Arun Mariappan — Tue, 23 Feb 2010 05:37:34 +0000

Thanks a lot.

Really a good article.

Comment on Trust… by Nick

Nick — Fri, 19 Feb 2010 13:39:25 +0000

Couldn’t agree more. I don’t know if you have looked at Michael Covey’s work around the speed of trust. What I like about this is he shows how the lack of trust costs in Rands and Cents. This really helps when talking to traditional managemement as cost is something they can really relate to. So the argument doesn’t have to be about the fluffy better environment but rather a hard fact that lack of trust costs money.

Once you have them sold on the idea that trust must be built then moving the other mindsets become easier.

Comment on Trust… by Kenneth

Kenneth — Wed, 17 Feb 2010 18:03:47 +0000

As I pointed out in one of our discussions regarding this topic, I think it falls back on the conditioning created by the old though process of project management. Get scared, fall back on what I know.

Rather sad if you ask me

Comment on Performance appraisals, do we really care? by Rick Tonoli

Rick Tonoli — Thu, 11 Feb 2010 20:30:42 +0000

In part I agree with you, performance appraisals are necessary but I believe how they are used needs to be re-evaluated. In my opinion linking reward to performance doesn’t work for this simple fact: if you tell someone “You produce 5 widgets and I will give you X reward” what is the incentive to ever produce more than 5 widgets? Performance related rewards cap potential in staff.

I believe reward and appraisal should be separated from each other. Rewards should be tied to something that has no cap (like company performance, share price or number of satisfied customers?) and people should be rewarded on the performance of the whole, not the individual. Rewarding individual performance discourages team work and emphasizes the individual over the team. Appraisal should be with the aim of self-improvement of the individual WITHIN the team; asking questions along the lines of: “in what way can we (employer) help you (employee) be better at what you do” (or something like that).

Here are some interesting reads off the infoq site on the topic (both for and against):

http://www.infoq.com/news/2008/03/bonus-for-agile-teams
http://www.infoq.com/news/2008/10/performance_review
http://www.infoq.com/news/2009/11/scrum-individual-reward

Comment on Change is good by Rick Tonoli

Rick Tonoli — Thu, 11 Feb 2010 20:02:26 +0000

Enforced teamwork is kind of like pushing a string, fun, but not useful. The team decided paired programming was something we wanted to try, two of them ran with it for a sprint and gave critical feedback at the end (both good and bad). Oh, and to make things more interesting we added TDD in as well

We found some interesting benefits coming out of it (besides the ones we expected), like the fact that people find it difficult to “interrupt” two people working, so fewer interrupts and more focus; guys actually had fun collaborating on solving a problem, even doing boring stuff; the combined momentum of the pair was (I thought) greater than the sum of the individuals. Add to that the obvious things like automatic review of code, improved quality and constant refactoring for improvement and I think it’s a winning recipe.

In the end though I think it has to be something the team decides to do, not something dictated to. It’s a mind-shift of note to get used to and unless your heart is in it, there’s no real hope it will succeed.