Outcomes of experiments to create a constant learning/improvement ecosystem in my company

21 views
Skip to first unread message

Jakub Nabrdalik

unread,
Feb 6, 2011, 2:03:40 PM2/6/11
to Agile Developer Skills
Hey everyone,

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:
http://blog.solidcraft.eu/2011/02/animating-developers-4-months-later.html

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.

Thanks,

Jakub Nabrdalik

D.André Dhondt

unread,
Feb 9, 2011, 8:26:27 AM2/9/11
to agile-devel...@googlegroups.com
Jakub,

Thanks for sharing with us... you've implemented quite a few changes and improvements--how many people are at your company? I really like the [research/spike] task board you've created, up for grabs for anyone in the company--and the way you've made it clear that this is official work of the company.  I also like the conclusions that most of the 'forced' work, and the irrelevant quests, were not motivating, and so you've been looking for ways to encourage learning where it also has an immediate benefit for the teams.  

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?

--
________________________________________________________________

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
agile-developer-s...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/agile-developer-skills?hl=en?hl=en



--
D. André Dhondt
mobile: 215-805-0819
skype: d.andre.dhondt
twitter: adhondt   http://dhondtsayitsagile.blogspot.com/

Support low-cost conferences -- http://AgileTour.org/
If you're in the area, join Agile Philly http://www.AgilePhilly.com

Jakub Nabrdalik

unread,
Feb 9, 2011, 10:36:57 AM2/9/11
to agile-devel...@googlegroups.com, "D.André Dhondt"
W dniu 09.02.2011 14:26, D.André Dhondt pisze:

> Thanks for sharing with us... you've implemented quite a few changes and
> improvements--how many people are at your company?

50-60. Most of them (50?) being developers, split evenly between SQL and
Java.

> 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
a generalist.

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
usually better.

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.

--
Jakub Nabrdalik
http://solidcraft.eu

ronjeff...@gmail.com

unread,
Feb 9, 2011, 11:15:18 AM2/9/11
to agile-devel...@googlegroups.com
What a super use of a code review! Especially if the review has good open discussion of style. (but not too much I suppose). Excellent notion, thanks!

R

Reply all
Reply to author
Forward
0 new messages