Wednesday, 14 December 2011

The No Whining Zone


How much of negativity do you see around when you sit on your desk? How much of those vibes hurt your development? How much it affects your moral and productivity? How much you start whining yourself? I am sure, answer to a lot of these questions are not known to you. A lot of us basically dont even notice or consider the whining around to be actual whining. For several reasons whining in office spaces have become the basic necessity and believe me you would certainly see moral and attitude troubles in places that are whiner-land.

So what and how does this whining affect us? I recently happened to visit a Travel agent, a small office clubbed with around 8-9 people who would help the clients book hotels, flights etc. I wanted to get my vacation planned with them and since the tour planner was running late I got a chance to sit in the crowded place. A few moments I noticed that that the girls around were talking, I could not avoid over-hearing but they were cribbing about phones, about customers behaviours, about bosses, about people.. during the same time they chose to have their working lunches and I noticed the whining increased in mercury levels.... there were arguments, complains and raised voices... huh.... Before I left the office I asked my planner on what was the issue with the girls working there, he said they have several and sometimes they just crib about everything..

I realised if your office space is a whining area.. where people choose to do nothing but complains.... you are soon de-moralizing your teams, building wrong attitudes in people and of course affecting your over all growth and productivity. Whiners spread there magic like fire and when they spread the negativity they dont care where they do it, how they do it and who it affects.

In today's era we all are burdened with a lot of work, deliveries, quality, customers and deals. Hence we all need that sympathy soul who can hear us out... most times whining is done to get away from responsibility or blame others for things not happening. A engineer can whine if he is consistently working hard on deliverables, if he see's not so good quality work coming to him, if he sees issues in the work place, if he notices any troublesome factor.. sometime he will wine if he see himself working more than others, if he thinks he is paid less, if he thinks other companies pay better and the list continues.... all these situations and talks happen in work desks, passages, smoke area and pantry rooms.

The Book Whining : 3 steps to stopping it before tears and tantrums gives a superb view of different types of whining that happens in a house, family. But it is not bad to link it to a workplace where the effects are much broader and affects bigger audience.

So how do we create the no-whining zone in workplace?

1. Make people accountable.. if they know how to take responsibility there will be lesser reasons to whine.
2. Make people responsible, if they know their responsibilities well there will be less reasons to whine
3. Suggest people they talk positive.. Unless they speak good things about even the worst possible elements there wont be those negative whining vibes.
4. Suggest people to have smiling than frown faces.
5. Put boards across office asking NO WHINING PLEASE
6. Create whining zones which are distanced than the work place and people can be noticed... it is important to let the whining not affect regulars or the motivated.

Last but not the least... whining is a problem.. try to fix the issue that matters... changing whiners is a difficult task.

Make your workplace a fun area not a whiners paradise

Thursday, 14 July 2011

We love Unhappiness? Do we? Really?

One thing I have learnt in my 32 year life is that humans are most insecure, dissatisfied and whining fellows. We just don't know how to be Happy or rather we just don't want to be Happy. I mean a few days ago I was playing the Age of empire, a strategic game. You build farms, food, infrastructure, you build your empire, make friends, allies and what not. Eventually after I spent around 8 days building a good set of empire, I started feeling uneasy, I decided to build an army, I wanted to grow my power, money and designation in the game. I was unhappy about them and I wanted to do more... In turn I made a few allies, attacked others. Huh? Tension grows.. wars, battlefields, blood... Darn it, even in a game? One can just not stay happy.

No??? tell me one game you have played that where you are happy and you keep playing? Lets take caveman.. once he is reaching his destination after playing all those difficult levels.. the Game ends... For that matter even the movies... it starts all good, romantic then some blunders and unhappiness, sadness and then the moment you get to be Happy the movie ends. Huh?

I think we humans are trained to become unhappy :). OK OK.. I am not teaching you about happiness here. Last when I wrote about Happiness quotient I emphasized on this part. In fact when I asked the question If I am happy years ago, I learnt I tried to be one. Well we spent most of our times at work, and hence work plays an important role in our happiness.

A few years ago the place I worked got me the experience of happy and unhappy people. I still remember the lessons and I have to say I am happy I learnt them. A few days ago I overheard someone whining to others about morning, traffic, day, office, parking, work, salary, job, role and I don't know what not, it made me feel he/she was not Happy. Since I wrote in my previous post about it, I asked the person what is it that is keeping him blocked? Why is he/she not able to enjoy work, be a part of the momentum or create one? I guess the answer I would say as for all whining lords was missing.

