Four months ago I've introduced ADS project at Agile Warsaw group. Since
then, we had a chance to test some new ideas and experiment a bit in
order to create a better learning environment for our developers.
I've tried summarize it here:
I hope it may be of some use to you. Maybe you also have some stories to
share? I'd be very interested. Anything to motivate us a bit, helps.
Much of the discussion in the group is predicated on several resources summarized on the wiki at http://www.agileskillsproject.org Please review this regularly. To request editing permissions for the wiki, send an email to either of these gmail addresses: richardjfoster or redhotglass .
You received this message because you are subscribed to the "Agile Developer Skills" group.
To unsubscribe from this group, send email to
For more options, visit this group at
50-60. Most of them (50?) being developers, split evenly between SQL and
> I really like the
> [research/spike] task board you've created, up for grabs for anyone in
> the company
The question is: will it work? Time will show, I guess.
> You mentioned code reviews, and breaking them up from one big session to
> two. I've found that the smaller those reviews are, and the less
> formal--that is, the closer they are to actual pairing sessions--the
> happier developers are. Is that something you'd agree with too?
We haven't broken up our code reviews into two. OCRs started as a pure
Java event, and then one of my bosses asked, whether it could be used
for SQL developers as well. They started doing their version of OCRs,
and are quite successful with it. There is no point mixing it though,
since Java developers are not interested in hardcore Oracle integrals,
and SQL developers don't do much Java either. The time we spend on OCRs
(one hour) hasn't changed, neither the number of participants (4-6).
I've noticed, though, that some folks from one world come to the OCR of
the other, just to learn how to do things better. But these are usually
people who want to learn a new technology and our company promotes being
I also believe people like that, it's somehow different to everyday
experience. So if you do pair programming every other day (which we
don't, we mostly pair when we feel like it), you'd rather have a few
more minds to crunch the problem. If you don't do pair programming at
all, having a smaller group is like getting more attention, which is
I believe It's more important what kind of a problem is being worked on
at the code review. Last time, instead of a typical "how to make it
simple, cleaner, better", we were trying to solve a bug with concurrency
in non transactional environment (sending thousands of sms messages,
loosing connection to gateways in the meantime and so on). Some folks at
the meeting were hardly speaking, but were still very interested, since
they don't get to have that issues in their everyday work. While I am
far from being good at concurrency (I usually just know how to avoid
it), I enjoyed drawing the behaviour of our code as a sequence diagram,
so that we could all understand what is going on a bit better. All
together, that was a very pleasant and informative meeting.
My guess is, that you should have not too many people (3-4?) who have
strong expertise/opinion on the subject, since these will be
talking/brainstorming a lot, but you can have quite a few, who, while
not having much to say (and not touching the keyboard much), just want
to understand the problem and learn ways of dealing with it.