Ego and Checklists

I must have some secret employees at the Financial Times writing for me or something. Atul Gawande wrote ‘Airline Pilot’ protocols in finance today and it caught my eye.

Some choice quotes:

He also found he made mistakes in handling complexity. A good decision requires consideration of so many different aspects of a company in so many ways that, even without the cocaine brain [confirmation bias], he was missing obvious patterns. His mental checklist wasn’t good enough. “I am not Warren,” he said. “I don’t have a 300 IQ.”

So he devised a written checklist.

Sometimes you don’t even know you’re making the mistakes over and over unless you get reminded of them by using the checklist. It’s there to keep you safe from your own mind. The easiest person to trick is yourself.

Even in his own firm, he’s found it a hard sell. “I got pushback from everyone. It took my guys months to finally see the value,” he said. To this day, his partners still don’t all go along with his approach and don’t use the checklist in their decisions when he’s not involved. “I find it amazing other investors have not even bothered to try,” he said. “Some have asked. None have done it.”

As I said before, people think checklists are beneath them. I’ve had a hard time convincing people to use them in any aspect of project work. Clients don’t like it because they think that’s why they hired you in the first place; you’re the expert. Consultants don’t like it because they think it will somehow make them look incompetent.

I’ve tried many different ways of motivating people to use the list, but in the end nobody seems to want to listen even when I show them measurable results. Ego.

Atul has a book out as well. I’ve already ordered it. Will you?

Checklists

One of the main duties I performed as a consultant was kicking off a project for a new client. The process went by many different names. Iteration zero, project kickoff, inception, and QuickStart. Sometimes a combination of them.

The thing I learned right away was that there was always plenty to think about and set up. All projects are different of course, but all projects are also the same in many ways. So, I began to do what I always do in a new situation and make a checklist.

I learned this skill a long time ago and it has served me well in many different ways. To my clients, I seem to have a super memory and intellect. Combining the checklist with GTD helps greatly. To my colleagues, I can share the list and get feedback and improvements for my own projects and help theirs. Now on with how to create your checklist.

First, I almost never start from scratch. I look to those who have done it before and have learned lessons the hard way. Nobody is smart enough to think of everything, and besides, why duplicate work? Look to retrospectives, post mortems, project wrap ups, lessons learned, bug reports, lawsuits (yep…), API versions, forums, email lists, etc. Anything where people are seeing 20/20 after something went well or, more importantly, something went wrong. Put it all on the list without filtering. If you don’t have stuff written down somewhere, try interviewing people and listen to their war stories. You’ll learn some good lessons. Write. Them. Down.

Second, once you have your list, try organizing it by rough topics: architecture, project management, QA, analysis, client relations, contracts, etc. This is a good time to take the list to your coworkers and ask them to fill in areas that you’ve missed. The important thing to remember is to keep things on the list unless they are incorrect. This list is for all projects, not just “your” project.

After you’ve created your checklist, put it somewhere it can be seen and used as well as collaborated on. A wiki is great for this because you can have multiple editors and you’ll get to see all of the versions. Tell people where it is and have them use it. Asking for feedback on how it works is a great way to get them to use it. They’ll improve things and add new items as they come up.

At this point, you’re probably expecting an example or even full version of my checklist. Sorry. That would rob you of the experience of creating it yourself which is well worth your time in just the collaboration alone.

Initially, people will complain that your checklist is too long. Ignore them. Explain that the checklist is there to keep them safe and spending a 30 seconds or a minute on each item on the checklist will save them loads of time and mistakes later.

One last thing. The checklist is a great tool to make sure you haven’t forgotten anything, but it isn’t a substitute for critical thinking. The checklist will help you to not look dumb, but you still have to be smart. Good luck.

Sophisticated vs. Complicated

Remember learning to ride a bike or drive a car? It was hard at first, with all of those things to remember and do at once. Put your foot here, your hands there, look straight, now look in your mirrors, gas, brake, turn signals, WATCH OUT FOR THAT TREE!

Driving that car or riding that bike seemed like a very complex activity. You didn’t know the simple steps to take and they weren’t natural for you yet.

What we didn’t realize then was that those things were sophisticated, not complex. They only seemed complex because we were trying to learn and remember and do things all at once.

Breaking something down into smaller, easier to understand parts allowed us to master those things. We had training wheels for a bike, someone to hold us and push us when we needed it. Learning how much pressure to put on the brakes of a car while going straight in a parking lot.

We could then put those things together into a sophisticated process that became more than the sum of its parts. It just looks complex to those who don’t know.

The next time you are learning something complex, remember it is probably just sophisticated and you need to break it down into smaller parts and master those things before trying to do the rest. Agile adoption is a good candidate for that breakdown.

So if you are learning something new like Agile, find out where you can break it down and learn small things at first. If you are being taught or coached by someone else, make sure they teach you this way. It is much easier. If they disagree, ask them why.

Keep Your Ear to the Ground

Ear to the ground

I’m always trying to find new ways to use technology to keep track of what’s being said out there.  Be it websites, RSS, mailing lists, twitter, etc. I try to know what’s going on for myself, my clients, and my colleagues.  As with most other things in life though, I always find someone who is doing it better than I am.

I created a twitter account using my name and not more than 24 hours later, Jason Calacanis followed me.  While this is not huge news (Jason has 62k+ people he follows), it was to me.  It means that Jason or a script is parsing his mailing list subscribers and finding them at places like twitter.  He can hear the train coming from miles away.  Can you?

Fear is Sand Under the Foundation

I’ve spent a good chunk of my life building houses with my family and also Habitat for Humanity.  Most people know the cliche that having a strong foundation is key to building a house.  That doesn’t make it any less important.  Today, Seth talks about the five pillars of success.

The five pillars of success

1. See (really see) what’s possible

2. Know specifically what you want to achieve

3. Make good decisions

4. Understand the tactics to get things done and to change minds

5. Earn the trust and respect of the people around you

It sure seems like we spend all our time on #4.

Seth doesn’t answer the question of why we spend so much time on #4.  The same reason we spend so much time on #4 and so little time on the others is fear.  Fear that we’re not good enough, fear that our dreams are too small, fear that we’ll make the wrong decisions, fear, fear, and more fear.  That fear brings all of the pillars crashing down.

For people who have never felt they could lead, I say take the first step.  Spend your time on something you find worthwhile and just start doing it.  Here’s the secret: you’ll make mistakes.  Probably a lot of them at first, but that’s often the best way to learn.  Learning to be alright with and recover from failure will help you get over your fear.  It will certainly help you with #5.

via Seth’s Blog: The five pillars of success.

Set The Mood

I had a conversation with a colleague about doing consulting and that there’s really no such thing as an “organization.”  There really is just a bunch of people who need their minds changed.  The CxO’s I work with usually only need a minimum of technical help, mostly they need an outside change agent to help get their people in the mood to do their best work, so they hire me.

You already know how to deliver excellent service that blows people away. You just don’t feel like it. Your organization has the resources to buy that machine or enter that market or change that policy. They’re just not in the mood.

If I accomplish anything on a good day, it’s helping you change attitudes. I’m working hard at getting you in the mood to do the things you already know how to do. I think that’s what your boss/the market wants you to do as well.

via Seth’s Blog: In the mood.

DSLs and Friends

My friends and fellow ThoughtWorkers Michael Schubert, Jay Fields, and Stephen Chu were just complimented by Martin Fowler.

This isn’t to say that there’s no benefit in a business-writable DSL. Indeed a couple of years ago some colleagues of mine built a system that included just that, and it was much appreciated by the business. It’s just that the effort in creating a decent editing environment, meaningful error messages, debugging and testing tools raises the cost significantly.

What Martin doesn’t go on to explain is that this project vastly improved efficiency for a whole organization.  They went from a situation where it took months with dozens of programmers to change some business rules in their software to minutes with all sorts of extras they couldn’t get before like “what-if” simulations.

Jay wrote about some of the things they learned in this presentation on InfoQ and much more on his blog about DSLs.

