Make it easier to do the right thing

Last year, I got a chance to work in India for 6 months. It was an awesome experience. I never had so much fun working. Something simple and thought provoking happened when I was there that I want to share.

I went to watch a movie with my friend. The theater was awesome. It was a multi-screen theater in a mall. We got our drinks and all set to watch a mindless hollywood movie. After the movie, my friend left his drink cup in his seat. I told him that it is not the right thing to do and we should not liter like that. He was like "oh don't worry about it". I carried my drink cup, I did not want to leave it in my seat. I was expecting there will be trash can outside the theater door. To my surprise, I did not find a trash can. I spend like 5 minutes looking for a trash can.

This is a very simple incident, but it teaches us an important thing. It is not that people want to do the wrong thing. They are just doing what is easy. In this incident , leaving the cup in the theater is an easier choice than spending 5 minutes looking for a trash can.

Lets take a software project. If it is very difficult to write automated tests, developers will eventually will stop writing tests. I can think of so many things like this. If it is taking a long time to run a build, developers will eventually start checking in code without running the build.

So in a software project, We should make sure that doing the right thing is easier than doing the wrong thing.

What is Rack?

Rack is a specification or a standardized way in Ruby to interact with a web server. It specifies how to accept a request from a web server and how to respond to a web server. Even though it sounds very simple, it opens up lot of options.

Check out these links for more information,

http://rack.rubyforge.org/

http://chneukirchen.org/talks/euruko-2007/chneukirchen-euruko2007-introducing-rack.pdf

http://vision-media.ca/resources/ruby/ruby-rack-middleware-tutorial

http://github.com/rack/rack-contrib/tree/master

Like movies, your presentations need Editors

Cleaning up your presentation is not that different from editing a feature film. As a director wants her films crisp and clear, you want your presentations to be crisp and clear. In movie industry, they say that director and editor roles should be done by different people. The reason is, for director when she looks at a scene she thinks the hardship that is gone in shooting that scene more than whether that scene is moving the story or not. No wonder Director's Cut is so boring. When an editor looks at the same scene she does not care how much effort has gone to shoot that scene. Editor cares only whether that scene is moving the story along or not. So next time when you are done with your presentation share it with an another person and ask her to edit it. Don't mind if she deletes a slide that took you 30 minutes to put it. Believe me your presentation will be more crisp and clear at the end.

Skills needed for a trainer to be good

There is a wrong assumption that good trainers are the ones who have expertise in the area they are training. I think having expertise in area you are training is important , but it is not the only skill that will make you a good trainer. A good trainer should also have these following skills,

- Facilitation skills :

The trainer should help learning to take place by creating a safe environment for trainees that encourages the learning process.

- Presentation skills :

The trainer should be organizing and presenting information and activities that will reinforce the learning process.

- Motivation skills:

The trainer should encourage and motivate trainees to learn and participate in training.

- Evaluation skills:

The trainer should be able to check to see if learning has taken place.

Yes expertise in area a trainer is training is important, but that will not alone will make he/she a good trainer. A trainer to be good will also need the skills I have mentioned above.

Random Thoughts about Retrospectives

• Retrospectives are there to surface problems not to analyze root cause of a problem.
• Retrospectives should end with action items.
• Each Action Item should have an Owner.

Should Project Managers be technical ?!

I have seen some good project managers who were technical or non technical. I have see some bad project managers who were technical or non technical. I am not sure whether being technical or non technical even matter for being a good project manager. Many of my friends and colleagues have some strong opinion on this subject. I wanted to know how everyone else feels about project managers being technical or non technical. Please share your thoughts as comments.

Simple Procedure for effective meeting

Are you spending lot of time in meetings without much result. Try this simple procedure

1) Invite only needed people
2) Display purpose and Agenda of the meeting
3) Time box your discussions (I will post another blog examining different discussion techniques)
4) Come up with Action Items
5) State the owner and due for each Action item.
6) Send meeting minutes to all attendees

Fresher and Experienced Developers - Friends or Enemies ?

There are many articles written about pair programming. I wanted to write something specific about pair programming between a fresher and experienced programer.

Lets look at some benefits of pairing a fresher with a experienced developer.

Benefits:

1. The fresher gets a good a mentor whom he can ask questions and clarify doubts.
2. Learn from experienced developer. Learn concepts in minutes which might take years if left alone.
   

There are so many other benefits in pair programming. My interest is finding problems that could occur when pairing a fresher with a experienced developer.

Problems:

1. Fresher can slow down experienced developer, so productivity may go down.
2. Experienced dev might get frustrated explaining everything to fresher.
3. Fresher might be intimated so would not question experience developer's decisions.
4. Fresher might feel discouraged as they don't know many things compare to experienced developers.
5. Fresher might not get sense of accomplishments as they feel they finished a task because they paired with some experienced developers.
   

Now we have a good set of problems. Lets see what we can do it avoid these problems.

Solutions:

1. Give freshers some tasks that they can do by themselves so they will get a sense of accomplishments.
2. Experienced developers can clearly tell freshers where they need to concentrate, like ask them to read a particular technology or practice.
   
3. Create a safe environment where freshers won't hold themselves from questioning experienced developers' decisions.
   
4. Create a culture where people seek feedback. 
   
5. Always make sure freshers what is expected out of them that way they can be ready.
   
6. Have One on ones regularly with freshers and experienced developers to get sense how things are going.
   
7. Talk with experienced developers to find how freshers are doing. Ask them what they suggest we can do to improve a productivity.

This is not a comprehensive list. Please share your experience. I would like to hear from both experienced developers and freshers.

Idea to Implementation

I created a presentation for some of my friends who were planning to start their own business. This presentation is based on "Getting Real" book.

Check it out and let me know if you have any questions/suggestions.

Determine root cause of a problem

Determining root cause of a problem and solve the root cause rather than symptoms is one of important principles of Lean methodology. I have been in situations where we do not have time to determine root cause, so we waste our time just solving symptoms of a problem. I am sure many of you have been in this kind of situation. Unless we solve root cause of a problem, the problem will keep coming back. So it is important for us to determine root cause of a problem and solve it instead of solving symptoms. How do we determine root cause? Lucky for there is a simple technique to determine root cause of a problem.

This technique is called "5 Whys". The technique is to repeatedly ask "why" till we find root cause of a problem.

It is easy to explain with an example.

Problem: QAs take lot of time to test application.

1. Why are QAs taking lot of time to test application?
- Because they find so many bugs in application. They have to wait for developers to fix those bugs, so they can retest.

2. Why are QAs finding so many bugs in application?
- Because the application has lot of bugs.

3. Why is application having many bugs after development is done?
- Because developers did not find these bugs when developing application.

4. Why developers did not find all these bugs during development?
- Because they do not have enough unit tests.

5. Why developers did not write enough unit tests?
- Because developers did not do Test Driven Development.

You can see that QAs taking lot of time to test is not the real problem, it is just a symptom. After applying 5 whys technique we found the root cause of that problem is developers are not doing test driven development. In fact we can repeat why questions some more time to make sure it is root cause.

6. Why developers did not do Test Driven Development?
-Because they don't know how to do Test Driven Development.

Now we have determined the root cause of our problem. It is not QAs taking lot of time to test. It is developers do not know how to do test driven development.So instead of adding more QAs to reduce testing time, we should train developers how to do test driven development.