Hi Manikanda,
We include a discussion of "research time" in the book: half a day each week for developers to devote to self-directed research. Not only is it a good way to learn new things, it adds slack into your iterations, which is good for meeting commitments. As we say in the book:
I've introduced this technique to several teams, and it's paid dividends each time. Two weeks after introducing research time at one organization, the product manager told me that research time was the most valuable time the team spent, and suggested that we double it.
Research time is particularly valuable for XP teams. The continuous drumbeat of iteration deadlines is great for reducing risk and motivating the team to excel, but it can lead to tunnel vision. Dedicated research time gives programmers a chance to widen their ranges, which often leads to insights about how to develop more effectively.
Ultimately, though, the time has to come from somewhere. You might be able to convince people to try research time for a month as an experiment. Hopefully you'll find it as useful as others have.
If you do adopt research time, be rigorous about it. Don't use it as time off or a catch-all for postponed meetings. Ignore your email, turn off your IM, and really focus on your research. Create spike solutions that demonstrate techniques with code rather than just reading. Half a day isn't very long and these techniques will help you get more done.
Some teams schedule a group lunch the following day to talk about what they've discovered. This can be helpful--as the saying goes, you don't really know something until you can teach it. It's also a good way to share and learn from each other.
A completely different approach is to have a book study group once a week during lunch hour or (even better) during their half-day research time.
We have some more tips in the book, but hopefully those ideas will help you get started!
Cheers,
Jim