Incremental self-education

Question

What is the best way to incrementally educating yourself? I mean I have a team, we work in scrum with 14 days long sprint and I would like to reserve each sprint some time for self-education including theory/practice all together (that whole team will study the same area, for example 4 hours each).

For example to learn design paterns, is there any site (paid or not it doesn't matter) which provides self-education in following form:

• clear explanation of one topic (which could be studied in question of hours)
• provides some primitive self-evaluate test which finds out whether he understood (could be implementation of one example where correct result is also provided)

I think this "school style" would be very efficient and it would be incremental and continuous education. Books usually doesn't provide that self testing part (they are mostly theoretical), and 1 week trainings are different topic (they are expensive and usually 50% forgotten by trainee)

I also very like "Pecha Kucha" presentation format, but it dosn't bring a new "know how" to the team.

I would appreciate any sites or books providing self-education in this format

Answer 1

Sometimes the best way to self test your knowledge on something is to stand before your peers and attempt to explain what you have learned to them as well as answering any questions that they might have on the topic. As such, might I suggest the following:

1. Identify some topics that your team either a) needs improvement on b) are going to be working with in the near future or c) sound interesting and people have expressed an interest in learning about them. If you have a mix of all three then you will likely find that the team is a bit more interested in the "training days" when they come around.
2. Allocate a subject to each of the team members and have them start learning about the topic. This part can be a bit tough as they will need enough lead time to learn and understand the material themselves as well as preparing any presentation. Furthermore, depending upon the number of team members you have, you might need to stagger when they get material to start studying so it is still fresh when they give their presentation.
3. Meet with the presenters a day or two before the training day to determine how much time they need to present. One of the draw backs of systems such as Pecha Kucha is that you might give a cursory examination of a topic that needs a bit of depth, or not go in depth on some slides. If you meet with the presenters, they can draw upon their own learning curve to determine what parts need more or less information.
4. Do the training! Having more than one topic on the training day will keep things a bit fresh and also allow for a natural break or two so that people have a chance to get up and move around a bit.

Something you might also want to try is a "slide-less" presentation in which the presenter has a technical report or the like that they hand out that the audience can study and refer to while they are listening to the presentation. This also provides folks with something to take notes on and also allows the presenter to give much more detailed information than they might be able to do in a slide (i.e. instead of a slide with some code, provide a full listing with the line numbers that can be referenced throughout the talk.)

Once you get a feel for how things run you can try different presentation formats, having panel discussions, or having invited speakers come in to present on a topic. One of the key things is likely to keep the training days feeling "fresh" as opposed to re-hashing topics people already know or aren't interested in. Another option is to also allow for side projects that the team members can work on and then present.

One final thing to note: while not mentioned, having the developers present and speak to their peers also gives them a chance to work on their public speaking skills which is good for their long term professional development in additional to learning about the topic they are presenting.