*** re one-on-ones: Sounds like a nice idea in theory though I wonder if that's becomes a pain in the long run. Not for the manager but for the report. How do you guarantee that the meetings don't happen in the middle of the developer's flow? There are already plenty of opportunities for breaking concentration, isn't that one more? Do you think that it would be worth making sure the 1-1's happen around a natural break, such as beginning/end of the day or around lunch, and not in the middle of the morning or afternoon?

*** re code reviews: Ed says it's his second code review, so I would not draw any conclusions yet. Hopefully he'll have good things to say after a few more sessions. In my experience code reviews wind up hurting more, because there's not accountability (at least I think that's why). The coder relies on the reviewer, and the reviewer relies on the coder. Both parties, subconsciously I'm sure, think it's the party's job to guarantee good quality. If he/you can make it work for real, that would be fantastic. This being said, pair programming is "code reviews done to the extreme" and it works. I think because *both* parties are accountable for the qualty of the code.

I feel a bit overwhelmed by the title, but thanks for the post. I'm just trying to share my attempts to bring up my organization's overall software development practices. I'm pleased with the results so far, but we still have a long way to go.

**OK, to answers Julio's points.

**On one-on-ones they're held the same time every week so there's no surprise meetings and they're mostly in the afternoon on Wednesdays and Thursdays. A few times developers have been late, missed them entirely, or renegotiated their times. Most times it's been because they were caught up in some project work, no problem with me, I'm the one who can afford to be more flexible. Actually when developers are a few minutes late to a one-on-ones it tends to be a good sign, because they are busy with interesting work. Most of my developers have approximately 1 hour of meetings due to one-on-ones and a 30 minute team meeting per week.

**With code reviews, agreed it would be great if we paired all the time and didn't need some sort of code review, but that's not our current situation. The code reviews have definitely helped increase quality in our code bases so far. The first two code reviews have been with myself and two developers and covered code written by both developers. So I don't think we've fallen too much into the trap of relying on just a reviewer and a coder to ensure quality. Still, we have a long way to go on this front.

Ed, thanks for the info and I'm looking forward to following your progress.

Btw, I'm not the only fan: http://homepage.mac.com/keithray/blog/2006/04/04/#EdGibbs

The worst manager I have ever had.

W3C link checker    Powered by Movable Type 3.16
This weblog is licensed under a Creative Commons License.
Agitar, Agitator, Software Agitation, Open Quality, and Quality Level Agreement are trademarks of Agitar Software, Inc.

Terms of Use