Ready! Set! Getting New Team Members off to a Good Start.

| by Deborah Hartmann Preuss Follow 0 Followers on Nov 23, 2007. Estimated reading time: less than one minute |
Agile practices promote ongoing team learning, but aren't necessarily as effective for new team members since they focus on reducing the "run time", not the "setup time". Understanding the different learning needs of new team members and addressing them directly with specific onboarding practices is a skillset lost by some teams as they move away from traditional "heavy" management approaches. And yet, the reason that companies implement induction programs for new hires persists. How effective is the one you have for your project? ThoughtWorks trainer and coach, Pat Kua maintains that rolling new team members on to projects can be organised without being difficult.

Kua applies ideas from the world of Lean process, and briefly explains how to use strategies like: preparation email, sharing the "big vision, and maintaining "visible architecture" and "transparent project debt". And he advises:
Try "Letting Go" - Give each new team member enough space to make mistakes in a safe environment. Some lessons are more effective if they learn it themselves.
Read Patrick Kua's InfoQ Article: A Leaner Start: Reducing Team Setup Times

Rate this Article

Adoption Stage

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

Getting New Hires Off to a Good Start by Chris Sims

Often times, a new team member is also a new hire. . .

My friend Peter started working at EvilEmpireSoft on the same Monday that I started at Geekaplex. That Friday, over beers, he told me that he had spent most of his first week waiting for his laptop to show up. When it finally showed up, it had an outdated version of the development environment installed which couldn't compile the code he was supposed to be working on. On top of that, Outlook was misconfigured and wouldn't even think about connecting to the mail server. He spent an afternoon figuring out the configuration only to discover that his email account hadn't been activated yet! "It's as if they were surprised when I showed up for work on Monday. Maybe they forgot that they hired me? I spent the first morning waiting in HR until someone was available to give me paperwork to fill out. After that," he went on, "I spent the afternoon wandering around looking for an empty cube to claim."

I felt bad for Peter, and I was almost embarrassed at how different my first week had gone. My office was just down the hall from my boss's. There was no mistaking that it was mine, as my name was on the plaque next to the door. Inside, I found a shinny new ThinkPad with a docking station and a pair of flat-screen monitors. The drawers in the desk were filled with new pens, pencils, paper, a stapler, and even a box of freshly printed business cards. My boss sat down with me and walked me through my first week, pointing out the various meetings and training sessions that were already on my calendar. There was even a welcome email from the president of the company waiting in my in-box.

"Wow!" Said Peter, "You're like a VIP over there! I feel like most folks don't know I exist, and if they do, they are just hoping that I won't bother them. It really sucks. EvilEmpireSoft seemed so cool and together when I interviewed, but now I'm wondering how they get anything done. They aren't the elite, well-oiled organization that I imagined them to be. I feel like I made a big mistake accepting their offer."

What a big difference attention to detail and a little preparation made. By simply taking the time to provision my office, my boss sent me a strong positive message about the company, and how much they valued me. Additionally, by making sure that I had all the tools I needed to be productive, they let me know that they expected me to be productive. I felt like Geekaplex had it together, and that they would expect me to have it together as well. I felt welcomed and challenged.

Originally posted here:

Why is this a problem? by Steven Devijver

One has to wonder how hard this problem actually is.

I my experience new people that come on board never have all the skills they will require. That's why it's important for me to run my projects in such a way that people aren't expected to be extremely talented.

That's why tasks like updating design documents and writing documentation are part of our iteration planning and burn-down charts.

Good agile practices by Wu Junyin

A new project coming soon, I wanna try these agile practices :P

Re: Why is this a problem? by Deborah Hartmann

Steven, it seems you have balanced the tactical (get the software done this week) with the strategic (and make sure we can continue to do so). But not all teams have done this. When things get tough, some decide it's ok to worry about the future in the future, i.e. we'll catch up on that later.

Sounds risky to me :-) The future doesn't usually ask if you're ready before it arrives, lol.

Mimeograph by Greg Helton

Where I work, technical policy announcements are sent out via email and never added to a central repository like a wiki. I was told that the wiki is not the place for that type of info.
New guys are screwed until the parts for our mimeograph machine arrive.

Re: Why is this a problem? by Patrick Kua

Hi there Steven,

The problem I've seen across many projects inside and outside of agile development is most people are thrown onto a project and assumed they'll pick everything up. The best case I've seen is a single day walkthrough where the new person is bombarded with everything in one go.

I wanted to express alternatives that I've found very effective and useful in different circumstances to drastically improve the learning speed of new team members. I agree that lack of skills can a problem and so plan accordingly. I've also seen people with skills not applying it correctly because they lack the context of the entire project. Hopefully these techniques will help build this context faster for them.

Re: Good agile practices by Patrick Kua

Good luck. I'd certainly appreciate finding out how they were useful/not useful for you.

Good to formalize the process by Jeff Bonnes

Good Article Patrick. In the team I just built I think I did about all of the tasks above, but not formally. I wish I would have had this before I started! It is good to recognize that building a team is different than running a team and has it’s own set of tasks.

One thing that we did do that was very effective was called 'designing the alliance'. It is a bit 'HR' but really effective. Basically, we agree on 4 things:

Granting Power to the Relationship: Permission to be open in communication, How do we communicate when were ________? How do you like to be communicated to?
My communication style is ________.

The logistics of the relationship: when / where you both work, how best to communicate, what is required (updating JIRA, daily scrums etc.) All the stuff that is expected of you (both ways!) as a team members.

Discovery: What needs to be at the heart of our relationship for it to be effective? What are the obstacles or potential obstacles? What might I do that would really piss you off? (You learn a LOT from that one!)

Future: What are your goals for this project? What types of rewards will we both get? How will we celebrate our successes?

If you get this done at the beginning of the relationship (we write it down and all sign it) it really opens of communication with team members from day one.

Re: Good to formalize the process by Deborah Hartmann

Jeff, your "alliance" is interesting. You mention "both" - in a multi-player communication game like a software team, who does this refer to? Thanks.

Spend the time up front by Pete Johnson

Nice article, Pat. I couldn't agree more.

The steps you outline for the onboarding process are good ones that are all well laid out. It's important in the early stages of a project to create the documentation/artifacts you'll need to expedite all those steps when they happen later. If you wait, you'll only be distracted with the other things going on in the project and not do as good a job.

An ounce of prevention absolutely beats a pound of cure here.

Can I be on Jeff Bonnes team? Great outline for setting up the rules of engagement. I'm definitely going to steal those ideas.

Pete Johnson Chief Architect
Personal blog:

I will try it! by Alexander Pavlenko

I'm Alexander Pavlenko, Java Solution Architect. Some days ago, I interviewed a new guy for my project team and he is going to join us next week. I will try this practise and, of course, I will write about my experience.


Re: Good to formalize the process by Patrick Kua

Hi Jeff,

I'm very intrigued about your alliance approach. I will definitely try it out the next situation I get to.

Thanks for sharing.

Re: Good to formalize the process by Jeff Bonnes

Hi Deb. In our context, it was the Scrum master and the team members as a start. We also had some Senior developers do it with starting programmers. It could also happen between team members. What I have found is that if it 'starts at the top' the communication between all team members is open, it filters to all the relationships (or at least most!)

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

13 Discuss