When to stop

Toyota assembly line stops when something is wrong. There is a willingness to quit when things are off track - then they are on the path of mastery.

If you fire your worst boss, clients, stop working with the people who have no value, stop working on wasteful activities, then you free up an enormous energy. Direct that energy toward conquering great things and odds of success go way up.

Your pick?

You are presented with 2 options of picking a bottle of wine in a restaurant. One is going for 20$ and the other one goes for 30$. Which one do you pick? What if there is a third choice for 40$?

Last week I provided estimate to our users in a range, 4-8 weeks, 4 being the probability of have something to deliver. User’s understating was that we are going to finish in 6 weeks!

Better = Simpler

Many organizations view complexity as a sign of getting better. They make things overly complicated by imposing new processes which create metrics (usually they are not based on results) they like to have. The end result however, is very depressing: fear, pressure, uncertainty, and complexity. What suffers? Human CPU is not very good at handling pressure when things are complicated. Since complexity is the default (law of physics), you need highly creative people to make things simple. Creative people survive only in an environment which creativity is allowed. While many advanced teams are implementing proven methods to increase teamwork and creativity, still many managers are at sleep or denial, ignoring possibilities of doing things new ways.

At one time China was ahead of the West in science and technology then they started to believe that information was enough and progress came to a halt because they never developed “possibility”.

Simplicity is the best indicator of “getting better”.

The more "done" something appears, the lesser and narrower feedback get

One of my colleagues at work has asked me to give feedback on his vision document (position paper). Oh well, the document is so strongly voiced that I am not sure that it is a vision document, a road map or a solution to a perceived problem. The document is definitely looks sharp with pretty pictures of sunny vision and green road maps. It also has an appendix section containing code snippets of a tagged language (xml/xslt). I am sure that our friend has put tones of work into this and his document is well thought out and incisive.
So, why am I losing energy as I read through the document? So much of what I read strikes me as correct but somehow belittling of the problems real domain face. The vision: Reuse, shared components and shared database. The document then goes through some lengths to show a solution along with a possible implementation.
The problem with such a generic vision statement is more or less the equivalent of a manager advice/order to "get better." That is no help at all if not insulting. I am also not a big fan of vision first, team later approach. Most successful companies define a domain to explore, build a team and then have the team to come up with the vision.
I am losing more energy as I see the perfectly fonted and formatted draft, every sentence seems more done than you’d like it open. The solution proposed deal with small amount of real problem, pretty much like an iceberg where 90% of it is underwater. The best design is emergent and done through exploration rather than a perfectly prescribed solution.
Am I just grumpy, or others may get annoyed as well? I shared the document with NP and DR, they both reacted the same way as I did - just a little stronger.
Don't make the Vision or a design document look done. Here is the most damaging part of this exercise besides setting the wrong expectation as Kathy Sierra suggest:
The more "done" something appears, the lesser and narrower feedback get.
If you show me something polished and pretty, you’ll get feedback on font sizes. The possibility of getting feedback is far more achievable if you do it on a piece of paper, napkin or white board. Java people use Napkin Look and Feel, for the same reason.

When measurement becomes dangerous

Tom Demarco - based on the Rob Austin's book, Measuring and Managing: Performance in Organizations is that measurement is a potentially dangerous business. When you measure any indicator of performance, you incur a risk of worsening that performance. This is what Rob calls dysfunction.

Make the study interesting by using test driven approach

I was helping my daughter with the goal of making the social study subject interesting. Initially she was torturing herself by reading a page passively trying to get through the chapter. I was thinking that timing of this material isn’t right for an eleven year old person. We all get interested in these subjects later in life when we are busy working and there is no time for literature, social study and other great things.
To achieve our goal (learning the topic by injecting interest) – my daughter and I decided to use the test driven approach. Without reading any of the chapters we tried to answer the questions first. It was kind of like a guessing game which you do your best to come up with the answers. Now that acceptance criteria were defined early in the game and our brains were sensitized to those questions, we started reading the chapter. Every time we hit the line containing an answer – we look at each other, if we’ve gotten it correctly we smile, nod and hi five, otherwise we learn and that learning sticks.
This is a fear reducing method that can help your child [team] overcome something that is perceived as boring or scary.