Unhappiness is an attitude, that gets more and more deeper into you. The more time you stay unhappy, the more your attitude turns ugly. It reaches a level where you have no turning back. I think over period I have realised that several companies spend their energies not in making their workforce happy... they spend there effort on working to not have them unhappy. The later is disastrous. I have experienced it, the more you try the more it grows, because the one's that are unhappy will always be unhappy. But don't get disappointed some psychology experts have figured out that Love can help improvise the situation.

Love...

Ask yourself, your teams, people who surround you to answer the following questions and actions:

1. Do you love the people you work with? If not what will make you love them?
2. Do you think the people you work with love you? If not what is it you think can make them love you?
3. Do you love what you do? If not what do you love to do? and can you tell the people you love on what you want to do?
4. Do you enjoy what you do?
5. Do you tell what you are unhappy about others?
6. Do you tell yourself what you are unhappy about?
7. Do you like to admit your mistakes? Do you like to improvise?
8. Do you think love can make a difference?
9. Do you love to be happy? If not unhappy? insecure?
10. Do you enjoy love and being loved?

Ask these and a few more, confront, talk, speak, learn and yes Love. Happiness at the place you spend most of your time is as important as oxygen. If you cant be happy and you have not made any efforts to be happy, you maybe on the path to be a whiner or a looser. Lets change path. Lets find ways to be Happy with people you are surrounded with.

Wednesday, 13 July 2011

Are bugs hurting your backlog?

I ended up in a discussion with the team last week on how bugs cause a unmanageable link to the Technical debt. The debate was how should bugs be treated. my argument laid with bugs that hurt the current development and the future backlog. As a agile team a product backlog is key driver in defining what we do for in every release, the known unknown here is the bugs that are generated out of the current development. Let's say your product backlog is 200. If your team of 10 is burning say 100 user stories in a release of 10 days we can say that the velocity is around 10. But if in the same situation your team is burning 100 user stories in 10 days and creating 20 bugs that take 5 days to fix, your velocity is dropped to less than 7 + on the release day your backlog increased from 100 to 110 say a 20% increase.

Gauge the effect bugs can have in your system. Now go a bit deeper, assume you can only only resolve 10 of the 20 bugs in 5 days. The other 10 bugs go sit in your product backlog. When you cant get them in the current release and put them up for the next they take 20 days to resolve (Due to the time spent in between it no longer is hands on) your velocity rate with the bugs regards is then 100 user stories in 25 days (Just around 4?) Now if these 10 bugs are mapped for a future unknown release???? The technical debt it had created can be high, very high and would lead to say 10 more bugs getting created [causing you 8 days or maybe 10] your velocity with regards has now gone to ?????? less than 3 and forget about the qa and discussion cycles, customer unhappiness, quality quotient. Your product backlog spanned to 120 which is 20% more than what you expected to burn.

So next time when your release user story is generating a bug, go shout on your developer and tell him/her that the bug is a part of requirement and when you go live you want the feature to be done, not debted.

Obviously for those "Think Realistic" atheists this wont sound good. But remember your product backlog is piling up with the bugs, your velocity decreasing, your debt increasing and your cycles of qa increasing... in other words nothing in favour of better product.

What do you do to bugs that get created from your development bug and found during the release?

Wednesday, 6 July 2011

The Art of un-informing


Yesterday my day started on a bad note, heard news of passing off of my father's aunt (grand mother) and had several production issues that were waiting for me. During the funeral I realised that I had missed to inform at work, and by the time I did it was probably too late. Bunch of calls and last minute meeting cancellations. I can imagine the frustration it caused others.

I couldn't stop thinking of it and hence about writing on it as I know it hurts not just you but everyone else. Over the last few years of my managerial experience I have learnt people fall into 3 broad categories :
1. Who intend to not inform
2. Who misinform
3. Who inform.

You would always love the 3rd type, You worry about the second and you hate the first. Today I write what hurts us Managers the most...The first lotte

"I couldn't come to work yesterday, Were trying for a baby and the doc said yesterday was the best chance."

Well I am sure this doesn't sound that unfamiliar? You may have not heard something like this but the types that intend to not inform are the types that make such excuses. The "I don't want to inform" types intentionally leave the information out for various reasons as follows:

1. Fear : Fear of leave getting rejected. Someone who makes an excuse is still better in this regards as he/she doesn't leave you in jeopardy. Fear of facing a rejection of request, makes such people do this. Some times it is also the fear of what the Boss would say (About lot of leave, Performance etc).

2. Ignorance : Sometimes this is just done out of ignorance. I remembered a friend of mine who worked on a collection counter for a government office collecting last minute penalties on property taxes, never realised that people have to face a extra buck if she is not on her seat.

3. Get Away attitude : A lot of them think that if no one remembers they can easily get away. This is the most hurtful of it.

The big issue with this type of people is that it brings you into a big crisis at times, and they never realise the importance of informing because they get away one way or the other out of the crisis issue. How do we fix them?

Well honestly there are several ways... lets put this in a funnier way


1. Make them feel what they just lost: I remember once I had a team mate who was really fond of some specific type of food. After noticing that he deliberately not informs the team about his absence we a couple of times had indoor lunch / dinner on the day he would go missing.

2. Add the surprise : Once a friend of mine who is a manager bought printed old passes of the person who would go uninformed with passes to a rock concert followed by an invitation for dinner with the popstar. Of course it was a fake one, but it kept the person pinching for his life time.

3. On a serious note : First time itself it should be informed. If they get away once they would make it a habit.

4. Punish sweetly : A little embarrassment can do.

I am sure you might have faced this and handled it.. what are your ways? Do share....

Friday, 24 June 2011

Things to Know - Who owns the Technical Debt


A fresh release for us is due next week, have to say it has been put up with a serious effort of around 8 months with a lot of hard work and agility and comes with a lot of development contribution that is beyond coding and testing. Now that we are almost there, I have been reviewing the bugs created by our test team, ran an eye on the code to check through the code quality, ran on de-scoped features, made a list of items we could not do for several reasons. Going through this one thing kept on reminding a discussion Me and Savio had way back in 2007 when reviewing code for another product topic was "Technical Debt". For those of who are new to this term technical debt is the leftover or unfinished things in your development work [precisely a product/feature] that links to documentation, design implementations, re-factoring, coding. In other words if you choose to finish your product faster and in a messy way you leave a big technical debt behind. The day your development team starts saying that X things which probably is a small feature will take more time, snap out that you have some technical debt on you.

Technical debt is similar to financial debt, the only issue is it is not measurable in figures. You can find how much you owe to someone when it comes to money/interest, but with regards to a Technical debt its the price the entire Team pays by putting additional effort to do some basic things. Technical debt is caused by Deliberate Motives or Ignorance, though the quadrants may differ you can broadly say that technical debt cleaned earlier the better...

Typically deliberate technical debts are caused by

1. Lets do it now and we will see whats the impact later
2. We need to release this by X date
3. Put a todo list and we will revisit it later
4. Not now
5. Its too much work

Out of Ignorance causing technical debt can be serious..but usually you would see it happening due to skills and comes from freshers unless you don't have good technical resources. Many a times technical debt created out of ignorance comes due to the fact of ignorance in writing code, unawareness in knowing the best definitions of technology and language or available design patterns that can be applied. A lot of times ignorance is caused due to skill and understanding too.

Whatsoever said.. You can know your technical and the severity of it by :

1. Counting the number of bugs raised once the development build reaches the QA.
2. By the amount of effort your team spends on adding features to the developed items.

Eventually most in disciplined teams do not care about the technical debt, they live for today. Letting the code die a cancerous death tomorrow. This is another reason you would never find a owner for repaying the technical debt or someone who works on it in such teams. Of my discussions with Savio and have seen him work I have a few traits identified I think I must mention them here;

1. Everyone in your team owns the technical debt; everyone hence should share it and repay it whenever they can.
2. Code review ad-hoc times apart from the stipulated and process schedules.
3. Add TO-DO lists and log them into some place [Wiki / JIRA] so that they can be put in a roadmap sometime.
4. An Architect defines the technical roadmap to repay the technical debt.
5. Product Module owners have to visit and identify what needs to be done. The lazy bone's should be thrown out of the process.
6. Re-visit code based on the bugs raised to ensure priority is given to severity
7. Value the quality, talk about it to others and show them how to execute it
8. Every release should have at least 1 technology effort put up. This would be one way to encourage new joiners to contribute in quality efforts.
9. Project Management should be introduced to technical debt earlier in the project.
10. Introduce group code reviews and multi code reviews randomly to find and fix the needed.
11. Prioritise your debt; keep it listed and updated. Know it to fix it.

