Friday, 23 March 2007

I work so hard... what is he doing?

A few months ago I faced this question, but in a different form… the question was "What is he doing in the office?" I wasn't really very serious at that time about this since it came in very casually…. While moving ahead a similar question came across in the Chat across Table (CAT meet) with one of the development resources… this time the question was more towards partial resentment… "What is (are) he/they/she doing?"

OK so this is what I think when someone really asks this question to a Manager or the BB… now that I assume that this question comes out of one or more person from a Team… I believe that these questions really affect the Team the moment they get raised…

These are first of the few things I really think why these questions are raised:

1. Is he paid for chatting, reading newspapers and bossing around?
A member not having enough visibility on what others within his team are doing has this question in mind quite often… The best way to avoid this is to let everyone know in a Scrum what each one is up to for that day/week.

2. I have so much of work and he sits Idle?
Most of the time the question comes because of different duties or responsibilities each one is handling… Most of the time people confuse between duties and responsibilities… I really had to mention that "Do you know what your CEO does? And the answer was NO, so the issue here is that the moment you feel you are working hard; you see others not working so hard… Law of nature really….

3. The beginning of the problem is the End of the Day?
So most of the developers tend to stay late at least that's the culture out here in India… many of them are bachelors who prefer not to go on their hostels where they don't have Yahoo, Internet and of course work… So while you work late and late you feel you are the only one in the office who work… no matter you really work till then or just funk around.

4. The taste of the Poison can only be tested when you Taste it?
Many of the aspirants feel that what their superior does or knows is less than what he or she knows and does… common misconception that leads to a Team trauma at the same time raises this question too often in the mind… The major issue here is the poison of success (I am on my way to write this soon) doesnt let them think sensibly...


5. I am always left alone….
Now this is a problem with a genre that has some einsteinius genes… well I really mean that they like to be alone… in their own world, dreaming about the figures and the code they are writing…, most of the times these hysterical genes don't allow them to think anything up until 10 in the night and when they wake up they realize that the whole day is gone doing nothing but programming and it's already next day morning ;). The cause hits the case and the question gets a base…
Now that I have written a bunch of why's I think it will be relevant to put on How to avoid these things…. After all We are here to Grow a Team not Build it;)

Regards
Sameer
http://sameer-shaikh.blogspot.com

Thursday, 22 March 2007

Time to call it Ufffffffffffffffffffff.

The whole of last 2 weeks was like sailing in the boat of problems which was fired by waves of issues, one after the other none of them new. I had to hold this blog for 2 weeks, and now I have to amend it just so that I can put it on a right time, Guess this is the right time….

So coming back to when to call an Ufffff (you call it "stop it" or "Enough" or anything else). I realized that sometimes certain mistakes are repeated, one, two, three and many more time... by the same people differently or by different people in the similar fashion... be it Software development or any other damm piece of profession, to be honest people repeating the mistakes… are not a problem ... it's the management who is the problem here....

How?
OK so here it comes…. Last few months (since I am here with my current employement) (We) had been talking about the Quality in the programming, and in spite of calls and discussions every 2 weeks for the last 1 year I somehow feel that the team makes the same mistakes and gets ignorant about the quality… nothing new... I am sure if you are into a Software Manager you must be facing the same issue…
"Dammit why the hell they dont understand" that's what Prince told me when I was at bolt's office...

Long back I heard a story from Henry Cobb about a Donkey who used to carry some scrap everyday and used to spill part’s of it on the way to the Masters house. The Master did drive the donkey off the path, made barriers to the load so that it doesn’t spill ... But it changed for a day and then the same old story… He had no other choice than whipping, but things never changed for years and years… The moral Henry wanted to give was that if you do the same thing again and again you get into a habit... what I derived from it was the Master never went and analyzed why this happen …simply because he too had a Project Manager’s brain…

The Donkey tells me that certain mistakes remain rectified only till the influence is there … which doesn't means that till the developer thinks that his code is being reviewed he will not make mistake with the quality… it means that till the fire to build the quality code is present in the developer the code produced is quality … the moment this fire gets ceased… I mean urge towards quality consciousness is off the mistake comes into action…

Same thing happened to the cricket … when we started playing cricket for the first time in the organization there were a bunch of guys… the moment there were matchsticks that don't produce flames cricket was off… Thanks to Natwar and Saket that this is being enlightened again….

So the whole point here is that repeated mistakes will come all the way along... all the Management has to do is to think of avoiding the scenarios...

I am sure you have the next How??? ok so I am not coaching you here until you pay me a few grands or promise to subscribe the blog ;) just kidding....here are things that can be done to avoid / tackle repeated mistakes...

1. Make sure that the Objective is in front of the Eyes all the time...
2. Make sure that it is being talked and followed up so that the feeling of the objective been alive is there.
3. Embarrass the odd ones out and publicize it so that everyone understands that mistakes might go un-noticed but repeated mistakes will lead to embarrassment. (This really came up when I was talking to Kari about this in one of the Demo where we were silent spectators...)
4. Cut the root not the branches… meaning cut the causes of the Build breaking not the developer's doing the builds…

Well these are not all…. I am sure all through next few months I am going to face bigger issues than these that will cause bigger than Ass pains… But I am preparing myself for it.... A New Lesson to a repeated problem...

Do you have another How ????

I am preparing a board to list down the Mistakes that we(The Team) makes everyday (at least the ones we catch) and try to work on them, of course there should be the Mistake (wo) Man of the week so that their is a celebrity status to the legends. The plan is to have a Story board of mistakes on a common area so that every one sees it… and the Actions taken on them ... nothing more can get your celebrity ranks high in the company...

