Tuesday, January 27, 2009

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.




Friday, January 23, 2009

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.

Sunday, January 18, 2009

Tips for on-boarding new hires in your company

On-boarding new hire to your company is a very important task. Every company needs to have a proper on-boarding strategy. I thought I will share some of good tips that I heard from different people for on-boarding new member to your company.

1) Buddy program: When someone joins your company assign them a buddy. The new person will know that they have someone whom they can ask questions and clarify their doubts.

2) Introduce recent hires to new hires. Recent hires will know what it was to be a new person in a company. They can help new hires in coping up with stress and also guide them.

3) Ask new hires to finish small measurable tasks. This will help you understand new hire's working style. As task could be measured you can give them feedback and guidance to them to finish that task. When they finish a task, their morale will also increase. They will feel a sense of accomplishing something.

4) Socials events. This will ease them and allow them to make friends in company.

5) Have a Mentor program . More than a buddy you also need to assign a mentor. Mentor will help them understand their goals and what they are looking for in this company. Mentor can also help them with their career and goal settings.

6) Weekly feedback sessions - Let them know how they are doing and what they can do differently. Look at my previous post  to see how to give and receive feedback. Feedbacks are very useful as they will give new hires where they going and how they are doing exactly. They will also know what is expected out of them in their company.


These tips could be used for on-boarding new member to your team.

Please share your tips on on-boarding new hires.


Friday, January 16, 2009

Feedback

It is important for a PM to encourage his team members to give and receive feedback. Feedback are important for team to be cohesive and successful. 

When it comes to feedback, people always use sandwich technique. How many times have you heard people tell you something in lines of,
"you are great. you are doing an amazing job. you are mean. it was great working with you". They sandwich a bad thing between two good things about you. This is not feedback. There is nothing positive is going to come out from these kind of conversations. In fact , the types of conversations will have negative effect.

Feedback should be given for two reasons,

1) Improving Effectiveness and
2) Strengthening confidence.

There is nothing like good or bad feedback, only feedback.

When giving feedback,

1) Be specific.
2) Focus on behavior rather than the person
3) Be descriptor rather than judgmental
4) Ask permission
5) Give feedback in private

When receiving feedback

1) Ask for instances if the person tells you something generic
2) Ask for suggestions
3) Treat feedback as a gift :)

Encourage your team members to give and receive feedback.

It will be nice if you all can share your experiences in giving and receiving feedback.

Wednesday, January 07, 2009

Team Development

Tuckman stages of team development is very simple and could be used for building and developing teams. It could also be used for analyzing the current behavior of teams. Knowing these stages will help PMs in creating awesome team.


The stages of Team Development:
  1. Forming : This is team initiation stage. PMs should bring their team members together. Make sure everyone understands the goal of their team. Should create a safety environment for team members to try new things without worrying about failing. It will be helpful if PMs share Tuckman stages to their team. PMs are Directors in this stage. 
  2. Storming : In this stage various personalities in team compete. PMs should not panic and change team members when their teams are in this stage. Instead PMs should coach(regular one on ones) to increase tolerance of each team member and emphasize their differences. PMs are Coaches in this stage.
  3. Norming : In this stage teams solve problems on their own and achieve harmony. PMs are Participant in this stage.
  4. Performing : In this stage team is performing as a unit. Teams will be more productive. PMs should allow their teams to make their own decisions. PMs are Delegators in this stage.
  5. Adjourning : Goal is achieved and team is disassembled.