• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How to better plan for self-improvement or training in Agile projects

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Do you see any better way to do this?
 
author
Posts: 46
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Manikanda kumar
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for reply.

'Research Time' idea sounds great, will try in our team. Looking forward for more such tips in your Book.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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!
 
Manikanda kumar
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic