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.
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: