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.

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.

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.

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. 

Avoid asking hypothetical questions in interviews

I have taken part in many interviews as interviewer and interviewee. I have seen many interviewers ( including me ) ask many  hypothetical questions especially for management positions. 

Hypothetical question example :

When one of your team member does not show up on time for work, how will you handle the situation ? 

The interviewee usually comes with a textbook answer. Something like , 

I will talk to him/her about him/her not showing up on time. 

This is a very good answer. But this answer does not mean that the interviewee has any experience handling these kinds of situations. It just means that the interviewee had read some books about management. So instead of asking hypothetical questions, we should be asking "behavior description questions" . 

For example instead of asking 

"When one of your team member does not show up on time, how will you handle the situation?" , 

we should be asking 

"Tell me about a time when one of your team member was not showing up on time, how did you handle that situation?" .

This way of questions will help interviewee to explain how they worked in their past instead of coming up with some hypothetical answer.

Letter to managers

Dear Manager:

Before you judge who I am and what I need to change. Give me an opportunity and see how I do.

Thanks,

Subordinate

Do we need a Tech Lead role ?

I have been thinking about whether we need a tech lead role for sometime. But now, I have come to a conclusion that tech lead role is unnecessary. Let me list my reasons, why I feel that way.

1. Instead of a tech lead , we need a person to act as tech facilitator. This role should be rotated among the team members in weekly basis or biweekly basis. The main responsibility for Tech facilitator will be to resolve some technical conflicts within team by facilitating a discussion where advantages and disadvantages of all approaches are discussed and decision is made.
2. I strongly believe the person with a strong technical expertise will be recognized by the team itself. We do not need to appoint a tech lead. Team members will go to a person who they trust as expertise in that technology. So there is no need for a technical lead role.

So instead of we pushing a person as a Tech lead to a team, I think we should let the team organize itself.

Waterfall is perfect (with some assumptions)

I took "Software development life cycle" course in my school long time ago. It was an interesting course as it was the only course that explained software development process from one level up compare to other programming courses. As a part of the course, I learnt about Waterfall process and different phases in waterfall process. At that time, I felt that Waterfall process is so simple and perfect. 

1. We gather ALL requirements
2. We design the ENTIRE system to attributes and behaviors level in classes
3. We code those designs
4. Test the system
5. Ship or release it.

I felt waterfall is the way to go. It is amazing yet simple. It has less steps than making chicken soup.  Waterfall process can never fail, but there is a catch. Waterfall process has many assumptions and some of them are,

• Requirements never change
• Design is perfect
• Coders can easily implement those designs
• Defect fix will not have much impact in the design as it is perfect.

These assumptions can never be true. In waterfall process, we never consider these assumptions can be wrong. We do not consider them as risks. I think this is the biggest flaw in waterfall process.

Now lets look at some assumptions made for agile process.

• Requirements will change
• Design will evolve and change as we gather more knowledge

As you can see assumptions made in Waterfall process and Agile is totally different. It is these assumptions that make such a difference between agile and waterfall. It is not the phases. In both agile and waterfall we will have requirement , design , coding and testing phase. 

In agile because of its assumptions, these phases are done quite differently from waterfall process. 

Requirement Analysis:

In agile we embrace change and expect requirements to change unlike Waterfall process. So expecting change in requirements, we do not do too much analysis. We do analysis only when it is needed. The advantage is as you wait till the last moment, you can use new knowledge that you have gathered about the system. 

Design and Coding:

In agile, design and coding phase happens in quick sessions that it looks like a single phase. As developers expect the requirements and designs to change they make sure they have good test coverage as a safety net. As they have good test coverage, they are not afraid to change their design or code. They do not spend too much time designing for future (which will be different anyway). They get things done with the information they have at that time.

Testing:

Defects found at this stage would not have much impact in the system as all other phases are expecting things to change. So there is no surprise. 

Workflow:

As analysis is done only when needed, there is less features for developers to design and code. As  only few features are implemented, there is less features for testers to test. So all these phases are done in a very fast rate. Mostly within a week or two. They keep doing them again and again till the customer is satisfied.

