What are they?
One hour every week. Gather the whole team together, and learn something.
What should we learn about?
Anything that will be of interest to your team, work-related. Some examples:
- This new open source library/project/technology we (can) use
- New programming language
- This cool testing technique
- A certain module of the business application
- The hardware architecture of our data-centers
- Some applied computer science (algorithms and stuff)
What is the concrete contents of a Knowledge Meeting?
Anything that'll make you learn. Examples:
- Let people present the things they already know, but..
- Give people time to prepare their presentations (1 hour per 10 minutes of presentation, as a rule-of-thumb, perhaps?)
How do I get started?
You need support from up top. You simply can't yank people one hour out of their working time every week.
If you don't get support from up top, you're gonna have to do it on a volunteer basis. I've written some strategy for this in my post about workshops. Over time, management will hopefully see value of the knowledge meetings, and start sponsoring them before people start leaving for companies that invest in people's knowledge.
- Give people plenty of time up front to prepare their presentation (one month)
- Always have the knowledge meeting the same time, week after week
- Point out a person to make sure the meetings go smoothly (prepare agenda).
- Over time, let this "knowledge facilitator" role rotate.
- If it gets hard using the internal knowledge to keep the meetings busy, increase budget: either give people more time to research/preparations, send them to conferences/courses, or hire in some externals to do the occasional gig with presentation.
- If the knowledge meeting starts losing time to other activities, like retrospectives, try to get a new time appointed to it.
- If you run out of content and discussion, cut the meeting short
So, I scribbled this together rather quickly, so let me know if I left something out, or if you've got any questions.