<!-- Content Here -->

Just say no to standups

I never liked regularly scheduled standup meetings. They interrupt your flow. They are boring because most of what is said has nothing to do with you. When an interesting topic does come up, the standup quickly transforms into a meeting-meeting that holds uninterested parties hostage. Standups are lame.

The good news is that, thanks to tools like Slack and Hipchat, we don't need to suffer through standups anymore. For around a year, my development teams having used ChICO (Checkin/Checkout) rooms. I got the idea from this blog post by Zsolt Kocsmarszky. When team members check in, they report what they are working on, who they need to work with, and any blockers they foresee. When they check out, they report what they accomplished and their plans for the next day.

This approach has multiple advantages over the classic standup.

1. It does not need to be synchronous.
   People report in and read at a time that works for them. They are alerted when a new announcement is made and can check it in their next stopping point.
2. It is scannable.
   You can scan over information that is not relevant. 
3. It is self documenting.
   Nobody needs to capture minutes or take notes.
4. It works well for geographically dispersed teams.
   Nothing is worse than a "phone standup" and, when timezones are involved, there is no good time to have them.
5. It cuts across language barriers.
   This may be the biggest one for us. My team's written English skills are great but the spoken word is challenging due to accents and "buffering" (when the time it takes you to decipher a word and recall it's meaning makes you fall behind). Removing that barrier has brought my teams closer together on both personal and professional levels. 

Rediscovering Private Chat

A few weeks ago, I moved my development team from Skype to HipChat for chat-based collaboration.  All the buzz around this new breed of collaboration services (such as HipChat, Slack, and Flowdock) was making me curious.  I had used private chat room technology like IRC and Jabber in the past with mixed results.  I also used to work for a company that made a product called MindAlign (which looks like it has been frozen in time since 2004).  In every case, these services were initially popular and then people drifted away to other tools such as AOL Instant Messenger (AIM), Yahoo! Instant Messenger (YIM), Microsoft Messenger, and Skype.  People preferred consumer chat services because you can also use them to communicate with your non-work friends. Nobody wants to run more software on their computer than they need to.

Times have changed. YIM and AIM are basically irrelevant only to be replaced by tools like Apple Messages, WhatsApp, and Viber.  But I think that there are bigger differences in play.

Smartphones have conditioned us to multiple channels

Now pretty much everyone runs at least two computers: a workstation on our desk and a personal computer in our pocket (our smartphone).  These two computers have different roles.  Your workstation is very clearly for work and your smartphone is focused on digital communications.  The smartphone has the best chat network of all (SMS because it is ubiquitous) and it is easier to use now that we have a keyboard.   The new chat services (WhatsApp, Viber, Apple Messages, Facebook Messenger) are all focused on the smartphone market.

Chat-based collaboration tools like HipChat don't have to compete with personal messaging services. It is easier for them to coexist because they live on separate devices.

Twitter and Facebook have built new habits

Integrations make chat collaboration tools more powerful

Why change?

Feature Request: Expiring Scheduling Calendar Views

Scheduling meetings is hard but it is a lot easier when all of the participants are on the same calendar server (Google Apps, Exchange, etc.). Despite all of the advances in calendaring, coordinating with participants in other companies hasn't gotten much easier in all the years I have been working.  Yes, there have been little victories here and there like Doodle and Tungle (which looked promising until RIM bought it), but overall, we are still sending times when we are available and hoping we stay available.  This is an increasing problem as business relationships become more dynamic and less siloed by corporate boundaries.

Google Apps has taken a step in the right direction by creating a free/busy view of your calendar that you can share.  But I don't love that option because that gives permanent access to that view.   It would be better to generate an expiring link that would give the user a view of the free/busy times for a few days (until the meeting is scheduled).

Google, Microsoft, anyone in the calendar software business - please steal this idea!  Just don't patent it so that only one customer community benefits.

What Game is your Team Playing?

I am trying to get a friend of mine to quit his job. No, I don't want him to join the massive ranks of the unemployed. I want him to move to a job that appreciates his talents and efforts. My friend (let's call him Bob) is totally dedicated to his profession. He is continually trying to improve his skills and productivity and wants to help his colleagues achieve better results too. Nobody brings more thought and interest to any task he faces. But he is surrounded on all sides by people who just don't care. They are satisfied by doing mediocre work. If something they build doesn't immediately fall over, they consider it done. If they can assign responsibility to someone else, they will. If nobody else notices a problem, it never happened.

It's frustrating for Bob. He can't accomplish his goals without help or at least cooperation. His company doesn't recognize the difference between his performance and that of his peers. In fact, he is constantly getting passed over. It doesn't feel fair. But it is fair. Bob is just playing the wrong game. Queue the metaphor...

Imagine that you are a world class tennis player. You live and breath tennis. You go into every volley trying to do your best and to improve upon the last one. You invest in coaching and resources to improve your game. If something might help you play better, (like a different diet, a different racket, or even one of those magnetic bracelets) you will try it.

One day, a friend challenges you to a game of Wii Tennis. You start to play tennis as you know how. Your knees are bent. You move your feet. You swing with explosive power. You are playing great tennis... but you are losing. You look over and you see your friend. He is slumped on the couch barely moving his controller with a flick of wrist. He looks like he couldn't walk across a tennis court without losing his breath.

As pathetic as he looks, Wii thinks your opponent is a better tennis player. Wii doesn't care about his form, his position, or how much leverage he has over the ball. Wii only cares about timing and maybe a couple other factors. Your friends knows this and he is not wasting any energy on what Wii doesn't care about. Your friend is the better Wii Tennis player because he has figured out how to do less but still satisfy the minimal inputs that Wii has been programmed to observe.

Bob is trying to play real tennis in his company's Wii Tennis tournament. He is not exactly losing, but he should be winning. The frustrating part is that he could be doing a lot less and get the same results. When he is on a team, he is constantly questioning whether he should be compensating for others by fixing their work — like in a doubles game when you see your partner is not running so you cover more of the court. His extra efforts only result in bumping into things and annoying people who just want to "sit on the couch and casually wave their hands."

Now the big question: who is playing the wrong game? It is difficult to tell if Bob's company would perform better if it paid attention to the finer aspects of how people worked and measured performance more holistically. It is unknown whether the company's customers would appreciate a higher quality product. But there are two things I know. 1) Bob wants to play real tennis, not Wii Tennis. 2) He doesn't have the clout to change the game that the rest of the company is playing.

The reason why I am writing this post on this blog is that I think that this story is very relevant to the pursuit of any type of organizational change, be it adopting Agile development or Enterprise 2.0. Companies can delude themselves into thinking they are playing a different game than they actually are. They may think they have a bunch of real tennis players who are striving for excellence and victory on a dynamic playing field; instead, they have a bunch of Wii tennis players who are looking for ways to minimize their personal/professional investment to only what is recognized. These companies get confused when they put a tool or way of working out in the wild and nobody adopts it; they shouldn't be.

Organizational change is much harder with the Wii Tennis company because you have to actively incentivize every behavior you want to see. It is not enough to say "this will make our company more effective." You have to say "do this specific thing and get points towards your performance review;" and you better not be lying because Wii Tennis players will see right through that. Finding real tennis players like Bob is hard to do — especially if you work for a large company. Real tennis players need a lot of room to move around and large companies tend to compartmentalize people. They need to be challenged in different ways to keep things interesting. Their rewards need to be tied to company achievement. Plus, other employees will get annoyed when you change the game that they have gotten so good at.

When building a company or even just a team within a company, think about what game you are playing. If your industry is commoditized and the difference between average and excellent is under appreciated by the market, it may pay to go after the Wii Tennis players and be very specific about expectations and incentives. If you are competing in a dynamic industry with a large upside, build a team of competitors who will take ownership of optimizing their personal performances and also the effectiveness of the overall team. They will innovate and try new tools and techniques that are offered. Most importantly, they will not stop a practice if it is difficult to do — they will only stop if it is ineffective or if they find something more effective.

When building communities, don't fall into the tool trap.

Chris Grams has an excellent post reminding us to avoid the tool trap when forming a community. That advice is so obvious yet so rarely practiced. Building communities is hard work and the temptation to experiment with technology is a distraction — a distraction so strong that it can obscure the fact that the community has no reason to exist. No matter what platform, the community will inevitably fail if it doesn't have the necessary ingredients: people with passion and a common set of interests and goals.

Technology can be an enabler but it can never be a driver. A robust community will survive with bad technology. I would say to intentionally use bad tools when you start a community. This approach will cause an unviable community to fail faster and save unnecessary investment. If a community is starting to grow despite bad tools, then you know you really have something worth investing in. By the way, if anyone wants to join my Julio Lugo fan club, fax me your fax number.

Wikis Not Word! Gaining adoption through psychological warfare

Your company has a perfectly good wiki but your (otherwise intelligent) co-workers insist on emailing you Microsoft Word documents to review. Your gentle guidance has been ignored. Your snarky comments have been equally ineffective. What do you do? I suggest the following method. Try it (at your own risk) and let me know how it works.

A co-worker has sent you and four or five other colleagues a MS Word document that summarizes some research that he did. The document contains some simple headings and paragraphs. You have a lot of ideas and feedback to give but, rather than give it all at once, you trickle it out and have your co-worker feel the pain of merging your edits.

• Draft 1: Re-Format. Don't really change anything, just format the heck out of the document. Change the styles around. Send it back with a cryptic filename like [irrelevant name]_[your middle name]_final.doc. Mail it with a note saying that it looks good and you had some slight wording changes. Leave it up to your co-worker to figure out that nothing has really changed.

• Draft 2: Re-Organize. A day after the first draft, take the original document you received and re-organize it. Re-order the sections and a few sentences here and there. Make sure that you turn on "track changes" so that the whole document is a multi-hued mosaic of change notifications. Name it [original filename]_new.doc. Send it with a note saying that you discussed it with another colleague and got some new ideas but "it is really coming along!"

• Draft 3: Edit. This is the version where you provide your real feedback. Start with your Draft 1. Make your edits. Name it [original filename].doc. Send it with a note saying how excited you are about this project and have been "thinking about it non-stop." Schedule a meeting to go over it and ask that your colleague send out a merged final draft for everyone's review. During the meeting, walk through everyone's feedback. By this time, your colleague is probably totally fried and is ready for a new way of working. At the end of the meeting, innocently say something like "you know, this might have been easier if we had worked in the wiki."

This method works even better if you have a co-conspiritor working with you doing the same thing. During the process, watch out for signs of mental instability or fragility and remove all sharp objects from the office. Make sure that the Employee Assistance Program posters are visible and well placed.

All humor aside, sometimes the only way to change people's ingrained behavior is to offer an alternative that is substantially easier. It has to be a big improvement because old habits are hard to break. Starting to use a wiki can be hard for people accustomed to Microsoft Word. They will initially get frustrated and resort to what they know. If you can't eliminate the learning curve of a wiki, you can expose the inefficiency of collaborating without one. The next time they launch Word, they will remember their painful experience and think twice.

J. Boye: Wiki in the Enterprise

Because of the inherent simplicity of the technology, wiki projects are less likely to fail in implementation than WCM or ECM projects. However, many companies still struggle to get the desired value out of their wiki initiatives. Purely managed and abandoned wikis have become yet another set of silos for information to hide in.

Janus Boye and Dorthe Jespersen's new report Wiki in the Enterprise contains a very well conceived and written analysis of what it takes to successfully implement a corporate wikis. Their research is based on interviews with enterprise wiki adopters and personal experience. It covers:

• the positioning of wiki's in the content technology marketplace and the benefits that they promise

• real world experience the impact and challenges of adopting wikis

• recommendations for executing a wiki initiative

Their advice covers the cultural and organizational aspects of information management that are so often overlooked in technology-oriented projects. If you are considering using a wiki to support collaboration or information management in your company, and rightly understand that success is not a matter of technology, you should definitely read this report.

Someone else agrees with me about email

I was pleased to see that at least someone agrees with me about the dangers of using overusing email.

Email and Content Management

I am not in the habit of identifying laws of nature or industry, but if I was, Gottlieb's Law would be "A company's success in content management is inversely proportional to the amount of information that is exchanged over email." Email probably has an 80% share of the content management market and that is a huge opportunity for growth of real content management processes and technologies and great opportunity for improvement for companies in managing their content. In fact, the next document management project I do, I want to baseline the number of email attachments before the project starts and not declare success until that number drops dramatically.

If you know me personally, you know that I often rail against email as a collaboration tool. A colleague of mine recently pointed out this blog post just to get my dander up. The desired results were achieved and I was not even soothed by the counter argument blog from the same source. I understand why email is such a tempting tool. That post outlines the reasons nicely: it is easy, universal, accessible, personalizable, reliable, and people just live in their email clients. Even I have to admit, the more you manage, the more you live in your email client. That is why most executives don't even need a computer anymore - just a blackberry to thumb a yes or no wirelessly. I could throw in a stick-it-to-the-man barb in here about adding value but I won't. What I will say is that if you compose the most brilliant text in the world into an email, it will have less impact than if you published it in some more persistent medium such as a blog, wiki, or forum.

The key issue that I have against email is that it compounds the problem of exploding volumes of unmanaged content by creating unnecessary duplicates. If you email a document to 2 people, you now have 3 copies to manage and merge and diff. No one knows which one is the master copy. No one knows which one is the newest copy regardless if someone stupidly added "new" to the file name. Plus, everyone is personally responsible for their piece of the archive. That is too much responsibility. If I accidentally delete the best version (it may or not be the latest version) of a document, there is no way to get it back.

There are lots of other issues I have with email. Many of them stem from a so-called benefit of email that it is a central place and it is in your face. Most people get too much email and are really bad at managing it. Because I monitor lots of open source mailing lists, I consider myself in that group. I constantly miss emails that sift below the scroll. I know that others have the same problem because whenever one of the mailing lists I subscribe to starts to get lively with good (or bad) dialog, there is always someone who complains about volume. What kind of collaboration is that? "Could you all please shut up? I have personal information management problem."

Never to be one to rant without a solution, here are some tips to solve the information management problem. I refuse to believe that the solution lies in building a better email client or integrating into email (other than sending an email notification of some event).

• See email for what it is: it's a messaging system. Use email to notify someone of something. If your message contains information that you want that group of people to continually refer to, put it somewhere that you all have access to.

• Publish information over RSS rather than email. I know that the marketing types still love their email newsletters and I know that some people still love getting them. It just feels incongruous to me to get these broadcast publications in the same place I want to get my business correspondence. I don't subscribe to any of them anymore. I am a bloglines junky instead. I also wish that there were two postal services, one to carry birthday cards and bills, and another to catalogs and credit card offers. OK. I know that I am asking for too much here. You can ignore that one. But, if anyone is listening, please stop sending me credit card offers.

• Allow the user to dictate how they are notified of content (email, digest email, RSS), not how they manage or receive content. Let the user subscribe to be notified when something changes in the repository (See CPS for a good model) but don't allow them to get attachments and take assets to manage "off the grid." Once you do, that document will take on a life of its own outside the system and become a threat to the system's relevance. The system should allow a user to send a link to someone rather than an attachment.

• This begs another question: offline access. I would suggest looking into a synchronization technology like Microsoft Windows Briefcase. Even as someone who travels a lot, I have grown to depend on the ubiquity of the network.

• If your team crosses organizational or company boundaries and you communicate enough, consider putting up some sort of shared space to work in rather than stay in the lowest common denominator (email).

• Experiment with tools that can take some of the burden off of email traffic. Open source is really nice in this area because you can try different things and see what people feel comfortable using. If it looks more complicated or difficult than email, people will use email.

• Don't be afraid of introducing a new tool. Anything is an improvement over email or nothing. If you are successful in getting people off of the old standby, you can leverage that success in migrating to a more centralized system. If you are good, you will understand what lead to success and apply those lessons to the configuration of the new system.

• You probably already have tools kicking around your infrastructure. Use them. If they don't work, give some serious thought as to why.

• Think content first, not documents. If you are publishing something, don't create a document when you don't have to. Too many people default to opening up a word processor or presentation authoring system the moment they have something to say. For example, if you have a collaboration space and you want to put up a phone list of the team, don't write it in a Word document. Create some kind of page instead. Why would you ask someone to download a document and open up an editor just to get a phone number? People will just save local copies and work from that. Then you have to deal with telling everyone that an updated version is available. If your collaborative workspace does not have pages, you have the wrong tool. My rule of thumb is that I only create a document when the content has to exist outside of the system. For example, if I write a statement of work or a white paper, it needs to be in a document.

• Think "page" or "post". A page is something that is maintained, a post is a snapshot in time. This blog entry is a post. If tomorrow I change my mind and I decide that I love email, I will write another blog post. My profile on this blog is a page. If something about me changes, I will update it. Use forum and blog tools for posts and wikis and WCM tools for pages. Of course, many WCM tools have content types for blogs and news releases and that is OK too.

• Make it easy for a person to join and leave the conversation. Forums are good in this way.

People were right when they called email the killer app. It is everywhere. It is extremely useful doing what it is good at: sending messages. It is also a victim of its own success and it's overuse, in my opinion, is starting to threaten
its usefulness. I would be very interested in hearing others ideas on this. Just don't email them to me ;).