Next week I will try to post how this board will look like ….

Regards
Sameer Shaikh
http://sameer-shaikh.blogspot.com

Thursday, 8 March 2007

Monday Morning.... Yuck?????

I recently landed up on this community on Orkut "Monday Sucks" and it was fortunate that there was no surprise… the community is full of Monday Haters… darn… Students, managers, Developers, Executives and a whole bunch of people saying why they hate Mondays…



Well it doesn't really take a community to tell you how much you hate Monday as you see lot of calls being made everyday when it comes to a discussion on a Monday … I don't know all or most reasons exactly why people hate, but I surely got a few things worth mentioning that can make your colleague not hate Monday:

Let your Week not begin with Monday: That is one reason our Sprint starts on Friday…I understand the most boring phase of a WORK LIFECYCLE is the beginning phase (Doesn't apply to you if you are a PP), and that's what every one of us think, Monday is the kickoff of work…

Avoid Meetings on Monday: Most of the Update Meetings happen on Monday, the first fear that comes to an employees mind is … "Damn… I got to update my Boss... and Hell I am not prepared…!" Or "Wish there was no party on the Friday night I would have finished some of my work on the weekend", actually lot more. No Meetings and Updates on Monday morning help release some pressure from the employees ;)

The Beginning of the Day should be 1 in the noon? I will get some stares from Kari (My Boss: D) for this… but I believe lot of guys are up until late even on Sunday nights… Be it a Family Function or a Dinner, or some auspicious occasion or a Bday party… starting late will kick off the thoughts of "Mom don't wake me up this early"

Light as a Feather, Smooth as Sush's cheeks: Mondays should be shorter and sweeter and the day should really begin with some sweet faces around…. It sounded funny to Mark (My previous employer) when I asked him to keep Interviews for BPO section on the Monday afternoon hours…

Well this is not all lot more you can do to get your Monday work as a Saturday… Just that you need to get out of the High School ;)

Regards
Sameer Shaikh

Friday, 2 February 2007

Success is in ????????????

The more of a Manager we be the more we loose on the leadership front… this I have noticed over a period of time while Project Managing…. While I think about all this I realize that this really has nothing to do with Manager or being a leader but rather with everyone be it a developer or QA or Manager… I think success is a radish that everyone really wants to achieve and for that they do anything and everything… I thought I would put up some points that can tell you where we fail in defining success:

Success is in:

1. Empowering the team to handle their tasks but not driving them to solutions….
2. Involving the Team into decision making and not defining what they have to do to achieve a solution…
3. Meeting as a Team to discuss problems and solutions not just taking it away…
4. Responding to queries and exploring solutions rather than waiting for them
5. Being Yourself rather than pretending to be someone else
6. Sharing the experience with everyone and not keeping things within fearing that everyone will be what you are….
7. Listening to what others want to say rather than pretending to know you know everything
8. Telling what you know and exploring the options within but not defining it to be the ultimate solution
9. Reflecting rather than being Opaque… so that other's can have a space to expand
10. Prompting rather than commanding so that everyone gets help wherever required… and still can balance themselves
11. Suggesting rather than dictating so that you learn what is in store with others
12. Connecting rather than isolating…. Like …How good it will be to involve the Developer while we discuss the requirement changes with the BA
13. Digging it rather than wrapping it with some make ups…. Like do you think that there is more of a problem in the solution?
14. Encouraging rather than hiding the credits… Like… This is something that was a problem since long… I am sure this solution will be liked by everyone
15. Focusing rather than deviating…. Like we discuss about all the issues in the company when doing a personal appraisal…
16. Being specific than generalizing like "Saket missed the bug which is causing the broken application" … rather than saying "QA missed the bug or dev did a faulty code to screw the app on a whole" (Sorry Saket that was just an example)
17. Marshalling rather than getting driven …. Like Agreed that this is a problem but for now our objective is to resolve XXX problem… lets come back to this when we have resolved it.
18. Challenging than accepting everything like "do you think that's the ultimate solution?"
19. Reading it to the bottom not just the heading

Information………………

Every morning for years, at about 11:30, the City MIC telephone operator in a small town received a call from a man asking the exact time. One day the operator summed up nerve enough to ask him why the regularity.
"I'm foreman of the local sawmill," he explained. "Every day I have to blow the whistle at noon so I call you to get the exact time."
The operator giggled, "That's really funny," she said. "All this time we've been setting our clock by your whistle.

The moral of the story is that sometimes we rely so much on a set of information that we really forget to testify the originality and reliability of it. You agree or you don’t I see it as a SIN in Project Management. If you want to be a Good Manager you need to make sure that what you have is correct and testified, if not you have to take the pain to do it before actions are performed on it. The added pain you take will also help you be a curious, inquisitive Manager who wants to learn more than pretending to know or giving Bookish answers…

There was a question raised in the SEO caferatti that happened 3 weeks ago at the KP Barista where SEO Manager of BigBytes raised a question saying “I am subscribed to several forums and websites and a part of Global SEO community, yet reading and implementing all the changes is not getting me to a highly trafficked website”. The answer was clear the information he was subscribed to was either not true/ bookish/ not relevant for what he was doing / not a solution and still he ended up spending 3 engineers work on a strategy which was uncertified…. Good Managers take a added step before provoking the team to move in the given direction so that they don’t end up in the debt of Fatal mistakes on irrelevant information.

Where do you think you stand while you use the information process in your team?