What is the average time software teams last without an existing member leaving or a new one being added?
What is the average percentage of teams remaining same from start to end in a given project. I will be very surprised if the number is in double digits.
Which brings me to the next question. How long does it take for a new member to come up to speed in a team. Adding people to a late project only makes it later as we are told again and again. If adding new people to a team is the reality that we must face, why is there no focus on techniques to make newer people in the team productive faster ?
Having documentation is better than not having it, however, it is not the sole panacea of reducing new member ramp up times.
The problem is two fold. The new member is trying his/her best to come up to speed. This introduces friction for the rest of the team members and slow them down. If the new member is not asking questions, he/she is not learning. This scenario is inversely proportional to the team moving forward.
So careful project managers will add team members with the knowledge that overall productivity will suffer. They are aware of the productivity loss and are hoping for long term productivity gain at the expense of the schedule.
Recently I joined a team in the middle of the project. The project was on full throttle, and the week I joined, most team members were busy fighting fires. As I shunted from meeting to meeting, I kept thinking how I could be productive . Getting off the ground seemed lofty. Acronyms kept flying. I was struggling to keep up. I thought about making a list of every acronym and abbreviation heard in the meetings and then prodding someone after the meeting to learn about each and every one of them. Somehow, I just couldn’t. It seemed like not the best place to start.
So I wanted to make a list of things a team can do to make the transition for a new member a healthy and fun experience.
Here is that partial list of things that help ease the transition:
- Diagrams – Much better when combined with brief text. This might include high level architecture, requirements, and designs.
- Deployment topology – New members will not automatically know where to go looking for things. Give them server names, user its, passwords etc.
- Methodology overview – Ask the new member about their experience and give them an overview of the methodology in use in the current project.
- Key contact list – Tell the new member who the key contacts are in the different areas. The go to people in each area.
- Admin issues – Get them out of the way. Make the new member feel at home. Tell them how to get around, what admin issues they need to be aware of. Time sheets, status reports and any relevant access issues.
- Software Tools in use – Have a handy list of software tools and packages in use. Give it to the new member. Ask them to get themselves familiar with the tools in use if they already aren’t versed in them.
- New Member Experiences – Make each new member write down their experience in terms of what was missing or what took them the longest to grasp and how did they do it ultimately. This will be invaluable for future members.
- Required Reading List – Each project must have a required reading list. A project without mandatory reading list simply means that there has not been enough thought put into research. Keep a required reading list and update it frequently.
This entry was written by , posted on December 29, 2005 at 1:54 pm, filed under Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.