Tuesday, December 26, 2006

Process

Tim Lister said: "Process is like swimming, you need a process when stuff you do is not natural." Your real process is what you need when there is a pressure (drowning), the rest is window dressing. If you see a human new to water paddling so hard isn’t because he is asking for a sign off, he is trying to save his life. Under pressure he wants a floater or rope to hang on – the process of having a floater or rope around makes sense then. Waiting for somebody to sign off would be deadly.

Sunday, December 17, 2006

Simple test

To see if you have created a great product - simply ask this question:

Would you offer this product to a friend?

A simple question

Is your boss gets mad at you?

If you're not doing something that someone hates, it is possible that you are not doing a good job.

Whether you're a leaf or a branch (employee or manager), pick your battles carefully, one poke at a time. Better to live another day to keep fighting the good fight then, say, being fired for trying to do it all at once. Build support for the leaf nodes, and find some brave branches who manage them.

Tuesday, December 12, 2006

How to get yourself out of a rut

Things I learned from many years of being stuck in a rough situations (Chess, meetings, stuck at a piece of code, etc), I have adopted a general formula for what to do when I’m faced with a problem that’s got me stuck. You need to take a creative pause in that situation. The “attacker” could be a person like your boss or a problem on hand.

The first step is to change your focus – this could last seconds to couple of minutes, you just pause and say “hamburger….” or drink your tea. I am drinking lots of tea for this very reason. Otherwise the first thing out of your mouth may make the matter worse. Once you feel you are in control and thinking is coming from the right place of your brain then you can return to the stage you were in the first place.

Everybody gets stuck from time to time, so have a handy bottle of water (it is good for you) or learn to say “…Ok …hamburger”. If you have a technical challenge just walk away and talk about other things. Many times you can turn and change toward a better direction by just following this simple practice.

1) Create a pause before you react. 2) It keeps you from taking things too personally
3) It helps you ask more questions instead of jump to conclusions.

Formula for success

Quoted from Tom Peters:

A man approached JP Morgan, held up an envelope, and said, “Sir, in my hand I hold a guaranteed formula for success, which I will gladly sell you for $25,000.” “Sir,” JP Morgan replied, “I do not know what is in the envelope, however if you show me, and I like it, I give you my word as a gentleman that I will pay you what you ask.” The man agreed to the terms, and handed over the envelope. JP Morgan opened it, and extracted a single sheet of paper. He gave it one look, a mere glance, then handed the piece of paper back to the gent. And paid him the agreed-upon $25,000.

The Paper:

1. Every morning, write a list of the things that need to be done that day.
2. Do them.

Monday, December 04, 2006

Get into the zone - working from home.

AG is one of the most productive players in our current project who is working from home in the Bay area. I am not going to generalize this to a rule and say “To be productive you should work from home…” As much as I love team’s interactions on site, I also appreciate giving people a degree of freedom so that they can be creative at other places. This is a standard benefit that good teams provide and is a great way to send your employees the message that you care about them and spark creativity in them.

I can tell you, the food at home is much better than the corporate cafeteria standards. Writers, programmers, scientists, analysts and even sportsmen will tell you about being in the zone. To get in the zone you might need to do something different. People get into the zone by working from home.

People get energy when they daily routine is decorated with a pleasant event like eating with their colleagues, taking a break and working from home, which increases learning and communication. They get back to work fresh, being more productive. They also feel you care about them, making them more loyal.

If you are legislating for people to come to office all days, then you should be prepared to make their environment better than their homes.

Sunday, December 03, 2006

Over 50% of any piece of software is communication with its end-user.

The first law of Bad Management is:

“If something isn’t working, do more of it.” – Managers who think they can decide instead of users are following this law.

Thursday, November 30, 2006

Crawl before you walk

Change comes through having great people doing extraordinary projects. You crawl before you walk. I see people jumping into solution forgetting the fact that they can’t even crawl. I hear: “version 2.0 will fix all of these….” Before jumping around and advertising a new solution ask yourself these questions:

What are you working on right now to make you learn how to crawl first? Does it matter? Is it creating a change momentum? Do you care?

Thursday, November 23, 2006

Why Robots Are the Best Employees



This graph wonderfuly done by Kathy Sierra shows why many bosses like "Yes man" employees. Using the brain is all secondary!

Timing is everything

Paying the Technical debt is very important aspect of dealing with legacy code. However, timing of it is even more important. The team estimated 2 weeks for something that normally takes 1 day to do. The re-engineering effort is considered as part of business feature making the estimates longer. I am thinking that overhaul of system effort should be separated from implementing the business valued features. Who said business should wait 2 weeks for something that they can get now! Timing is an essential ingredient of success. If gods are telling you to do something – would you do it or …
Here is a questionnaire for leaders:
* Challenge: do you question what is and what you are told?
* Decisiveness: do you make up your mind in good time?
* Speed: do you take necessary action?
* Clarity: are you clear about what you are doing and why?
* Change: are you prepared to change anything and everything that needs changing?
* Basics: do you do well all the basic things that need to be done?
* Objectives: do you have written aims for this project, next year and five years’ time?

Tuesday, November 21, 2006

Queuing Theory

Queuing Theory

We spend a lot of time in queues. Life is a queue itself. You get stuck at traffic jams, for somebody to approve a request, lines at stores, waiting for your mother in law to call, or for rain to wash your car.

Queuing theory deals with making your wait as short as possible. One hotel used its front help desk to route people to specific elevator which takes them to their destination floor (reducing waste). “Take # 3 it takes to 10th floor faster…”

The main measurement of a queue is cycle time – that is, the average time it takes something to get from one end of a process to the other. Nine months for a baby to come into this world. Sometimes if they come 2 months earlier they can play for another soccer team.

Today we worked on queuing jobs that are behaving badly. The time spent waiting in the queue is wasted time. There are two ways to reduce cycle time (I hate to limit to two); one is to look at the way work arrives and the other is to look at the way work is processed. Doctor’s office use reservation system to assure that patients arrive at regular intervals.

One way to control the rate of work arrival is to make sure small arrival of requests, if the same work is released in small batches, the queue can be much smaller. However, the other way is to go after fixing the processor – which is faster service (it is not in our control).

Next time you are waiting at store pay attention which cashier service faster. The first criterion (managing arrival) is natural assuming you are picking the leveled and shorter line by default.

Top 10 symptom of sick projects

  • Over-preparation for the meetings. The more people prepare in advance, the more likely they will be boring.
  • PowerPoint overdose
  • Documentation overdose
  • Big bang delivery
  • Invisible clients. If you don’t see client’s visiting something is wrong
  • Framework overdose
  • Developers are awfully quite
  • Phony celebrations
  • Phony roles
  • Analysis overdose

Sunday, November 19, 2006

“Every project plan should try something new otherwise it is boring.”

NP and I started figuring out what the legacy code does. First we started writing learning tests. First we copied the legacy code and made sure it worked. Then we decided to try something new. We decided to delete the existing code until we get to the revealing part. That worked great, it felt good deleting that code and quickly we discover what was needed to make our learning test pass.

Michelangelo was telling the literal truth when he explained that his principle accomplishment was removing unnecessary stone to get to the piece of beauty. We found the same pattern works to get into the key point of a legacy code too.

Monday, November 13, 2006

“If you can’t test it, it is not working”

This week I heard/read many misused words (untested) from many people. Words like “Transition plan” or “Best practices”. “We should be done by tomorrow”. “Should” sends a false sense of security. A better translation of it is “we are having a lot of trouble”. Best Practices means: I don’t know what they are. “It is Better” is too broad to mean anything. “Transition Plan” gets translated to: I don’t know how to handle this problem. The list goes on and on. It you can't test what you say why bother ... "Wasting people's time is the biggest sin."

Sunday, November 12, 2006

Week four-six (diff and merge)

The truck number on this project is 2. If two people get hit by a truck the project suffers irreparable harm. Every piece of work is also get assigned to these two people while there are more people in the team.

Collective ownership and shared code is a good next step for this team. No single person should claim ownership over any part of the system and anyone can make any necessary changes. The team goal should be to increase the truck number. The nice side effect would be the improved code quality. The good news is that the team members are all open minded and willing to work it out. The bad news is that pressure is already too high and technical debt is increasing.

