# Monday, 15 February 2010

The story of human achievement is almost always one of teamwork. While we celebrate individual accomplishments, like Neil Armstrong stepping foot on the moon, it is always the team that makes or breaks the effort. I have always been interested in why teams succeed; it is easy to figure out why teams fail. A lot of time we think that we need a team of “Ninjas” in order to succeed, or a superstar team leader. In reality we need neither the Ninja team nor rock star team leader. For better or worse, I have been leading teams for a long time and I maybe a decent team leader now, but I was not early in my career-I have made every mistake in the book! Upon reflection of my past successes and failures I recently turned my attention to the question of why do teams succeed?

The problem with answering that question is that each team is different and even if you measure one team over a period of time, chances are that they worked on different projects or with different users, so it is difficult to get reliable observations. To gain some reliable observations you would have to observe one team working on virtually the same project, with virtually the same users, over a short period of time.

The good news is that I did just that. About 10 years ago during the .COM boom, I was the team leader of a team that was working on a website. (Surprise, surprise back then!) We worked on two short iterations (we did not call them that since this was before “Agile”) that were very similar in scope and requirements and worked for the same users. One iteration failed completely (the second one) and one was a smashing success (the first one). What was the key difference between these iterations? Everything was the same, the users and the developers got along, all key members were engaged, all the requirements were clear. What was different?

During the first and more successful project , I was on the “disabled list”. My ankle and leg were hurt while rock climbing and I had to walk around with a silly cane. (My doctor wanted crutches, but I refused.) It hurt to walk, even to stand, so I tended to stay put in one place at a time. As luck would have it, this company was an aspiring .COM, so they had leased a ridiculous amount of office space since they were going to hire 500 more people overnight. (Remember those days?) Since it hurt to walk, I usually just camped out with the business users at a spare desk.

Sometimes I overheard something the users would say that would affect the system and just butt on in that conversation. Sometimes they wanted to bounce things off my head and since I was right next to them, we had a lot of ad hoc meetings. This produced a better quality of communication. Studies have shown that there are thousands of communication "points" delivered with facial expressions and verbal tones/speech patterns. This gets lost in email, documents, etc.

Besides the close proximity to the business users, the development team would be around a lot too. While email was popular back then, I believed (and still do) that in-person communication is better, so I would not reply often to emails (especially vacation requests), forcing my introverted developers to ask me things face to face. This lead to other mini-meetings with the users and developers; business users would also overhead a team member coming to me lobbying to cut or add a feature and butt into that conversation with their perspective.

When the second project started, I was almost healed, so I tended to hang out in the IT department more often. (I also started to walk around with a baseball bat instead of a cane, that that would frighten people who did not know me.) As I said before the second project was a big failure and we later figured out that my leg was the only variable that had changed. For the next project iteration, we made it a rule to have a technology person sitting with the business team. (The guy who suggested this won the first shift with the users.) The collaboration between the business team and the technical team was the deciding factor and I have stressed team collaboration ever since, and my career has been the better for it.

You may be thinking that this is impossible in today’s day and age with distributed teams and rapidly changing requirements. The company I co-founded a few years back, Corzen, employed this strategy, even though we had a distributed team with both remote employees and overseas contractors. At our Corzen headquarters in New York City, we had our seating arrangements in an “open” style where the business team and the technology teams all sat together at desks right on top of each other alongside the sales team. While it at times did suck (like when my girlfriend would call and everyone could overhear our conversation), it paid many dividends. When the salesperson obviously lost a sale because of a lack of a feature that you lobbied against, it is far more powerful to hear the play by play in real time than getting an angry email from him later on.

Corzen had remote employees as well as overseas contractors, and we collaborated and communicated well with them. Of course we could not have them sit with us in the “bullpen” as we called it, but we did involve them on very frequent calls and webinars with our business team. The business team would make all of their documents available on a share or Google documents and over-share information instead of under-share. During the design phases the team would always communicate well and keep that communication going almost daily. New team members were inserted all the time and would come up to speed very rapidly. Of course the technical team held daily scrums using Skype and reported both ways (to the tech team and the business team) what was going on. This process was so successful that it lead to a great deal of success and Corzen was acquired by a larger entity based in another country and it still operates this way.

So if I have to sum it all up and answer the question why do teams succeed, the answer is pretty easy: communication, collaboration, and being “in the flow” of the emerging process. I have always known this, but my experiences described above enabled me to re-discover it. The best teams can finish each other sentences. Successful projects that I worked on had high bandwidth communication and extremely small feedback cycles. Success projects communicate and work "the way humans" should work - more face to face, more verbal. They also didn't rely up documentation to collaborate/communicate need/specification. Users don’t have all the answers, the requirements and features need to be discovered jointly by having a technical team member embedded with the users, or tools that mimic the fluidity of being together. Toyota perfected this process twenty years ago; the agile movement that started ten years ago was a recognition of this, so we have the knowledge of what works and what doesn’t work on projects. Embrace collaboration, communication, and work “the way humans” work (or mimic that fluidity if your team is remote) and you will have successful projects all the time.


Technorati Tags:

Bookmark and Share

posted on Monday, 15 February 2010 14:46:36 (Eastern Standard Time, UTC-05:00)  #    Comments [4] Trackback
# Friday, 12 February 2010

As you all know by now, Google unveiled its latest attempt at social networking this week, called Google Buzz. The first reaction was that it was Twitter meets GMail and some folks joked and called it Glitter. Sure it got 9 million posts in the first two days, however, it is doomed to fail.


Buzz is a response to Twitter and to some degree Facebook. In the past if news happened, you went to Google to see what was up. Nowadays, you go to Twitter first to get the real time news and see what people are saying. You only go to Google for what I call the encyclopedia search, like “who was in that movie?” or “what year was xyz” or “what is the name of that blah blah?” All real time stuff you go to Twitter, like “what is going on at the TED conference this weekend?” As the saying goes, Twitter starts arguments, Google ends them. Twitter and social networking (when you can ask your network a question instead of Googling it) are a threat to Google’s core business model: owning search and the ad revenue around it. Buzz is an attempt to mitigate that by creating the platform for people to go to for real time search and social networking.

The problem with Buzz is that it brings nothing new to the table, except maybe GMail integration, but if you use Facebook you can pretty much replicate that. We already are on Facebook, LinkedIn, and Twitter, so who needs Buzz? Buzz is already too far behind and does not have any break out features, so it is not going anywhere anytime soon. Google is Google and will get some traction just because of its strong brand: just look at the PR around the Nexus One and Android, however, those are great products. Buzz is (at this stage) just a copy cat of what is already out there. I don’t see the platform growing into something better anytime soon either.

At Google, its founders still have a strong say in everything the company does. That is not a problem, look at how successful Google has been; look at Steve Jobs’ hold over Apple and that seems to be working out. But at Google, Larry and Sergey get a lot of things, however they don’t “get” social networking. Google has tried and failed with social networking and community in the past and most visibly ran Orkut into the ground and acquired YouTube since GoogleVideo failed. Google will need to bring in someone big from the social networking community to own Buzz. Since Google has deep pockets, I am sure they can. My advice to Google is to do this pronto and then rethink what Buzz will do.

Google should reposition Buzz to be a master consumer and publisher: the place you go to publish and consume all of your social media content. This way they will get all the eyeballs and then hence, all the ad revenue. What would be great is if Google Buzz talked to all the APIs of all the social networking sites and used OpenID and created one social networking portal for you. You can post your photos, blogs, status updates and consume content from all of your contacts (“friends”) on all the social media sites without having to sign up for them all (or join them all). I constantly get invites to fringe social networking sites from friends overseas and refuse to join some of them, but I am missing out on that content and connecting with those friends. Google Buzz can solve that problem, I can consume that content without joining.

