Directi Flexi-Learning - Our strategies for knowledge sharing

This document introduces the concept of Flexi-Learning - describing strategies that a team can implement for percolating skills, processes and practices that the team considers important, within the members of the team. This concept was born out of a recent dialogue on the challenges in adopting Agile development practices within our development team as a repeatable ongoing activity, today and in the future as the team expands. While this document uses the dev team as an example, the strategies explained within this document can be applied to any and every department / team.

For instance - we discovered the following challenges with respect to adopting Agile development practices within our dev team -

Many of the existing team members and new joinees do not possess the skills and knowledge of practices we consider important
Team ramp up results in new additions on a monthly basis
It is not practical for us to organize a classroom style training session for each new set of joinees due to opportunity costs
Training videos can help, but different people have different preferences for learning (some prefer reading, some prefer conversation, some prefer training videos etc)
As newer people join, there is a possible risk of losing out on the best practices, processes and skills we consider important

Therefore the goal was to come up with alternatives to conventional training processes that can address some of these concerns. As a clarification the Flexi-Learning strategies listed below are not meant to replace other conventional training processes. But the strategies below can supplement, and possibly even supercede other conventional training in overcoming the challenges described above

List down the skills and practices that are important to your team

As a first step list down the specific skills / practices / processes that are important to your team.
This list does not need to be static and can evolve from time to time. But it is important to know and maintain the list.
For instance, in the software engineering team we consider the following general skills and practices are important to us -
- OOPs
- Design Patterns
- Refactoring
- Agile development
- TDD
The above list can change over time. Infact it is highly likely that the list would change
- Practices and skills evolve. Skills / practices that are important to the team today may be different from those that are important to the team in the future
- Different skills are required at different levels
Additionally each team will have variants of the above list. For instance the Mail Server Dev team may choose to add SMTP/POP/IMAP or QMail as required skills, or a web app development team may decide to add Ajax, Flex etc
This list needs to be decided by the team, and recorded appropriately. For instance in our case we record this in a Team Wiki. The list can be revisited once every few months or when a new skill / practice needs to be introduced

Induction

When an employee joins he needs to be given a set of books that we call textbooks. each department and team has its own list which they maintain.All hr needs to do is ensure they catch the mentor / superior of the individual joining and get the books that should be provided to this individual

Select and provide Text-Books

Select a set of books that cover the above skills and practices. We list these out on an internal wiki page. Then buy a gazillion copies of each of them to give out to each individual within the team. Basically when a new developer joins our organization his superior or mentor selects 3-5 books from this list that we have in stock and hands him the set. These are not lent, but given. Which means the developer takes them home with him. They are his copies. They are essentially his text-books for his tenure at Directi. This helps in the following way -

Since these books are given to the individual as a part of his joining process, they communicate a sense of importance. The individual understands that we treat these subjects seriously when it comes to project development
Most people can relate to this metaphor quite easily. As students, we have always purchased a set of books at the beginning of our year in school / college. It is easy to relate to being given a set of text-books in a similar manner upon joining a company
Most people will tend to read a book if it is lying around with them at home, at sometime or the other
This results in the individual spending time acquiring important skills outside of the office
People are encouraged to read a book, when they realize others in their team have read it, and refer to terminology and examples from it in conversation
Learning from a professionally written book is often much easier than learning using the Internet, since information in a book is structured and typically flows from basic concepts to advanced concepts, leaving no ambiguities or gaps
For those who like reading, there is no additional encouragement required as such

The list of books can evolve and change over a period of time. Also switching teams is like switching courses in a school. The individual may need a fresh set of text-books. Additionally, every now and then (6 months to a year) a new the list maybe revised and new books maybe provided to everyone in the team. These decisions are left to each superior. As a practice, each team maintains their list of textbooks on our common wiki page.

Pairing

Pairing is actually an agile development practice that can infact be applied to any team. Pairing consists of having two individuals work together on a single desk, side-by-side, on a single task. Without getting into implementation details (which we can cover independently) some of the key advantages of pairing are information exchange, knowledge percolation, risk reduction by reduction in errors, out-of-the box thinking etc. Pairing can be quite beneficial for new individuals who join a team.

Balancing Recruitment

None of the strategies listed here work if one introduces a 100 new unskilled individuals into a 10 people team. It is essential therefore, to balance recruitment by -

Adding individuals to a team in a manner that they can be absorbed
Balancing skill sets by recruiting a reasonable proportion of individuals who already possess expertise and skills that we require

Workshops - Learning by Activity

Once every 3-4 weeks various teams take out half a day to organize a workshop on any topic that the team wants
The workshop must ideally focus on a single topic
It can be conducted by anyone in the team (ideally a different person each time)
It can be open to anyone to attend
Individuals participating in the workshop should be ideally divided into teams of not less than 2 people so that it encourages collaboration
If multiple teams from within the organization engage in this workshop it also facilitates cross pollination
The workshop must be a hands-on session involving a practical activity, and NOT a theory presentation by the conductor
In our eg the following ideas can be translated into workshops -
- Designing an elevator using OOPs, or refactor a particular piece of code etc
The topic does not necessarily have to be directly related to a live product
A workshop of this nature results in the following advantages -
- Everyone has different learning styles and preferences. Some people like self-learning through books and videos while others prefer a classroom style approach. However as the old adage goes - Actions speak louder than words. There is no substitute for practical experience
- Workshops encourage collaboration, cross-pollination, communication and if different individuals take initiative to conduct these, then they enhance presentation skills of individuals within the organization

Repetition and Reinforcement

Repetition is a simplistic yet very powerful tool. One cannot possibly under-estimate its importance. A typical team has several meetings and sessions during the course of a week/month. It is easy to take 2 minutes in each of these meetings to stress on the skills and practices that are important for the team. All it requires is repeating 2-3 sentences about these practices and highlighting some of the benefits and reasons why we consider them important, possibly sharing some recent anecdotes.

This is in no way a redundant exercise. Repetition helps transition a practice from your concious to your sub-concious. Repetition makes an activity second-nature. Infact as kids, most of the things we have learnt have been by repetition, whether it was the alphabet or multiplication tables .

Note that the technique of repetition requires an audible oral statement in front of an audience. It cannot be a mental note. It must be emphatically stated and heard, possibly with visual metaphors that people can relate to.

Certifications

If there are any certifications or exams that test the skills and practices in question, you may want to explore the option of choosing one or more of these and requiring individuals within your team to appear for these and pass them with a certain score. For instance we encourage and sponsor select certifications in Java / .NET / System Administration and other varied subjects, for individuals within our dev teams.

This helps in the following ways -

Typically individuals are motivated to learn skills and adopt practices if there is a specific goal in mind. A certification or exam serves as such a goal
It encourages healthy competition in the team, if everyone in the team has published scores and rankings in such a certification
It also serves as an indication of the capability level of an individual with respect to a certain skill

An absence of any such certification does not mean that one cannot adopt this strategy. Infact, a team can build its own certification by creating an objective question paper which can be used for the same

Rectifying Deviations

At times one will come across situations when individuals in the team deviate from practices we consider important. Each member of the team is responsible on behalf of the entire team for attempting to reduce such deviations unless they are required. If you notice a peer deviating from any important practice, make it a habit to tell them. Infact this can be done in a transparent and open manner too, if the team is comfortable with it, by posting each deviation on a wiki page.

Rectifying deviations is important because not doing so can cause a cascading negative effect. If you spot a deviation in the team and do not speak up, then not only does it result in sub-optimal adoption, but it also sends out an implicit message to the team that maybe these practices / processes / skills are not that important