Certainly if you have more than 1 code owners in your team, who value the size, quality and robustness of your code base, day is not away when you will have a highly qualified code base that can do best to your team. Question to ask yourself:

1. Do you want to invest in creating these owners?
2. Do you believe that technical debt is killing your product?

Thursday, 23 June 2011

Development : What does Quality mean? - 2

Continuing our efforts on working and understanding quality let's now focus on the other side of quality for developers and development teams. What we should do before, after and during the development cycle's is the bright known side of the coin, but to be honest you may be well equipped to write the best products, but quality is not just ensured by writing very good code, planning better, reviewing.. there is another aspect of development that one should consider, specially for development teams. As a developer in my career I felt the need of some of these several aspects which were just not about programming but affected quality in several senses and ways...

Here are those other things that should be avoided / done to ensure development sticks and values quality..

Enjoy Coding, Love Programming,Live Development
It's not the same for those who think it is there are big differences. Coding is about putting syntax together to make something do what is needed. Programming is more complex, it is putting a design in place to get things work in the way they should be.. Development is about bringing a lot of pieces like coding, architecting, designing, programming, analysis, testing together. If you think just writing code is making you a quality developer, you are wrong. Get your gear up for the later..

Find your blockers first
Many of developers don't know what blocks them from doing quality work. Over years I have come across so many factor's that affected quality of developers work from silly to serious. Years ago I knew a developer who consistently wrote code which had several review comments, upon asking we realised that there was a clock placed right above his desk that would tick every second, give an alarming sound every 30 minutes, this would distract him so much that he started to put his focus on it.. funny? Meetings, Noise in the workspace, sitting arrangements, external sources like people walking in and out, people calling loud, ring tones etc make it difficult to concentrate.. obviously long term they start affecting what you do.

Find your Rhythm source
Some find music to bring them to rhythm others just a quite place. Each developer needs to find his own comfort space, and this comfort can yield focused effort, in turn support quality in work.
Stay Put
Focus is important. If you cannot stay put at your work place, you are more likely to be distracted by yourself than others. Obviously you are going to spend time doing things than finishing work that would result in slogging in the last minute to get things done. Obviously quality is the victim.

Garbage Collection is not just for Objects, for developers too
Many of you from technical world might know this term for those who don't.. it is a systematic recovery of stored resources used by your computer program that it no longer needs. Developers if understand that they put in a lot of thought in several things and they should have ways to recall some of that energy , thoughts spent in right time to un-exhaust them. This is just not about taking a break from your desk.

Google is not the only source
95% of times when asked to the interviewed candidate on what is the source of his/her information I got the same answer "Google". If I was a Googler I would be pleased. But as a Technology person no more. If a search engine is your source of information you are starting from step 1 and drilling down to where you want to go. In general terms Google is a right thing.. but is Google the only source?

I remember of StackOverflow, Experts-exchange been the general forums I referred to, Java ranch and Sun Java forums for Java, Quora for general startup things, Mashable / Techcrucnh for tech news etc..But are these not important sources? I have a list of 80 Delicious items that I know I visit every evening. depending on the last update index. You need to find the right sources and should turn to Google when you need it hard.

Make Forums your homepage
Forums... everyone wants to ask a question and get an answer.. but tell me, How many of you really give that answer? the quality of a developer improves with his contributions to the forums. Just reading and learning without contributing is shit. You may not be a good writer.. but if you share you learn, you evolve, you would unlearn and you would re-learn. Have forums your home page. See what industry or technology is facing as a challenge.


New Technology is a mirage
I have heard form many that knowing new Technology will boost there careers and help them write more performing, more scaling, more robust application. I am sure if you think that way you have not tried enough. Moving to a new technology is good. But the first attempt should be making the current one be good. Most guys who I found fascinated to change architectures with New Technology without sane answers are the same guys that would give excuse of technology limitations to do something.

Unlearn , Relearn always
Do you? If not start doing this.. A long ago I learn using java.util.Vectors was the best way to manage key/pair values. Unlearn things occasionally to re learn them in a better way. Now I know it is not. There are better options available and can be used effectively. This just doesn't apply to technology, just generalise this.

Yet again, I am sure there are many more things that will help you improve quality of the development process and what you develop. Point is.. The most important thing.. do you have a WILL to be a quality person, a quality developer, a quality craftsmen?