Google will also have to work on a breakout feature to get all the people to visit Buzz, maybe an image search: I can upload my photo and then search across all the social networks for image recognition of myself. Throw on top of this portal some awesome search and categorization and filtering that made GMail so successful and you have a great platform. Then Google Buzz could be the only social networking site you had to visit.  Today I have to check my RSS feeds, Twitter, Facebook, LinkedIn, Flickr, Gmail, and like 10 other sites I am a member of. Sure I have some email integration and RSS readers, but it is not a true one stop shop. Google Buzz can do that. If not, they are doomed to fail.

Technorati Tags:

Bookmark and Share
posted on Friday, 12 February 2010 21:27:37 (Eastern Standard Time, UTC-05:00)  #    Comments [2] Trackback
# Thursday, 11 February 2010

Fifteen years ago I was a programmer on Wall Street. Times were good, it was the boom economy and Fidelity Investments where I worked was flush with cash as the Dow just hit 4,000 for the first time. (Yes you read that right.) I had a great office in the (now gone), World Trade Center looking at the river and I coded client server applications all day. We were waiting for the conversion from 16 bit to 32 bit with the arrival of Windows 95. Except for arguing with my annoying co-worker Ronald who wanted to write his own grid (I wanted to buy a grid, so it is funny that 15 years later I work at a component company), life was good. I was a good programmer and I use to dream of being CTO of Fidelity Investments one day.

Then one day one of my buddies and I went to an event for IT professionals hosted by Netscape. It was about the Internet, the browser, and this new Java thing. At the session, they threw my entire 3-tier, client-server world upside down. “Dude they are talking about going back to the days of Rumba dumb terminal” my friend said to me. The speaker kept saying that the browser is going to be ubiquitous. (I had to look up ubiquitous when I got home.) A very tall guy from Sun said that “The Network is the Computer.”

I went home that night and canceled my AOL account and joined pipeline.net, an ISP that allowed you to surf the “real” web with Netscape Navigator 1.0 via dialup. Over the next few weeks I took a class on Java and taught myself HTML and put up a web page. (Full disclosure, I abused the <Blink> tag. Sorry, I know some of you now think lesser of me.)  Later that year when Fidelity did not embrace the Internet fast enough for me, I quit and stared my own business to focus on “the internet and databases.”

Somewhere around 1998, the guy from Netscape was right, the browser was ubiquitous. Every Super Bowl ad had a “www'” at the bottom as did every magazine ad. HTML ruled the world. It continues to rule the world to this day. It is hard to believe that HTML is only on version 4.

Then came the iPhone. Web pages on the small screen just don’t work well. Enter the world of applications or apps. So today, instead of web pages, we interact with the sites we like with Apps. Use Facebook on the web? Download the App. Need a currency converter, weather notification, even news and sports scores, there is an app for those as well. No longer do you need to go to a web page, you are using a native application on the device you are using. This will only proliferate with the iPad and rumored Google gPad.

I have never been a believer of 100% “The Network is the Computer” or “back to dumb terminal” browser only computing. Hardware is too fast and too cheap to not take advantage of local graphics APIs, local memory, and even local storage for caching and backup. Why code to the least common dominator? Why should you have “Google docs” just in a browser when you can take advantage of the local device for spell check, rendering, and cache? A hybrid approach is the best bet, with the ultimate storage in the cloud, but the application will store a cached version locally and also have a local App that takes advantage of the local API and rendering engine. This is what all my apps on my Android phone do now, from TripIt to Facebook to a simple currency converter (which I can use offline).

HTML and the web page dominance is now over. A whole generation of users are growing up using devices and interacting with the internet only via Apps. Apps are our future; we are now living in the App Economy, as Business Week puts it.

Apps are the new HTML.

Technorati Tags:

Bookmark and Share

posted on Thursday, 11 February 2010 04:01:40 (Eastern Standard Time, UTC-05:00)  #    Comments [1] Trackback
# Wednesday, 10 February 2010


Registration for NYC .NET Code Camp v4 is officially open! Camp is on Saturday March 6th and we will have many tracks and scores of talks for you to choose from as well as food, prizes, and time to socialize and meet with the speakers.

Attendance is free but we have a limited number of seats available on a first-come, first-serve basis.  This event is expected to sell-out quickly so if you'd like to attend please complete your registration now at  http://codecampnyc.eventbrite.com

