Purposes of A3

Purposes of A3 could be broadly fit under either of the following three purposes:

1. Reporting how you solved a problem
2. Outlining a proposal or strategy
3. Conveying status on a previously agreed proposal

Announcing the Bay Area Chef User Meetup

Hi folks, I’d like to announce the Bay Area Chef User Meetup. The first meeting is scheduled for the mid of the this month – on the 14th of Oct.

This is just the first meetup, so it will be general – exchanging ideas about what different folks in the valley are cooking using Chef

Join the group – and attend, it should be fun!

A strategy to port from old system to new system

Click the Image for Full Size

Lean Software Development MindMap

Click the Image for Full Size

Be Nice

Well put

I don't care how good you are at programming, finding bugs, whatever. If you're rude, or if you speak poorly to people who don't understand your... quirks.... you will wind up being shunted to the side. No one wants to work with someone who makes them feel beat down all the time, or someone who they simply can't understand, or someone whose reaction to every issue is to start wailing about the end of the world

Check out Catherine Powell full blog at http://blog.abakas.com/2009/06/be-nice.html

Automation is Overrated!

Imagine that in our project we have a manual build process that is complex. Sadly, this is not that difficult to imagine. Obviously the manual build process is reducing our ability to release our software often. Close your eye for a minute and think how will you will solve this problem.

When I asked this question to some of my friends, most of them told me they will automate the build process. I bet even you came up with automating build process as a solution. Automating the build process looks like a logical solution. If you give some more thought, you will realize that we are just automating the complexity that is there in the build process. We are not simplifying the build process. Even though we automated our build process it is still complex and it is going to be difficult to change.

So next time before automating a complex process, first simplify that process. If you simplify a complex process, as a added bonus it will be easy to automate.

Check out my other blogs on Lean at http://bizdriven.blogspot.com/search/label/Lean

What makes a group of people a team?

A group of people are a team when they,

• Have Common Goal
• Have Mutual Commitment
• Synchronize their effects and
• Trust and Respect Each Other

Otherwise they are just a group of people not a team.

Check out my other blogs on Team at http://bizdriven.blogspot.com/search/label/Team

It is the system

"It is the system, not the workers, that creates defects and lowers productivity"

-- W. Edwards Deming

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.

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.