via MF Bliki: BusinessReadableDSL.

What’s Your Exit Strategy?

An occupational hazard of being a consultant is that you get to see lots of the same problems in many different organizations.

It seems that sometimes little thought is given to how an organization can move from one technology to another or to move from legacy systems (where legacy means it doesn’t fit the organization anymore) to better solutions.

Today’s decisions can be tomorrow’s botleneck or bad design. It’s just a matter of time.

What can you do to help your future organization? Things like SOA can help. Great tests around your application are essential if you ever make the choice to change.

I’m looking for something better. I don’t know if you can ever get to a system that is that responsive to change. I’d like to see one that is.

A Shift In Attitude

Agile is about a shift in attitude more than process. It requires a shift in focus that is easy to explain, but hard to put in practice.

A useful way to view making the change is as an investment. There are many advantages to thinking this way about how you change an organization.

Being disciplined about investing in people, testing out theory, evaluation and constant improvement go a long way.

When you look to implement this kind of change, process only takes you part of the way. The mechanics of analysis, for instance, can be taught in a few weeks, but it takes a deliberate shift in thinking as well as practice to get good.

Shifting language is a good first step to shifting attitudes. Language around collaboration rather than commitees and processes. Shifting from requirements to goals and priorities.

When you change language, you can start to change minds. It’s a long road and it helps to have experts to guide you along the way. Don’t expect a magic process and if you work with me, expect a conversation.

Mingle Ubiquity Commands

I’ve started a project to create some useful Ubiquity commands for Mingle.

Here is a video of it in action.


Ubiquity for Mingle – First Cut from Joe Homs on Vimeo.

You can view the project at github.

Stimulate The Economy: Start A Business

As we begin our latest downward slide in the economy, people are starting to lose their jobs at an alarming rate.

Instead of looking for some other job, why not create one for yourself? It is easier than most people think if they simply choose what’s right for them.

“What is the right company to start?” I can hear you asking. Something you know and that can be tested easily with minimal costs. I don’t know what that is for you, but you do.

It’s old advice, but worth repeating. Look for something that comes easily or happily to you. Something you are an expert in that you can turn into something to sell to others. If it is hard to replicate, even better.

Once you know what it is, start small and test out the results, but start today. That is the key. Your business model is only going to be perfect by accident. Be willing and able to change.

How does this help the economy? By creating jobs, tax revenue, etc.

If you’ve gotten this far, let me know. There are so many people out there that are willing and able to get you even further.

PSA: Don’t Generate Offensive Promo Codes

OK folks, I’m now on my 3rd client having problems with certain four letter words coming up in their automatically generated promo codes. It’s easy to get around this problem in a very simple way: Don’t use vowels in your promo codes if you’re using letters. No need for special filtering software or huge lists of banned words. You can always add complexity later, but that simple rule will help you more than the rest.

If you want to get more careful, you could alternate letters and numbers, or use some other strategy. To be kind to your users, be aware that some numbers and letters look the same to people and they will enter your codes wrong (or worse, enter in someone else’s code by mistake).

To help you, here’s a list of the numbers and letters I suggest people use because they won’t get them confused with each other and hopefully your system won’t create any bad words (if they do, let me know). If you’re worried about the number of combinations you can make, just add more characters to the length of your code or allow yourself the option to generate your own special codes.

letters = ['B', 'C', 'D', 'F', 'H', 'J', 'K', 'L', 'M', 'N', 'P', 'Q', 'R', 'S', 'T', 'V', 'W', 'X', 'Y', 'Z']
numbers = [2, 3, 4, 7, 9]

You could then take this and make a simple ruby method that does something like this:

1
2
3
4
5
letters = ['B', 'C', 'D', 'F', 'H', 'J', 'K', 'L', 'M', 'N', 'P', 'Q', 'R', 'S', 'T', 'V', 'W', 'X', 'Y', 'Z']
numbers = [2, 3, 4, 7, 9]
promo_set = letters | numbers # combine arrays
promo_code = promo_set.sort_by{rand}[0..14].to_s # randomize array and take the first 15 elements and make them a string
=> "CS4FZLHVMPK3QJN"

Documentation Is Conversation Frozen In Time

I’m on a new account this week and my colleague Julias Shaw coined the phrase in the title.

We have been trying to get our client to realize that the solution to people not reading huge requirements documents all the way from development to QA to support is not more documentation, but more communication.

We are all for documentation, but only the kind that people will actually read.

A Story About Me Written By My Grandmother

Joey at 7 Years By Ruth

Last night, as I sat with my grandsons reviewing their five and seven year old accomplishments, I was drawn again to memories of my own childhood experiences. Joey, my seven year old, proudly displayed his ability to write in handwriting, which had mostly been learned through self teaching, some of his capital letters. This, despite the fact that his mother was repeatedly requesting that they say goodnight and get ready for bed. “Let me show you a capital T, Gramma”, he said, laboriously outlining his project. “Oops!” I remarked, “You shouldn’t have crossed the T, honey, that makes it an F.” There was a stricken look on his face, and with an “Oh no!” he left the room. He returned shortly with his specially wrapped gift for his parents which had a large beautifully made capital F in “Fo Mom & Pop.” I whispered to get an eraser and we would fix it and he went and desperately began searching the drawer where such things were kept. Mom, by this time, and not knowing what was going in, demanded that bed time was now! And she forcefully directed him toward the stairs. The enormity, to him, of his predicament, started a totally frustrated cry, but he went upstairs. When she returned I briefly told her what was happening and went to call the sobbing child for just one minute. I explained to him that if he added a small “r” to the “Fo” it would change the word. With brimming eyes, and a moment’s thought, he realized it would say “For” which was perfectly acceptable. Tears stopped, the correction was made, and a true weight had been lifted in his young mind.

It is the tendency of busy adults to forget the importance of the little tragedies that are as monumental to a small store of experiences in children as larger ones are to adults. Showing them how to deal with and minimize error is one of the best and kindest tools to give them. The humiliation and lack of self esteem that comes from not doing what is acceptably correct can leave a scar no different than the scar an adult gets from the same type of things. The child has within him the adult he will be. Treat him with the respect you would afford, and the kindness you should use, in your dealings with all people.

The enormity of unresolved calamities of my own childhood, though they are small by adult standards, still come back to haunt me. Not that adults were uncaring, but there was an opinion that because children were small, their feelings were relative to their size. Not so! The adult is wrapped in a small confining package, straining to find answers to enormous complexities in the child’s body.

I miss you Grandma.

Sugarcoating Is Harmful

When you have to evaluate someone, it is easy to err on the side of being nice. When you really like the person outside of work or they are your friend, it becomes doubly hard. It is still important to be honest with feedback for someone so that they can improve and important for future teams so that they can make sure the person is the right fit.

I tend to use a lesson learned long ago to escalate problems I’m having with people.

First, talking to the person is often the earliest and easiest way to give someone feedback. Often people will not know something is wrong and are more than willing to fix it.

Second, if the person doesn’t respond, let them know you will take your feedback to their boss if needed. Give them a timeframe to improve and tell them what you will do if they don’t.

Third, evaluate how the person is doing and possibly even get a second opinion.

Finally, putting honest feedback into a review will help teams evaluate the person’s strengths and weaknesses for the future. Even bad feedback with a good outcome can help someone’s review for the future. Who doesn’t like to see someone improve?

When you sugarcoat a review, you hurt the person by not letting them improve and future teams they will work with by not letting them see where they need to cover or help someone.

Mingle Tip: Automatically Refresh Mingle

I’ve seen many teams using Mingle as a card wall instead of using real index cards. Usually the teams are distributed, so real cards wouldn’t help anyway. They all run into the same problem that Mingle doesn’t have a feature to automatically refresh a page throughout the day as the team updates cards. I’ll show you a few simple solutions you can choose from to refresh Mingle automatically.

Firefox Extension

A quick and easy solution is to use a Firefox extension that can automatically refresh any page called ReloadEvery. This is probably the least amount of work and works just fine.