Technorati Tags:

Bookmark and Share
posted on Wednesday, 10 February 2010 01:39:00 (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
# Tuesday, 09 February 2010

.NET Ninja in training, Peter Bahaa, shows us how to build an AtomPub Endpoint using Telerik OpenAccess entities and the Data Services Wizard beta 1.

Telerik Data Services Wizard Beta1-ATOMPub from Stephen Forte on Vimeo.

Technorati Tags: ,,

Bookmark and Share
posted on Tuesday, 09 February 2010 04:11:38 (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
# Monday, 08 February 2010

On January 22nd 1984, during the 3rd quarter of the Super Bowl, Apple unveiled the Macintosh personal computer for the first time with a masterful TV commercial directed by Ridley Scott. I was only 12 years old at the time and I still remember it, it was that good. Almost 25 years later I studied it in business school, that is how important to Apple this ad was. The ad was a take on the George Orwell classic novel 1984 and is considered Apple’s defining moment. The ad said that Apple arrived and is now part of the game in a big way.

Since then the Super Bowl has been used to create brand awareness and many other companies have tried to put themselves on the map the way Apple did that January in 1984. A few even succeeded, Monster.com is one that comes to mind. Another, pets.com, created such brand awareness for its corporate mascot, that the mascot lived on, even though pets.com went out of business 9 months after its Super Bowl ad.

Google has never spent any money on traditional advertising. Not a single Google ad has ever appeared on TV and to my knowledge, in print media either. They grew to be a multi-billion dollar company by word of mouth. That is why this morning while watching the Super Bowl (it is morning in China) I almost fell out of my chair when the Google ad played.

The ad was perfect.  It was simple and kept your attention by telling a love story. It focused on the core business of Google: search.

While not a masterpiece like 1984, the ad did the job in a very Google way. Since Google is already “on the map” this ad was a signal to Apple (iPhone) and Microsoft (Bing): Watch out, we’re coming! The ad is a signal of the arrival of Google 2.0. The company that grew up on search that is now making phones, browsers, operating systems, and much more.

Well played Google.


Technorati Tags: ,

Bookmark and Share
posted on Monday, 08 February 2010 04:27:49 (Eastern Standard Time, UTC-05:00)  #    Comments [1] Trackback
# Saturday, 06 February 2010

Check out my pre-con at TechEd North America, Joel and I will be speaking on Agile. Register here. :)

PRC07 The Agile Methodology Demystified: Implementing Agile in Your Organization

Track: Development Practices

Speaker(s): Joel Semeniuk, Stephen Forte

Agile project management and development methods are being adopted at many development shops. After an introduction to the basics of Agile and Scrum, including: project planning and estimation, the Scrum Master, team, product owner and burn down, and of course the daily Scrum, certified scrum masters Stephen and Joel show many real-world applications of the methodology drawn from their own experience. Negotiating with the business, estimation, and team dynamics are all discussed as well as how to use Scrum in small organizations, large enterprise environments, and consulting environments. Next we discuss using Scrum with virtual teams and an off-shoring environment. We then take a look at some of the planning tools we will use for Agile Estimation, including planning poker, Microsoft Visual Studio Team Foundation Server 2010, and much more. We dive into some agile developer techniques such as TDD, Continuous Integration, and Dependency Injection, and round out the pre-con with a discussion on Agile developer tools and how they can help (and sometimes hinder) the development process. The speakers have a very interactive style so participation is encouraged and there will be plenty of time for Q&A. This seminar is a jump start for preparing for a scrum master certification.


Technorati Tags:

Bookmark and Share
posted on Saturday, 06 February 2010 03:56:32 (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
# Friday, 05 February 2010

.NET Ninja in training, Peter Bahaa, shows us how to build a WCF Endpoint using Telerik OpenAccess entities and the Data Services Wizard beta 1.

Telerik Data Services Wizard Beta1-REST Collection from Stephen Forte on Vimeo.

Technorati Tags: ,,

posted on Friday, 05 February 2010 07:12:26 (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback