Sunday, October 04, 2009

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!

Thursday, July 30, 2009

A strategy to port from old system to new system

Click the Image for Full Size

Sunday, July 19, 2009

Lean Software Development MindMap

Click the Image for Full Size

Thursday, June 25, 2009

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

Monday, June 08, 2009

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

Sunday, June 07, 2009

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

Tuesday, June 02, 2009

It is the system

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


-- W. Edwards Deming

Saturday, May 30, 2009

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.

Monday, May 25, 2009

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,