HTML IFrame

I’ve also created a small bit of HTML that uses Javascript to refresh an IFrame that takes up the whole page. Just change the google URL to whatever page you need to point to and the amount of seconds you want it to refresh (set to 5 right now). It works in all of the browsers I could find.

Download Radiator

Reduce Your Meeting Dependency

I had a client almost two years ago that was plagued by meetings. Many employees would have back-to-back meetings lasting all day. All of the common symptoms were there: unessential people, no agenda, no clear goals or tasks at the end of a meeting. I remember being annoyed by this the whole time, but the straw that broke the camel’s back was having back-to-back meetings about the same thing.

We coined the term MDD or Meeting Driven Development for them and helped eliminate a huge percentage of their meetings with a few simple rules and tricks to show them him much a meeting really cost them.

First, if there was no clear agenda over email at less an hour before, there was no meeting, period. Initially it was just the consultants that wouldn’t show up, but the full time staff eventually did this too. Often this would eliminate meetings entirely as questions could be answered over email.

Second, we set up a mailing list for people to post to on topics that were relevant to the business including off-topic boards so people could have fun and not clog inboxes. This helped kill meetings by giving them a searchable repository of knowledge.

Third, a wiki was set up with many common threads expanded in a more readable format. Wiki pages were updated and constantly referenced in the mailing lists.

What was the result? More productivity due to more time not wasted in meetings. People actually had time to do work again.

People often wonder why consultants can be so effective at a client site. There are many reasons, but a good one is not being subject to all of the administrative tasks and processes that an employee is put through. Sometimes it is simply that consultants cost too much for the client to be willing to foot the cost of a distracting meeting. Employees are no less important.

Note: agile principles dictate people over process which encourages talking rather than documenting. I’m not against all meetings, only unimportant ones that are wasteful of everyone’s time. Don’t invite 10 people for an hour when 2 for 5 minutes will do just fine for now.

Mingle Tip: Search Mingle Projects Directly In Firefox

Do you love using Firefox’s built in Google search? Wish there was a way you could do that with your Mingle projects? Well, now you can with the code below.

I’ve provided a download of the xml file here.

You’ll need to edit the file to point to the Mingle project you want to use the search tool with and then you need to install it into your searchplugins directory for Firefox, which for Windows is probably something like

C:\Program Files\Mozilla Firefox\searchplugins

and for Mac is something like

/Applications/Firefox.app/Contents/MacOS/searchplugins/

Drop the xml file in the folder and restart Firefox and you’ll have your new Mingle search up and running. It should look like this

Note: I’m working on getting this to work as described in this mozilla dev article for Mingle. It shouldn’t be too hard since we can modify views in Mingle. I’ll blog about it if people are interested.

PSA: Tab Between All Controls On Mac

I normally love the Mac’s design decisions, but one thing that’s always maddened me is that by default you can’t tab between all controls on webpages, etc. I finally got that fixed today with an article from lifehacker.

Click the “All Controls” radio button at the bottom of the Keyboard & Mouse pane in System Preferences to right this wrong.

Bliss.

[via]

When Distrust Turns To Disdain

While taking computer science classes in college, I was taught to distrust a user’s input in all cases. The theory goes that a user’s data can’t be trusted because it could be malicious or just a simple mistake that causes your program to have an error with input it didn’t expect. So you protect your system from incorrect user input and sanitize it. It always felt like one of our dirtier secrets to me, however I fully advocate the practice in code.

My problem comes when the people building software turn from distrusting their user’s input to having a level of disdain for the users themselves. It starts innocently enough with the engineering principles I described above, but can sometimes turn into small things like, “Our users won’t understand that,” and starts to slip into things like, “Our users are dumb, so we won’t do that.” If you’ve started to hate your users, you’ve gone too far. If something is too complex for your users to understand, it’s your job as the developer/engineer/analyst/etc. to make it so that they can understand it. If you think of your users like idiots, your system will reflect that and they will notice.

If your job is to design software for people to use (which, is pretty much all software), make sure you work with the user, instead of against their best interests.