Friday Nov 9th over having a wonderful food in an Indian restaurant – one of my friends said an interesting thing: “start deleting code…” - Looking back at 4th week, while doing a short iteration, that advice would have been the best strategy. It is obvious, the more software you have to maintain, the more it costs. The team is doing a lot of diff and merge of code. Customers are demanding and then something new comes. To deliver this version quickly, the team duplicates the code base, make the changes, and ship it. Sometimes the shipped s/w is not accepted and new things get added. Now, the line of code to maintain is doubled and code needs to be changed and merges in many different places. I’ve seen this cost cripple team’s ability and it is nearly impossible to merge a split code base without heroic and immediate action of 2 people. It feels good to write this: Don’t duplicate your code base. I have also mentioned short iteration and shortening the UAT cycle for fighting this syndrome. Please post a comment if you have a suggestion.

Thursday, November 09, 2006

A true story

Week One:

2006

I changed my department. I have a desk and a Laptop borrowed from my previous job. Time to get to work. I shared with the team how automated test (Nunit) works. I heard one person resisting the change. “Ya, Ok – this works if you have formulas but our thing is different ….”

Then I showed them the continuous build (Cruise control) - One developer got it working on his machine day after. There's hope.

Week Two and Three:

It seems that DRY “Don’t repeat yourself” principle is violated big time here. Smell like copy and paste everywhere. There are many screens doing the same thing and rules are scattered all over the code.

It doesn't take long to identify the communication problems. Business people are saying something today and want it tomorrow. However, they aren’t talking much with developers. I’ve picked up a lot of information about the project and people just by talking to them. Stand Up meeting sounds like a good start.

The good news is that my boss is very supportive. The dev managers saying "our business people never show up in the meetings." Well, I hope this time is different. I start building a good relationship with the users. My boss schedules a series of stand up meetings in the morning at his office. The good news is that business people are showing up and liking it. The room is covered with index cards. However the stand ups are taking more than 10 minutes. I reminded everyone to be aware of this overrunning meeting and started raising a red flag when people go beyond 1 minute talk. It isn’t perfect but at least business and developers are talking.

Week Four:

Comming soon....

Friday, October 13, 2006

Mortgage for Women

Brand a bank which caters mortgages only to women. Sounded crazy here however, Women are more reliable and I believe their mortgage rate should be better.

On the same subject, I am very happy to see that Muhammad Yunus has won the 2006 Nobel Peace Prize. My favorite sentence which goes deep into "people first" is:
"It's not people who aren't credit-worthy. It's banks that aren't people worthy."
"Conventional banks ask their clients to come to their office…. The entire Grameen Bank system runs on the principle that people should not come to the bank, the bank should go to the people. ... "

Wednesday, September 20, 2006

Film Loop on Lean principles



These slides are created by using FilmLoop and is based on Mary Poppendieck Slides on Lean Software Development. If you install the FilmLoop player, you can turn these pictures into a screen saver.

Mehrdad Rashidfarruhi

Estimate-risk spreadsheet

I stumble upon a wonderful tool created by Robin probably a long time ago. (http://www.agilemetrics.com/tools/estimates-risk.html).

You’ll see a spreadsheet captures the Stories (Requirements) in a visual and easily risk ranked way. “One of the nice things it does is provide a framework for quickly capturing subjective customer (business) perception of the stability/completeness of their requirements. It then uses this to give a graphical representation of the Estimates/Risk of the project.”

Number of conversations inversely proportional to the likelihood of having trust.

Extraordinary how much organization talk about culture change and trust

Rule of Thumb is that number of conversations inversely proportional to the likelihood of having trust. More people and management talk about trust – more it is lacking.

Sunday, September 10, 2006

Add meaning to a search

What is a Lens?

Seth defines lens as:

"A lens is one person's view on a topic that matters to her. It's an easy-to-build, single web page that can point to blogs, favorite links, RSS feeds, Flickr photos, Google maps, eBay auctions, CafePress designs, Amazon books or music, and thousands of products from hundreds of other trusted merchants. You can pick whatever content you want to put in your lens to bring context to your topic. Then, when someone is looking for recommended information, fast, your lens gets him started and sends him off in the right direction. It's a place to start, not finish. "

I have created two Lenses:

http://www.squidoo.com/lean/

and

http://www.squidoo.com/testfirst/

Tuesday, August 08, 2006

Establish a simple rule to change behavior

I was recently thinking about how to make change possible. Started Reading “the heart of change” – the pattern discussed in the book goes like this: see->feel->change. Robin has a great example of using an application like Cruise control as a vehicle to change the developer's behavior. People have to write the test and do frequent check-ins to integrate. Good example of establishing a simple rule for injecting a behavioral change.