I've been working in Agile projects for close to 2 years now. We have been constantly improving on the agile adoption by learning from earlier mistakes. So far so good, but when it comes to individual development, these tight iterations doesn't seem to provide room these days.
Once we started to successfully adopt Agile with shorter iterations (we follow 2-week iterations). I have always had a thought that Agile keeps people busy doing their work, but leaving no room for self improvement. I agree we can plan earlier for training and others, but our project being a multi-site project, never allows developers to be off for more than 2 days, which will never be enough for any kind of training.
With new additional backlogs every single iteration, we (developers) are always kept busy doing something every iteration, and there were no any significant time given for us to improve ourselves.
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!
James Shore, coauthor of <a href="http://www.amazon.com/Art-Agile-Development-James-Shore/dp/0596527675" target="_blank" rel="nofollow">The Art of Agile Development</a>. Website and blog at <a href="http://www.jamesshore.com" target="_blank" rel="nofollow">http://www.jamesshore.com</A> .
Joined: Sep 14, 2007
Thanks for reply.
'Research Time' idea sounds great, will try in our team. Looking forward for more such tips in your Book.
Originally posted by Manikanda kumar: our project being a multi-site project, never allows developers to be off for more than 2 days, which will never be enough for any kind of training.
I'm not following this reasoning. Would you please elaborate? Thanks!
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Sep 14, 2007
We have projects running across countries which are dependent on each other.
By multi-site, module owners will always be having their own work and are also required to be in supporting role if there is any development from other site which depends on their modules, which never allows any module owner (developer) free for any kind of further learning or training. Also, with this small Iterations (2 weeks) we always get busy throughout the Iteration doing something or at least resolving dependencies, devoting no time for personal development!
Hope this is clear!
Joined: Jul 11, 2001
Does that mean that every module has exactly one owner, which is the only person who can provide support for it?
That surely sounds like a problem to me.
What Agile method are you using that suggests this practice?