As you can see, some simple assumptions can change the whole software development process. So more than anything else, your assumptions will determine whether you project will be waterfally or agilely.

Please teach me rspec

I was first introduced to BDD like 4 years back by Dave Astel's article. I really liked the idea. It totally made sense to me. I was like damn this is the way we have to think for designing objects. That time I was working in a java project. Igor and I were like okay lets do BDD and started naming our Junit test methods like testDogShouldBarkWhenThrownStoneAt . When jBehave released I wanted to use it, but I never got a chance.

When I started working on yewoh, I was so excited that now I can chose whatever framework I want. Being a BDD addict, I obviously chose rspec. It is a great framework for doing BDD.It gives you nice syntax to express behaviors in "when" and "should" format .It felt very natural for me to write verifications for verifying my object behavior instead of tests.

Now after using rspec for sometime, I have some questions about rspec.

• What is the best way to organize specs? In rails project, specs are arranged in folders like models, controllers etc. I do not have a problem arranging the spec files, but I am not sure how to organize specs itself. Does anyone has some good practices that worked for them?

• Sometimes my objects have behaviors like "Player When power is on It should start playing When play button is pressed " . In this behavior I have two When conditions. How do you express this behavior in rspec ? Should I have it like

describe Player, "When play button is pressed"
    it "should start playing if power is on"
      ....
   end
end

using a if condition. Or should I have something like this

 describe Player, "When power is on and play button is pressed"
   it "should start playing"
     ...
   end
end

• In unit test, usually we write tests to make sure our method do not blow up when we pass nil for example. I feel it is a good test to have. How do we writes spec for this kind of situations?  

Rspec documentation has good explanations and examples for rspec syntax. But I am looking for best practices for using rspec.

It will be great if you all share your experience with rspec.

Do we need Iteration Planning meeting?

Iteration Planning Meeting (IPM) is becoming a controversial topic. In one side , some people feel IPM is a must. In other side, some people feel IPM is not needed. I have friends and people whom I appreciate in both sides. According to me, I feel IPM is needed (not a must) but in a different form.

These are the activities that usually happens during a typical IPM.

• Showcasing (Demo to customers)
• Retrospect
• Story presentation
• Story tasking and estimating
• Planning
• A little celebration for finishing an iteration.

In those activities I have mentioned above, I am not convinced that some activities should be part of IPM. Let me explain one by one.

Retrospect:

Retrospect is where we collect knowledge to eliminate waste. We can retrospect what things worked and what did not work. The problem I have is why cannot retrospect be an ongoing activity instead of just happening during IPM ? We can have a board where everyone in the team can add things whenever they want that they like or do not like. The board will be always up to day. In daily standups everyone can discuss on issues that are very critical.

Story presentation:

Story presentation is where a analyst will present what a story is all about. Developers can ask questions to understand about what is expected out of that story. This is a very useful activity, but again why it has to happen during IPM. Story presentation should be postponed till some developer is ready to work on it. That way we can use new knowledge that we acquired in the past few days working with other stories.

Story tasking and estimating:

Please look at my other blog, where I have discussed the importance of tasking. Again like 'story presentation' this activity should be done at last possible moment (ie.., when developers are starting to work on that card) instead of being done during IPM.

Planning:

Planning is something that we can never avoid. Planning has to happen. But we should understand that planning is not a commitment. We should be willing to change our plans as we gather new knowledge. Planning for short term should be more towards what is next three stories (keep this number as low as possible) that I wanted my team to work on. Things change so fast and we gather so much more knowledge in a short time. So planning should be a continuous activity rather than being done only during IPM.

Now our new form of IPM will have only these activities,

• Showcasing (Demo to customers)
• A little celebration for finishing an iteration.

Ideal situation:

In a ideal situation, customers will be always sitting in your team room. Whenever we have a story done, we can deploy to a demo machine (which is very close to production system ) and demo it to the customer. In this scenario, celebration is the only activity we will doing during IPM.

Reality:

In reality, not all customers will be sitting in team room. So we need a scheduled time to demo the stories you have done to get feedback from them. So we will need IPM , but in new form.