BT

Inducting Newbies On Large Agile Projects

| by Mike Bria Follow 0 Followers on Mar 25, 2009. Estimated reading time: 2 minutes |

One advantage an agile team has is that getting new members brought up to speed can often occur in a more natural, efficient way than when people were working in a soloed, waterfall world. This is particular true if the team is co-located, communicating frequently and effectively, working from small stories, and especially when using pair-programming.

In a recent article Anand Vishwanath agrees with this, stating that for most small to medium sized projects new members can be assimilated into an agile team without much special ceremony, but feels that larger projects require a little something more. He suggests for large agile projects that using a small scale "simulation project" might be the best approach to getting the newbies into the groove. In a nutshell, "maintain a group of 4-6 new joinees in one batch of induction" and have them execute a few mini-iterations over a 1-2 week period with the help of a few experienced mentors.

Vishwanath stresses the most important component of the induction project be the presence of mentors able to guide the inductees during the simulation. He states that among these mentors should be:

  • A Mentor Developer, who is a seasoned "Journeyman" developer capable of helping the inductees understand the codebase and domain of the project. This person will work full time on the simulation, pairing with with inductees and running learning discussions.
  • A Mentor Business Analyst, working in a part-time role on the simulation to act as the customer to the developers, as well as to coach inductee BA's if they exist.
  • A Mentor Quality Analyst, also working part-time to help the group with activities and learnings regarding their specialty.

Vishwanath discusses how this simulation will operate as an actual iteration (or even a few), including an iteration planning meeting, end-of-iteration demo and retrospective, and as much as what ever other constructs your real project employs is possible.

Vishwanath gives direction to present the group with a variety of stories in the simulated iteration. For example, he suggests to include some simple functional stories, and also to save room for some "refactoring stories" that are totally technical in nature to give the inductees a good chance to really get dirty with the project's code-base and architecture.

Vishwanath also gives a few suggestions on how to collect artifacts from the simulation that can be leveraged in future inductions. For example, he highlights capturing video recordings of sessions from the simulation, as well as learnings highlighted from the iteration retrospectives.

If this quick summary sounds interesting to you, take a look a Vishwanath's article. Does seem like a good approach? Knowing your environment, is it feasible for you? Have you done something similar and if so with what outcome?

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT