I'm trying to come up with some ideas for skilling myself and my co-
workers up. I'm in a small company with 6 developers. Most of us have
between 2-6 years experience. Not many people here keep very up to
date in the dev community. Folks here seem interested in learning
more, but as a team we haven't been very good at the ad-hoc learning,
so I want to bring some structure. I want to come up with something
sustainable so that we can start to change the culture here. Since we
don't have any very experienced people here any activities we did
would have to involve everyone doing the learning, we have no
"teacher". Also any activities I come up with would have to fit into
our work load (realistically I could get 1 - 2 hours a week of
peoples time).
I've had a few idea and I'd love some feedback on them and any ideas
for other activities:
1) Do a "lecture" series - There are a lot of great talks from
different conferences. We could listen to a talk then have a short
discussion about it afterwords
2) Have discussion sessions - Someone leads a discussion on a more
philosophical topic, like DRY or SRP or Technical Debt.
3) Book group - I'm a little hesitant about that, because it takes a
big commitment from everyone to do work before we meet. Without a lot
of effort I feel it would be difficult to get that kind of commitment
from the team.
4) Brown bags - Each week (or month) someone gives a technical
presentation.
Coding Dojo with a ping-pong approach to a code-kata.
Get half the number of computers for people in the room.
Pick a code-kata from http://coding*dojo*.org Have people pair up and the first person starts with writing the first test
Pass the keyboard to the partner
Have them write enough code to pass the test
They write a test
Pass the keyboard to the first person
Switch partners
Iterate
Debrief after 60-90 minutes
This will quickly give you skills in pairing, TDD and getting discussion
going on how the team should be working.
On Mon, Nov 2, 2009 at 6:47 PM, zd...@yahoo.com <zd...@yahoo.com> wrote:
> Hi All,
> I'm trying to come up with some ideas for skilling myself and my co-
> workers up. I'm in a small company with 6 developers. Most of us have
> between 2-6 years experience. Not many people here keep very up to
> date in the dev community. Folks here seem interested in learning
> more, but as a team we haven't been very good at the ad-hoc learning,
> so I want to bring some structure. I want to come up with something
> sustainable so that we can start to change the culture here. Since we
> don't have any very experienced people here any activities we did
> would have to involve everyone doing the learning, we have no
> "teacher". Also any activities I come up with would have to fit into
> our work load (realistically I could get 1 - 2 hours a week of
> peoples time).
> I've had a few idea and I'd love some feedback on them and any ideas
> for other activities:
> 1) Do a "lecture" series - There are a lot of great talks from
> different conferences. We could listen to a talk then have a short
> discussion about it afterwords
> 2) Have discussion sessions - Someone leads a discussion on a more
> philosophical topic, like DRY or SRP or Technical Debt.
> 3) Book group - I'm a little hesitant about that, because it takes a
> big commitment from everyone to do work before we meet. Without a lot
> of effort I feel it would be difficult to get that kind of commitment
> from the team.
> 4) Brown bags - Each week (or month) someone gives a technical
> presentation.
On Mon, Nov 2, 2009 at 9:39 AM, Ironic Buddha <ironicbud...@gmail.com> wrote: > Coding Dojo with a ping-pong approach to a code-kata. > Get half the number of computers for people in the room. > Pick a code-kata from http://codingdojo.org > Have people pair up and the first person starts with writing the first test > Pass the keyboard to the partner > Have them write enough code to pass the test > They write a test > Pass the keyboard to the first person > Switch partners
Don't forget to refactor after each passing test. Keeping the code clean and readable is the reason we put so much effort into software development. If code was naturally easy to maintain, we'd not need all this craftsmanship stuff in the first place :)
One good technique that I have used is the randoori format, similar to what
was suggested earlier, but taking more of a format where two people are
pairing, but other people in the room are observing.
> On Mon, Nov 2, 2009 at 9:39 AM, Ironic Buddha <ironicbud...@gmail.com>
> wrote:
> > Coding Dojo with a ping-pong approach to a code-kata.
> > Get half the number of computers for people in the room.
> > Pick a code-kata from http://codingdojo.org > > Have people pair up and the first person starts with writing the first
> test
> > Pass the keyboard to the partner
> > Have them write enough code to pass the test
> > They write a test
> > Pass the keyboard to the first person
> > Switch partners
> Don't forget to refactor after each passing test. Keeping the code
> clean and readable is the reason we put so much effort into software
> development. If code was naturally easy to maintain, we'd not need all
> this craftsmanship stuff in the first place :)
> --
> Curtis Cooley
> curtis.coo...@gmail.com
> home:http://curtiscooley.com > blog:http://ponderingobjectorienteddesign.blogspot.com > ===============
> Leadership is a potent combination of strategy and character. But if
> you must be without one, be without the strategy.
> -- H. Norman Schwarzkopf
Thanks for the suggestion of doing a code-kata / randoori. I think our team might really enjoy that. Now I'll have to figure out how to make it happen!
>From: Steve Donie <steve.do...@gmail.com>
>To: software_craftsmanship@googlegroups.com
>Sent: Mon, November 2, 2009 8:55:33 PM
>Subject: [SC] Re: Education Plan (how to skill up a young team)
>>One good technique that I have used is the randoori format, similar to what was suggested earlier, but taking more of a format where two people are pairing, but other people in the room are observing.
>On Mon, Nov 2, 2009 at 4:20 PM, Curtis Cooley <curtis.coo...@gmail.com> wrote:
>>>>On Mon, Nov 2, 2009 at 9:39 AM, Ironic Buddha <ironicbud...@gmail.com> wrote:
>>>>> Coding Dojo with a ping-pong approach to a code-kata.
>>>>> Get half the number of computers for people in the room.
>>>>> Pick a code-kata from http://codingdojo.org >>>>> Have people pair up and the first person starts with writing the first test
>>>>> Pass the keyboard to the partner
>>>>> Have them write enough code to pass the test
>>>>> They write a test
>>>>> Pass the keyboard to the first person
>>>>> Switch partners
>>Don't forget to refactor after each passing test. Keeping the code
>>>>clean and readable is the reason we put so much effort into software
>>>>development. If code was naturally easy to maintain, we'd not need all
>>>>this craftsmanship stuff in the first place :)
>>>>--
>>>>Curtis Cooley
>>curtis.coo...@gmail.com
>>>>home:http://curtiscooley.com >>>>blog:http://ponderingobjectorienteddesign.blogspot.com >>>>===============
>>>>Leadership is a potent combination of strategy and character. But if
>>>>you must be without one, be without the strategy.
>>>>-- H. Norman Schwarzkopf
Excerpts from zdsbs-at-yahoo.com zdsbs-at-yahoo.com |Software_Craftsmanship|'s message of Mon Nov 02 10:47:34 -0600 2009:
> I'm trying to come up with some ideas for skilling myself and my co-workers > up. I'm in a small company with 6 developers. Most of us have between 2-6 > years experience. Not many people here keep very up to date in the dev > community. Folks here seem interested in learning more, but as a team we > haven't been very good at the ad-hoc learning, so I want to bring some > structure. > I want to come up with something sustainable so that we can start to change > the culture here. Since we don't have any very experienced people here any > activities we did would have to involve everyone doing the learning, we have > no "teacher". > Also any activities I come up with would have to fit into our work load > (realistically I could get 1 - 2 hours a week of peoples time).
I don't mean to be needlessly pessimistic. But I feel I was in a similar situation in a previous job and reached huge frustrations. I reached a point personally where I was taking a much more active interest in process management, testing strategies, flexible design, and other software pragmatics. I was enthused about how much was out there, and hoping to get others equally excited. I tried all kinds of communication strategies to engage my peers, including side conversations, setting up a blog, writing up wiki pages, and hosting educational brown-bag sessions. Ultimately, my cohorts were at best only interested in non-invasive spoon-feeding. Management was pretty much disinterested, and the organization as a whole reflected that leadership.
The only solution that really panned out was to look for another job. I found a job by networking with groups that were likely to have like-minded people, and overall I think it paid off.
I'm just worried when I hear things like "not keeping up," "not good at learning," and "can only give 1-2 hours a week." Especially, with limited expertise, I feel there's some abrupt limitations you might run into. Something has to give. Here's some options:
- Management can advocate software craftsmanship, which I don't think should feel like a small allocation of time, but something that's integral to the whole process.
- Developers can be motivated to learn more in their personal time. Obsolescence makes for a nice fear-based motivator.
- Expertise can be hired into the organization. It's just amazing how much can be learned on the job when pairing with an expert.
Perhaps there's most options out there. Those are just what came to mind.
On Nov 3, 7:22 am, "Sukant Hajra" <33jlhr...@sneakemail.com> wrote:
> I tried all kinds of communication strategies to engage my peers,
> including side conversations, setting up a blog, writing up wiki pages, and
> hosting educational brown-bag sessions. Ultimately, my cohorts were at best
> only interested in non-invasive spoon-feeding.
1. Pick strategies that require the least amount of discipline, especially
discipline outside of work hours.
What this means can vary by team culture, but the point is to find ways of
learning that the team will WANT to participate in. That might mean you
convince management to provide free food or some type of non-learning
incentive. Do not to force people into this, and be prepared to do a lot of
extra work on your own in the beginning.
2. Pick tools/ideas that will immediately improve the everyday working
livesof people.
I typically get a good response from these things: continuous integration,
simple dependency injection between layer/tiers, mocking frameworks. ORMs
can be impressive, but a lot of people react very negatively to ORMs.
So, to recap: make it easy; make the benefit obvious. If you try for a month
or two and nobody responds, it might be time to find a new job -- maybe your
peers just don't care, or maybe you're not the person to motivate them.
Either way, you'll be happier elsewhere.
Good luck,
Al
On Tue, Nov 3, 2009 at 2:33 PM, Esko Luontola <esko.luont...@gmail.com>wrote:
> On Nov 3, 7:22 am, "Sukant Hajra" <33jlhr...@sneakemail.com> wrote:
> > I tried all kinds of communication strategies to engage my peers,
> > including side conversations, setting up a blog, writing up wiki pages,
> and
> > hosting educational brown-bag sessions. Ultimately, my cohorts were at
> best
> > only interested in non-invasive spoon-feeding.
In a previous position, we had Technical Staff Meetings every week
(Thursday lunch... company paid to have lunch brought in) and people
took turns presenting.
Most of the people there worked 40ish hours per week, and would find
time to get enough info together to present. Everyone benefitted from
getting "forced exposure", and the people presenting had to dig deeper
(if you want to learn something, teach it). The company buying lunch
gave the message that technical growth was important.
YMMV.
Ken
On Nov 2, 11:47 am, "zd...@yahoo.com" <zd...@yahoo.com> wrote:
> I'm trying to come up with some ideas for skilling myself and my co-
> workers up. I'm in a small company with 6 developers. Most of us have
> between 2-6 years experience. Not many people here keep very up to
> date in the dev community. Folks here seem interested in learning
> more, but as a team we haven't been very good at the ad-hoc learning,
> so I want to bring some structure. I want to come up with something
> sustainable so that we can start to change the culture here. Since we
> don't have any very experienced people here any activities we did
> would have to involve everyone doing the learning, we have no
> "teacher". Also any activities I come up with would have to fit into
> our work load (realistically I could get 1 - 2 hours a week of
> peoples time).
> I've had a few idea and I'd love some feedback on them and any ideas
> for other activities:
> 1) Do a "lecture" series - There are a lot of great talks from
> different conferences. We could listen to a talk then have a short
> discussion about it afterwords
> 2) Have discussion sessions - Someone leads a discussion on a more
> philosophical topic, like DRY or SRP or Technical Debt.
> 3) Book group - I'm a little hesitant about that, because it takes a
> big commitment from everyone to do work before we meet. Without a lot
> of effort I feel it would be difficult to get that kind of commitment
> from the team.
> 4) Brown bags - Each week (or month) someone gives a technical
> presentation.
The key ideas here are etudes (http://thiagi.com/games.html) combined with the practices from Fearless Change and Agile Retrospectives books. Personally I found the model behind the Fifth Discipline overwhelming.
Personally I made great experiences with Brown bags and lecture series as you mentioned them down there. Since I'm working in a "busy" company, it's hard to bring in such activities. Usually invitees come to the brown bags or coding dojos, but after 3 or 4 of these less and less come there until the approach is dropped. It's a bit depressing, but you can't force anyone to learn something new...
> I'm trying to come up with some ideas for skilling myself and my co-
> workers up. I'm in a small company with 6 developers. Most of us have
> between 2-6 years experience. Not many people here keep very up to
> date in the dev community. Folks here seem interested in learning
> more, but as a team we haven't been very good at the ad-hoc learning,
> so I want to bring some structure. I want to come up with something
> sustainable so that we can start to change the culture here. Since we
> don't have any very experienced people here any activities we did
> would have to involve everyone doing the learning, we have no
> "teacher". Also any activities I come up with would have to fit into
> our work load (realistically I could get 1 - 2 hours a week of
> peoples time).
> I've had a few idea and I'd love some feedback on them and any ideas
> for other activities:
> 1) Do a "lecture" series - There are a lot of great talks from
> different conferences. We could listen to a talk then have a short
> discussion about it afterwords
> 2) Have discussion sessions - Someone leads a discussion on a more
> philosophical topic, like DRY or SRP or Technical Debt.
> 3) Book group - I'm a little hesitant about that, because it takes a
> big commitment from everyone to do work before we meet. Without a lot
> of effort I feel it would be difficult to get that kind of commitment
> from the team.
> 4) Brown bags - Each week (or month) someone gives a technical
> presentation.
> Personally I made great experiences with Brown bags and lecture series as you > mentioned them down there. Since I'm working in a "busy" company, it's hard to > bring in such activities. Usually invitees come to the brown bags or coding > dojos, but after 3 or 4 of these less and less come there until the approach is > dropped. It's a bit depressing, but you can't force anyone to learn something > new...
I've done brown bags at previous companies, it was permitted by management, and I had the same experience, attendance petered out. What ever we do here I plan on getting more formal management support. I hope that support will help alleviate the issue (but maybe I'm just being naive) . It's also my belief that folks (okay at least the folks at my company) are really interested in learning more, so I don't think I'll need to do too much wrangling, it's more of a finding the time / getting the support. Oh... and having good topics.
So my question is : How can we keep brown bags from 'petering out' ?
How can we keep busy people interested in attending brown bags? I
would like answers to this.
In the past I have sometimes been guilty of shying away from brown
bags because they took up my lunch time (especially if I had planned
to use my lunch time for some personal errand). I am usually happy to
attend brown bags if they are not during lunch time, and take no
longer than an hour (We got permission from management to do that on
one project, and it worked out pretty good).
--ikenna nwaiwu
On Nov 6, 3:00 pm, Markus Gaertner <mgaer...@googlemail.com> wrote:
> The key ideas here are etudes (http://thiagi.com/games.html) combined with the
> practices from Fearless Change and Agile Retrospectives books. Personally I
> found the model behind the Fifth Discipline overwhelming.
> Personally I made great experiences with Brown bags and lecture series as you
> mentioned them down there. Since I'm working in a "busy" company, it's hard to
> bring in such activities. Usually invitees come to the brown bags or coding
> dojos, but after 3 or 4 of these less and less come there until the approach is
> dropped. It's a bit depressing, but you can't force anyone to learn something
> new...
> > I'm trying to come up with some ideas for skilling myself and my co-
> > workers up. I'm in a small company with 6 developers. Most of us have
> > between 2-6 years experience. Not many people here keep very up to
> > date in the dev community. Folks here seem interested in learning
> > more, but as a team we haven't been very good at the ad-hoc learning,
> > so I want to bring some structure. I want to come up with something
> > sustainable so that we can start to change the culture here. Since we
> > don't have any very experienced people here any activities we did
> > would have to involve everyone doing the learning, we have no
> > "teacher". Also any activities I come up with would have to fit into
> > our work load (realistically I could get 1 - 2 hours a week of
> > peoples time).
> > I've had a few idea and I'd love some feedback on them and any ideas
> > for other activities:
> > 1) Do a "lecture" series - There are a lot of great talks from
> > different conferences. We could listen to a talk then have a short
> > discussion about it afterwords
> > 2) Have discussion sessions - Someone leads a discussion on a more
> > philosophical topic, like DRY or SRP or Technical Debt.
> > 3) Book group - I'm a little hesitant about that, because it takes a
> > big commitment from everyone to do work before we meet. Without a lot
> > of effort I feel it would be difficult to get that kind of commitment
> > from the team.
> > 4) Brown bags - Each week (or month) someone gives a technical
> > presentation.
One way we keep brown brown bags from petering out is to have the
company pay for lunch. As long as the time is used effectively, it's
a relatively cheap investment for the employer, and should pay for
itself over the course of 6 months (as new knowledge is acquired and
leveraged).
On Sat, Nov 7, 2009 at 9:05 AM, Ikenna <ikenn...@gmail.com> wrote:
> So my question is : How can we keep brown bags from 'petering out' ?
> How can we keep busy people interested in attending brown bags? I
> would like answers to this.
> In the past I have sometimes been guilty of shying away from brown
> bags because they took up my lunch time (especially if I had planned
> to use my lunch time for some personal errand). I am usually happy to
> attend brown bags if they are not during lunch time, and take no
> longer than an hour (We got permission from management to do that on
> one project, and it worked out pretty good).
> --ikenna nwaiwu
> On Nov 6, 3:00 pm, Markus Gaertner <mgaer...@googlemail.com> wrote:
>> I attenended a nice talk on Team learning at the Agile Testing Days from Declan
>> Whelan. Gojko Adzic made a fine review of the session:http://gojko.net/2009/10/15/how-to-promote-learning-in-software-teams/ >> He had a similar presentation at Agile 2009.
>> The key ideas here are etudes (http://thiagi.com/games.html) combined with the
>> practices from Fearless Change and Agile Retrospectives books. Personally I
>> found the model behind the Fifth Discipline overwhelming.
>> Personally I made great experiences with Brown bags and lecture series as you
>> mentioned them down there. Since I'm working in a "busy" company, it's hard to
>> bring in such activities. Usually invitees come to the brown bags or coding
>> dojos, but after 3 or 4 of these less and less come there until the approach is
>> dropped. It's a bit depressing, but you can't force anyone to learn something
>> new...
>> > I'm trying to come up with some ideas for skilling myself and my co-
>> > workers up. I'm in a small company with 6 developers. Most of us have
>> > between 2-6 years experience. Not many people here keep very up to
>> > date in the dev community. Folks here seem interested in learning
>> > more, but as a team we haven't been very good at the ad-hoc learning,
>> > so I want to bring some structure. I want to come up with something
>> > sustainable so that we can start to change the culture here. Since we
>> > don't have any very experienced people here any activities we did
>> > would have to involve everyone doing the learning, we have no
>> > "teacher". Also any activities I come up with would have to fit into
>> > our work load (realistically I could get 1 - 2 hours a week of
>> > peoples time).
>> > I've had a few idea and I'd love some feedback on them and any ideas
>> > for other activities:
>> > 1) Do a "lecture" series - There are a lot of great talks from
>> > different conferences. We could listen to a talk then have a short
>> > discussion about it afterwords
>> > 2) Have discussion sessions - Someone leads a discussion on a more
>> > philosophical topic, like DRY or SRP or Technical Debt.
>> > 3) Book group - I'm a little hesitant about that, because it takes a
>> > big commitment from everyone to do work before we meet. Without a lot
>> > of effort I feel it would be difficult to get that kind of commitment
>> > from the team.
>> > 4) Brown bags - Each week (or month) someone gives a technical
>> > presentation.
Hello,
I second Dave's advice. I have set up a weekly coding dojo session in
the company I currently work with and the management agreed to pay for
the sandwiches. We manage to gather 5-10 people each week, not always
the same one, and it has been lastin since June.
But of course, you cannot really prevent "petering out". It is a
constant thing I found over the course of my professionnal life that
whatever group you are in and whatever project you start, there always
will be 10-20% people enthusiastic, 60-70% passive followers and
10-20% reluctant opponents. The only way to prevent such an initiative
from losing too much steam is to be endurant: Even if you happen to
run session with 2 other people, keep going and talking about it. You
have to outrun natural exhaustion of the novelty effect to reach the
steady-state where people start incorporating the session's objectives
and rules and it becomes normal part of your business.
On Sat, Nov 7, 2009 at 10:12 PM, Dave Hoover <dave.hoo...@gmail.com> wrote:
> One way we keep brown brown bags from petering out is to have the
> company pay for lunch. As long as the time is used effectively, it's
> a relatively cheap investment for the employer, and should pay for
> itself over the course of 6 months (as new knowledge is acquired and
> leveraged).
> On Sat, Nov 7, 2009 at 9:05 AM, Ikenna <ikenn...@gmail.com> wrote:
>> So my question is : How can we keep brown bags from 'petering out' ?
>> How can we keep busy people interested in attending brown bags? I
>> would like answers to this.
>> In the past I have sometimes been guilty of shying away from brown
>> bags because they took up my lunch time (especially if I had planned
>> to use my lunch time for some personal errand). I am usually happy to
>> attend brown bags if they are not during lunch time, and take no
>> longer than an hour (We got permission from management to do that on
>> one project, and it worked out pretty good).
>> --ikenna nwaiwu
>> On Nov 6, 3:00 pm, Markus Gaertner <mgaer...@googlemail.com> wrote:
>>> I attenended a nice talk on Team learning at the Agile Testing Days from Declan
>>> Whelan. Gojko Adzic made a fine review of the session:http://gojko.net/2009/10/15/how-to-promote-learning-in-software-teams/ >>> He had a similar presentation at Agile 2009.
>>> The key ideas here are etudes (http://thiagi.com/games.html) combined with the
>>> practices from Fearless Change and Agile Retrospectives books. Personally I
>>> found the model behind the Fifth Discipline overwhelming.
>>> Personally I made great experiences with Brown bags and lecture series as you
>>> mentioned them down there. Since I'm working in a "busy" company, it's hard to
>>> bring in such activities. Usually invitees come to the brown bags or coding
>>> dojos, but after 3 or 4 of these less and less come there until the approach is
>>> dropped. It's a bit depressing, but you can't force anyone to learn something
>>> new...
>>> > I'm trying to come up with some ideas for skilling myself and my co-
>>> > workers up. I'm in a small company with 6 developers. Most of us have
>>> > between 2-6 years experience. Not many people here keep very up to
>>> > date in the dev community. Folks here seem interested in learning
>>> > more, but as a team we haven't been very good at the ad-hoc learning,
>>> > so I want to bring some structure. I want to come up with something
>>> > sustainable so that we can start to change the culture here. Since we
>>> > don't have any very experienced people here any activities we did
>>> > would have to involve everyone doing the learning, we have no
>>> > "teacher". Also any activities I come up with would have to fit into
>>> > our work load (realistically I could get 1 - 2 hours a week of
>>> > peoples time).
>>> > I've had a few idea and I'd love some feedback on them and any ideas
>>> > for other activities:
>>> > 1) Do a "lecture" series - There are a lot of great talks from
>>> > different conferences. We could listen to a talk then have a short
>>> > discussion about it afterwords
>>> > 2) Have discussion sessions - Someone leads a discussion on a more
>>> > philosophical topic, like DRY or SRP or Technical Debt.
>>> > 3) Book group - I'm a little hesitant about that, because it takes a
>>> > big commitment from everyone to do work before we meet. Without a lot
>>> > of effort I feel it would be difficult to get that kind of commitment
>>> > from the team.
>>> > 4) Brown bags - Each week (or month) someone gives a technical
>>> > presentation.
On Sun, Nov 8, 2009 at 09:26, Arnaud Bailly <arnaud.oq...@gmail.com> wrote: > You > have to outrun natural exhaustion of the novelty effect to reach the > steady-state
I am not quite sure of how this quote shall be understood in relation
with my sentence. Maybe this is due to my poor command of english
language? Could you please elaborate ?
> I am not quite sure of how this quote shall be understood in relation
> with my sentence. Maybe this is due to my poor command of english
> language? Could you please elaborate ?
OK, no problem. YEs, I thought you were referring to the last part of
the text, but was unsure. You could also hint at the fact that pushing
such practices in enterprise could be some form of "inner ring"
constructin :-)
On Mon, Nov 9, 2009 at 12:51 PM, SimoneB <simone.bus...@gmail.com> wrote:
> Sorry if I haven't been explicit. I was referring to the quoted
> statement:
>> You have to outrun natural exhaustion of the novelty effect
> Which brought the transcript in the link to my mind. I guess it's
> fundamental to bring in people not looking just for the novelty-ring
> effect.
> On Nov 9, 8:56 am, Arnaud Bailly <arnaud.oq...@gmail.com> wrote:
>> I am not quite sure of how this quote shall be understood in relation
>> with my sentence. Maybe this is due to my poor command of english
>> language? Could you please elaborate ?
On Sun, Nov 8, 2009 at 12:26 AM, Arnaud Bailly <arnaud.oq...@gmail.com> wrote:
> Hello, > I second Dave's advice. I have set up a weekly coding dojo session in > the company I currently work with and the management agreed to pay for > the sandwiches. We manage to gather 5-10 people each week, not always > the same one, and it has been lastin since June.
> But of course, you cannot really prevent "petering out". It is a > constant thing I found over the course of my professionnal life that > whatever group you are in and whatever project you start, there always > will be 10-20% people enthusiastic, 60-70% passive followers and > 10-20% reluctant opponents. The only way to prevent such an initiative > from losing too much steam is to be endurant: Even if you happen to > run session with 2 other people, keep going and talking about it. You > have to outrun natural exhaustion of the novelty effect to reach the > steady-state where people start incorporating the session's objectives > and rules and it becomes normal part of your business.
George Leonard addresses this phenomenon very well in his book "Mastery". You're butting up against homeostasis, the strong natural desire for people and systems to want to resist change. His advice:
1. Be aware of how homeostasis works 2. Be willing to negotiate with your resistance to change 3. Develop a support system 4. Follow a regular practice (like what Arnaud is saying above) 5. Dedicate yourself to lifelong learning
Here's a terrific way to continually re-ignite a group:
Have a short series (2 to 4 meetings) on a particular topic and then
"restart" the group by changing your focus.
People often feel uncomfortable jumping into an established group.
Even loyal attendees get board. This strategy of "rebooting" the group
provides natural points when all the members of the group can get
excited about something new and can invite others. Then you can send
out messages like this:
Hey guys, we spent the last 3 weeks looking at NHibernate and here are
a few things we learned.
Join us next week as we start a new series on TDD. Here are some of
the things we'll be covering. It's gonna be sweet.
And there will be free food.
See you there!
You can apply the Reboot Principle (yes, I'm coining that term right
now) for your individual learning and life in general. If I focus on
one area or topic for a long period of time, eventually I will get
board. Every 60 days, I come up with 3 areas of life I'm going to
focus on. That focus allows me to get things done in those areas in
that period of time. Then I'm ready to move on to something new.
On Nov 7, 9:05 am, Ikenna <ikenn...@gmail.com> wrote:
> So my question is : How can we keep brown bags from 'petering out' ?
> How can we keep busy people interested in attending brown bags? I
> would like answers to this.
> In the past I have sometimes been guilty of shying away from brown
> bags because they took up my lunch time (especially if I had planned
> to use my lunch time for some personal errand). I am usually happy to
> attend brown bags if they are not during lunch time, and take no
> longer than an hour (We got permission from management to do that on
> one project, and it worked out pretty good).
> --ikenna nwaiwu
> On Nov 6, 3:00 pm, Markus Gaertner <mgaer...@googlemail.com> wrote:
> > The key ideas here are etudes (http://thiagi.com/games.html) combined with the
> > practices from Fearless Change and Agile Retrospectives books. Personally I
> > found the model behind the Fifth Discipline overwhelming.
> > Personally I made great experiences with Brown bags and lecture series as you
> > mentioned them down there. Since I'm working in a "busy" company, it's hard to
> > bring in such activities. Usually invitees come to the brown bags or coding
> > dojos, but after 3 or 4 of these less and less come there until the approach is
> > dropped. It's a bit depressing, but you can't force anyone to learn something
> > new...
> > > I'm trying to come up with some ideas for skilling myself and my co-
> > > workers up. I'm in a small company with 6 developers. Most of us have
> > > between 2-6 years experience. Not many people here keep very up to
> > > date in the dev community. Folks here seem interested in learning
> > > more, but as a team we haven't been very good at the ad-hoc learning,
> > > so I want to bring some structure. I want to come up with something
> > > sustainable so that we can start to change the culture here. Since we
> > > don't have any very experienced people here any activities we did
> > > would have to involve everyone doing the learning, we have no
> > > "teacher". Also any activities I come up with would have to fit into
> > > our work load (realistically I could get 1 - 2 hours a week of
> > > peoples time).
> > > I've had a few idea and I'd love some feedback on them and any ideas
> > > for other activities:
> > > 1) Do a "lecture" series - There are a lot of great talks from
> > > different conferences. We could listen to a talk then have a short
> > > discussion about it afterwords
> > > 2) Have discussion sessions - Someone leads a discussion on a more
> > > philosophical topic, like DRY or SRP or Technical Debt.
> > > 3) Book group - I'm a little hesitant about that, because it takes a
> > > big commitment from everyone to do work before we meet. Without a lot
> > > of effort I feel it would be difficult to get that kind of commitment
> > > from the team.
> > > 4) Brown bags - Each week (or month) someone gives a technical
> > > presentation.
Set up showings of videos on technical topics you find on the web
(dnrtv.com is a good place to start)
and following it up with a 10 to 15 minute discussion of how you can
apply things you learned to the projects you're currently working on.
You don't even have to have a projector. Find someone with a good size
monitor and some speakers and make it work.
Asking people to watch videos during their lunch hour every now and
then is really low pressure and fairly low effort for everyone.
It has the added benefit of bringing in ideas from outside the group
and expanding your horizons.
On Nov 2, 10:47 am, "zd...@yahoo.com" <zd...@yahoo.com> wrote:
> I'm trying to come up with some ideas for skilling myself and my co-
> workers up. I'm in a small company with 6 developers. Most of us have
> between 2-6 years experience. Not many people here keep very up to
> date in the dev community. Folks here seem interested in learning
> more, but as a team we haven't been very good at the ad-hoc learning,
> so I want to bring some structure. I want to come up with something
> sustainable so that we can start to change the culture here. Since we
> don't have any very experienced people here any activities we did
> would have to involve everyone doing the learning, we have no
> "teacher". Also any activities I come up with would have to fit into
> our work load (realistically I could get 1 - 2 hours a week of
> peoples time).
> I've had a few idea and I'd love some feedback on them and any ideas
> for other activities:
> 1) Do a "lecture" series - There are a lot of great talks from
> different conferences. We could listen to a talk then have a short
> discussion about it afterwords
> 2) Have discussion sessions - Someone leads a discussion on a more
> philosophical topic, like DRY or SRP or Technical Debt.
> 3) Book group - I'm a little hesitant about that, because it takes a
> big commitment from everyone to do work before we meet. Without a lot
> of effort I feel it would be difficult to get that kind of commitment
> from the team.
> 4) Brown bags - Each week (or month) someone gives a technical
> presentation.
|
