Its all about Biz, man

Purposes of A3

2009-10-04T13:00:00.001-05:00

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

Reporting how you solved a problem
Outlining a proposal or strategy
Conveying status on a previously agreed proposal

Announcing the Bay Area Chef User Meetup

2009-10-04T12:53:00.001-05:00

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

2009-07-30T22:45:00.002-05:00

Click the Image for Full Size

Lean Software Development MindMap

2009-07-19T15:18:00.002-05:00

Click the Image for Full Size

Be Nice

2009-06-25T00:02:00.001-05:00

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!

2009-06-08T00:39:00.002-05:00

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?

2009-06-07T11:05:00.005-05:00

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

2009-06-02T23:21:00.001-05:00

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

-- W. Edwards Deming

Make it easier to do the right thing

2009-05-30T12:47:00.002-05:00

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?

2009-05-25T17:10:00.002-05:00

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

2009-05-24T11:55:00.000-05:00

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

2009-05-17T20:38:00.002-05:00

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

2009-05-16T10:02:00.002-05:00

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 ?!

2009-02-18T22:50:00.002-06:00

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

2009-02-13T22:38:00.002-06:00

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 ?

2009-02-09T11:08:00.002-06:00

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:

The fresher gets a good a mentor whom he can ask questions and clarify doubts.
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:

Fresher can slow down experienced developer, so productivity may go down.
Experienced dev might get frustrated explaining everything to fresher.
Fresher might be intimated so would not question experience developer's decisions.
Fresher might feel discouraged as they don't know many things compare to experienced developers.
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:

Give freshers some tasks that they can do by themselves so they will get a sense of accomplishments.
Experienced developers can clearly tell freshers where they need to concentrate, like ask them to read a particular technology or practice.
Create a safe environment where freshers won't hold themselves from questioning experienced developers' decisions.
Create a culture where people seek feedback.
Always make sure freshers what is expected out of them that way they can be ready.
Have One on ones regularly with freshers and experienced developers to get sense how things are going.
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

2009-01-27T15:51:00.002-06:00

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

2009-01-23T09:58:00.006-06:00

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

2009-01-18T01:07:00.000-06:00

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

2009-01-16T13:57:00.004-06:00

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

2009-01-07T09:58:00.005-06:00

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:

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.
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.
Norming : In this stage teams solve problems on their own and achieve harmony. PMs are Participant in this stage.
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.
Adjourning : Goal is achieved and team is disassembled.

Avoid asking hypothetical questions in interviews

2008-07-14T02:18:00.004-05:00

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

2008-05-26T08:21:00.000-05:00

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 ?

2008-04-30T23:42:00.000-05:00

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.

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.
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)

2008-04-17T23:03:00.002-05:00

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.

We gather ALL requirements
We design the ENTIRE system to attributes and behaviors level in classes
We code those designs
Test the system
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.