Crack the whip

I enjoy wandering into conference rooms. Because in conference rooms, people leave stuff on the whiteboard. Ideas, thoughts, discussions are often not erased at the end of the session.

This habit makes interesting reading for the post discussion observer. Especially if the discussion involved top management. Now that’s a sure way to feed the grapevine. If you want to start a rumor, get some executives in a conference room, scribble on the whiteboard and leave it there for all wanderers to read.

“Year end target: Reduce existing staff by 30% and add 50% staff offshore”(an actual line on a whiteboard somewhere). Just imagine leaving such an incendiary line on the whiteboard. Sit back and watch the morale plummet or even worse, watch some people leave in a what they think is a preemptive move. In the end, there was no such move by the organization.

Here is another quote I picked up recently from a left over whiteboard, “Crack the whip”. Ostensibly, it was listed a strategy to avoid failure. Frankly, it conjured images of a World War II Japanese prison officer intent on making the allies prisoners of war completing the bridge over river Kwaii.

What are the software developers to make of such a strategy?

I think people write on the whiteboard due to a few different motivations. The obvious one is that they are thinking as they are writing in a discussion. Ideas are flowing, different people are speaking and someone must consolidate these points on the board.

When there is primarily one dominant person in the discussion, it is usually to enunciate, display the thoughts, and underscore the spoken word.

In any case, all useful whiteboard scribble needs to be transferred to the computer or a notified or I threaten to make a collection of them and publish a book filled with leftover whiteboard scribble.

This entry was written by Amit, posted on December 29, 2005 at 1:58 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.

Non stable software teams and ramp up times

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 Amit, posted on at 1:54 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.