Helping people determine if they work for an asshole.

This is the test of ARSE (Asshole Rating Self-Exam ) scores based on Bob Sutton’s book, The No Asshole Rule . Clearly, I am not a fan of profanity and forgive me for using this word here; however "asshole" is the only word that delivers the proper message in some situations.

How do you improve the productivity of meetings for software developers?

Bring a mobile projector to meetings. Many people may raise their eyebrows by saying it is expensive but if you use a projector in your working session you’ll see the difference. These days I say that every team should have one projector handy.
Why is this important? If you have a working meeting and need to share and see different things, it is far better to show everyone the same thing on a big screen. If you print screens on paper people will drift off and meeting can’t follow its course. The feedback loop increases once everyone is on the same page and usually your meetings are very focused and productive.
This is not as expensive as most people think. One of my friends said the price for a mobile projector is in the range of 1000 to - $2000. People are expensive; it doesn't take much to recover that kind of cost.
Sharing ideas over a big projector screen is a wise investment and cost reduction act.

Measurment Rules

"Isn't it about time we quit measuring professional success in one dimension, vertically, and start considering how much your actual work matches your desired work?"

1: A useful measurement should help you to understand and make decisions.
2: The cost of gathering metric shouldn’t exceed the benefit it provides.
3: The aim of metric shouldn’t threaten the safety of employees.
4: People who measure shouldn’t design it to nudge the numbers to make themselves look better.
5: Management shouldn’t have a preconceived outcome in mind and are open to whatever the data tells.
6: It is about learning
7: Use “Just enough” measurement to understand the system
8: Don’t measure individuals
9: Create Safety – Before collecting data, talk with the entire team. It’s critical that your team understands that they will not be blamed, ranked, or rated based on the data.
10: Assure your team that you won’t be using the data to evaluate them. You are depending on the team to collect the data, and you want accurate data.
11: Having distorted data is worse than having no data. If your team starts reporting the data in a way designed to make their performance look better, you will be relying on distorted data.
12: See the whole - Increase employee safety by only seeing aggregate data, not the results associated with any one employee. Otherwise you lose trust.
13: Gather Data based on your department goals, anything else is irrelevant.
14: Find the motivation - Ask why five times to get to the root cause of why we need these data in the first place.
15: You don’t have to have fancy automated data collection or an elaborate measurement program to do this.
16: Make sure the collected metric is used in a way to increase customer satisfaction.
17: Check the progress
18: Stop - if there is no reason to keep collecting the data.

137

Sometime back our team had a lot of fun using number 137 to estimates unknown requirements. We could have used another number like pi but pi was a known number and less likely to believe by the project office.
137 is a mysterious number mentioned by physicists as the value of the fine-structure constant (the actual value is one over one-hundred and thirty seven), which is defined as the charge of the electron (q) squared over the product of Planck's constant (h) times the speed of light (c). This number actually represents the probability that an electron will absorb a photon. Pauli the famous physicist did a lot of research about this number and he died at room 137.
137 is the odds that an electron will absorb a single photon. Protons and electrons are bound by interactions with photons. So when you get 137 protons, you get 137 photons, and you get a 100% chance of absorption.

Two biggest mistakes

1. Not giving your team authority and enough space
2. Not managing peer relationships effectively

Stand ups

It seems that people have a fear of justifying their work during standups rather than focusing on what can be done.
Last week I created a big visible chart (story wall) of actions, how and when columns and stuck it to the wall for everybody to look at. This helped people to become focused and they started signing up for tasks as oppose to a push system which managers assign tasks to programmers.
We also tried to prevent people from going into detail. Initially we were showing the red card as a signal but recently adopted yawing for indicating too much into detail sign. Yawing is very contagious - start yawning couple of times when a meeting gets boring, you’ll be amazed as to how many people will get infected and start to yawn.

The twenty happiest countries

According to the study by Adrian White the twenty happiest countries are (the world map of happiness):

1. Denmark
2. Switzerland
3. Austria
4. Iceland
5. The Bahamas
6. Finland
7. Sweden
8. Bhutan
9. Brunei
10. Canada
11. Ireland
12. Luxembourg
13. Costa Rica
14. Malta
15. The Netherlands
16. Antigua and Barbuda
17. Malaysia
18. New Zealand
19. Norway
20. The Seychelles

Other interesting data: USA (23), France (62), China (82) Japan (90), India (125). This seems like a good list of places to travel to. I am thinking about spending my next vacation in Costa Rica (ranked 13th).

Guide to success

From Richard St. John, author of Stupid, Ugly, Unlucky and Rich: Spike's Guide to Success.

Do you recommend this presentation to your friend?

Please let me know by adding * in the comments.

Measuring what? Criteria for good measurement.

1. Measure the cycle time
2. Measure the Business value, ROI and not the number of items or hours worked. Who cares if fruit that you made isn’t juicy.
3. Customer satisfaction – most will put their faith into customer survey – they allocate 1024 questions and forget to free the customer off. The ultimate question is much superior approach, you ask just one question. It goes like this: Would you offer this (product) to a friend? The scale would be from 1 to 10, 1 is recommending it to an enemy.

What happened to you?

To see how you have been evolved, do this simple comparison. Watch a movie that you have seen 5, 10, 20 years ago. Can you compare your feelings about this film to the feelings you had when you first watched it over many years ago? To put things into perspective, look at the code you have written many years ago. Back then, when you were young and trying to do new things with an open mind. What has changed?

Communication pattern

Couple of years ago I adopted the thinking process of assuming that everybody in the meeting is smarter than me. Since then I realized that this pattern gives you ammunition to communicate and understand others better.

The killer in any communication is the Curse of Knowledge. When we know something, it becomes hard for us to imagine not knowing it. As a result, we become ignorant to others people’s view and lousy communicators. Doctors can’t give you a straight, comprehensible answer to a simple question. His vast knowledge and experience renders him unable to fathom how little you know. He is trapped in a road which when he talks to you, he talks from his view that you can’t follow. And we’re all like the Doctor in our own domain of expertise.

This is illustrated in the story by Roger von Oech about a creativity teacher who invited a student to his house for afternoon tea. They talked for a while, and then it was teatime. The teacher poured some tea into the student's cup. Even after the cup was full, he continued to pour, and soon tea overflowed onto the floor.
Finally, the student said, "You must stop pouring; the tea isn't going into the cup." The teacher replied, "The same is true with you. If you are to receive any of my teachings, you must first empty out the contents of your mental cup." His point: without the ability to forget, our minds remain cluttered with ready-made answers, and we're not motivated to ask the questions that lead our thinking to new ideas.

Design by looking at Nature

Steve Jobs mentioned that human can learn a lot from the nature and use those in design. Here is an industrial designer, best known for his work on the Sony Walkman and Apple iMac Ross Lovegrove presents his recent work. Here is a link from his wonderful presentation at TED talk conference.

Performance Evaluation

If you are like me, you would be a big fan of outsourcing tasks that you are either not capable of completing (like ordering things, creating legal documents or whatever is your skill gap) or loathe doing (like filing, copying, estimating numbers for some boring planning or responding to tons of administrative tasks).

One observation I have is seeing our most talented people are doing tones of administrative at different points. Would it be better to focus on what we are good at?

This brings us to one of these tasks - performance evaluation process (one I loathe passionately). Wouldn’t be better to focus on people’s strength rather than telling them “You need to improve on x and y area” and judge them based on some stupid grading system. Imagine if we have a Mozart in our team and wanting him (a great composer) to be good at audit, running reports, and tracking projects! I feel many managers killing talents this way unintentionally.

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.

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.

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.

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.

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.

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?

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?

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 10^th 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

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

“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."

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 9^th over having a wonderful food in an Indian restaurant – one of my friends said an interesting thing: “start deleting code…” - Looking back at 4^th 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.

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

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

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.

Agile/Lean Screen Savers

Everyone chose their own screen saver, wallpaper, and pictures on their monitor. Since the screen savers appears on computers (especially in a corporate environment they can appear on all), there is an opportunity to introduce the company’s visions, values, and principle by pushing those words to people’s computers.

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/

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.