Microsoft Unveils New Linux Hate Site?

The post Microsoft Unveils New Linux Hate Site, refers to Microsoft’s replacement for their “Get the Facts” site as a “Linux Hate Site”. I saw the same comment on Digg a couple of days ago.

What are these people smoking? Where on that site is there anything “hateful” about Linux. Microsoft is a commercial software organization. They sell operating system software, including some for servers. They consider Linux to be competition. Hence, they have content which compares their products to their competition (Linux, mainframes, etc.). In typical marketing fashion, their site shows that their products are better than the competition. It would be sort of stupid to do otherwise.

How is this different than the marketing efforts of pretty much every other commercial organization in the world?

I also noticed a rant in a comment on Digg about how badly designed the page was, because the person making the comment could not find the so-called “comparison”. I think the tabs along the top point to the comparison pretty clearly, as does the big piece of white text on bright orange background that says “Find out how Windows Server compares to Linux ->”.

The point I am trying to make here is that the Linux community damages its own cause by making meaningless, fact-deprived statements. Stop ranting about MS and do something useful.   

Snipping Tool in Vista

This is a nice post about the Snipping Tool in Vista. I really, really liked the design of the snipping tool that was pat of the Tablet PC Experience Pack on Windows XP. Unfortunately, I cannot show a picture, because I am not running Windows XP anywhere, but the UI while in snipping mode was very nice, with a semi-circular menu docked to the bottom of the sceen with you snipping options.

Oh well – nice post anyway.

But I want to be Disruptive!

I have spent a great deal of time over the last couple of years thinking about the process of innovation, different types of innovation, and how to innovate in a small but established organization versus a startup organization. I was reading Innovator’s Dilemmas: Do You Really Need To Be Disruptive? over on consultaglobal this weekend, and got to comparing some of Jose’s thoughts with work I have done in the last year.

As Jose says in that post, he is more interested in the process of defining a product roadmap in terms of gradual innovation, and in managing product portfolios. We have been very successful with this type of innovation, having a strong product management process for our existing product suite. In my role, I have been more interested in how we do larger scale innovation – how do we come up with the innovations now which are going to drive our growth 2+ years from now?

I have defined an innovation cycle as shown below.

image

Recognizing that disruptive innovation is, well, disruptive, as this cycle is traveled counter-clockwise starting from the upper right, we go from a high-chaos, low-process environment to progressively higher process and lower chaos.

In this model, the upper right quadrant represents what we are really good at, evolutionary innovation driven by product management.  The upper right quadrant represents the starting point – the idea generation engine. This is traditionally a hit and miss process of collecting ideas from various parts of the organization (or just a few people), and trying to pick which ones to invest time and money in. It is my belief that this activity can be wrapped in a process without destroying the creativity needed to really come up with ideas. Among the activities I consider important in this quadrant are:

  • Establish some context for innovation (see this earlier post)
  • Get ideas from everybody, not just R&D or Product Management
  • Get out and talk to customers
  • Involve your staff who are in front of customers, especially professional services people if you have them
  • Engage in structured/facilitated brainstorming with groups from various cross-sections of your company
  • Know how you are going evaluate ideas and decide which ones to investigate more deeply

The last point is important – it is no use having lots of ideas if you have no way to evaluate them. No organization can go deep on all the ideas generated, and a small organization can only really attack a couple. See this earlier post for my thoughts on using the Needs, Approach, Benefits, Competition (NABC) approach. At the end of this stage, and ideas should have a reasonable Needs definition, with a rough indication of the other three categories.

The next quadrant is what I have called Play. This is where ideas which survive the evaluation in the Ideas stage and start to play with them, flesh them out, create prototypes, and generally move the NABC definition forward. Early in this phase, the Approach needs to be clarified, while the Needs are evaluated more deeply.  Later in this stage, if a viable Approach is identified, and the Needs continue to make sense, then the Benefits and Competition need to be addressed (note that in reality, it is never anywhere near this linear, but this is for the benefit of description). By the end of this stage, we should be able to present a fairly strong value proposition for those ideas which have survived the process.

The next stage is to Build the products (ok, probably only one) for which the value proposition seems best. I will not get into the build process, except to say that the NABC analysis should be kept at the forefront throughout the process, and not be afraid to make hard decisions if things stop making sense.

The final stage is the Evolution stage, where the product moves into the incremental, evolutionary development cycle of a completed product. Note that for a new product, there may be some iteration between Build and Evolve.

Finally, the cycle is closed by having ideas from ongoing product evolution feed back into the Ideas stage.

So, is it ever this neat and clean and linear? Well, no. But that does not mean it is not valuable to have a model which you at least pretend you are following!

GigaOM Web Innovators Group: Boston Startups Come Out & Present «

I noticed this over on GigaOM GigaOM Web Innovators Group: Boston Startups Come Out & Present «. I noticed that a company called frevvo. This company was founded by a gorup of people I have worked with in the past. They have some cool technology that is worth checking out (I would describe it, but hey, go look for yourself!)

Why IT Executives aren’t embracing Agile

Wille Faler has written an interesitng post Why IT Executives aren’t embracing Agile, referring in turn to another post on the same subject. Given my background, and my current role, I think I can comment on a technology executive’s opinion of agile processes.

Over the years I have worked on projects using a wide range of processes. Back in the eighties I worked on a team of very bright scientists, writing software primarily for their own use. We had almost no real development process (at best it was managed chaos). This was also one of the most successful software teams of which I have ever been a part. I do not think this is repeatable in most software development environments, because that particular environment had a number of unique characteristics:

  1. Really, Really smart people, especially in the domain in which we were working (satellite control).  
  2. Staff Retention: nobody ever left. When I joined the team, most of the people there had been there, working on the same code for 15+ years. Most had written the original versions of the code, and invented the algorithms.
  3. The developers were the users of the software – eliminating alot of problems of capturing requirements  and expectations. It is pretty hard to have unfulfilled expectations when you are writing software your own software.

Shortly after that, I was was involved in a large military project (10 years, billions of dollars, hundreds of thousands of requirements). Needless to say, we had plenty of process. This was the epitome of the heavy process. Between the company I worked for, and the many subcontracting organizations, I was exposed to many flavours of software process (all of them heavy). I was also involved in ISO 9000 certificatiom programs, CMM assessments, 6-sigma programs and Design for Manufacturability programs (we did hardware, too). One of the things I learned in all of that was that you can have all the process in the world, and still fail. While having a strong software development process (whether it is heavy, agile, or otherwise) may vastly increase your chances of success, it by no mean guarantees it.

In the past 10 years, I have become a great proponent of “just enough process” – trying to take what I have learned from the heavy processes on the military projects, and apply what makes sense in a small, product-oriented environment, while leaving much of the “weight” behind. In the period from about 1998 through 2002 (the last time I directly managed development projects) I was greatly impressed with agile processes. While we never fanatically applied any of the agile methodologies, we did adopt many aspects, such as user stories, iterative incremental development, and test driven development. Some aspect just did not fit our environment (such as pair-programming). We had a fair amount of success using this approach, and many aspects of agile development are still in use.

Getting back to the topic at hand (why IT executives do not embrace Agile processes), from my perspective, agile processes are definitely viable and advantageous in certain contexts. Also, “heavy” processes certainly do not guarantee success. My feeling is that there is a time and place for both kinds of process. As in most things, it is important to have a number of tools at your disposal, and to have the knowledge of when it is appropriate to use these tools. Remember, an idea is a dangerous thing when it is the only one you have (didn’t I use that a couple of days ago?).

For example, I think it is entirely innappropriate to use “heavy” processes in small, commercial product development. Similarly, as an IT executive, I would be extremely hesitant to use an Agile process on a large, complex development project, because I have not seen sufficient evidence of the viability of the approach.

It all comes down to using the right tools in the right situations.

Usability – interesting analysis of WordPress

I just had a look at the results of this interesting usability analysis of WordPress.

While I do not necessarily agree with all of it, it is a very good analysis, and most of it makes sense. The biggest thing I liked in it was the concept of “not getting noticed”. As much as I love slick new UI models, and lots of graphics and animation, in reality the best software in the world is software you do not even think about. As a user, I should be focusing on what I am trying to do, not how I am going to make the software do it. Especially for any activity which requires any level of focus, having to constantly context switch from thinking about your work to thinking about whether the software will let you do it is extremely invasive.

I had not really thought before about the design of WordPress (hey, I started using it because it is free!), but overall it seems pretty good. Goodness knows, if it had done things to annoy me, I would have whined about it on my blog somewhere!

Someone Already Thought of My Idea – Now What?

This post Someone Already Thought of My Idea – Now What? is a few months old, but I just came across it tonight. it makes some very good points about a problem I think many of us have – we want to come up with that brand new, perfect idea, that no one else has ever even dreamed of.

Well, it is probably not going to happen. No matter how smart you are, there are many many people out there as smart or smarter (unless you are that one person out there who actually IS smarter than everybody else – it is not me, so I am not going to worry about it), and it is highly likely that at least one of them will have thought up an idea very similar to yours.

So, what do you do about it? Well, you do not give up for one thing. Just because someone has the same idea you have, does not mean they have the same business you have. There are so many variables, and so many opportunities to innovate every aspect of your approach, that you absolutely can do it better than someone else.

Ultimately, it comes down to execution. Given two people/organizations with the same idea, the one that executes better has a much higher likelihood to win. Note that no matter how good your execution or anything else, there are no guarantees – you can do everything right, make no mistakes, and still lose (I think Picard said that on STNG – kind of sad that I am quoting Star Trek wisdom!).

I will make an analogy with football (I frequently do – and I mean American football, not soccer). Both teams in a football game have the same objectives, often have very similar levels of talent, are on the same field with the same playing conditions, and really have pretty much all the same tools and strategies available to them. More often than not, the team that wins is the team that executes the best on game day – executes on the fundamentals, and does not do things to hurt themselves.

Much the same holds true in starting a business, and when you find out someone else has had the same idea as you, you only have two choices: execute better than them, or leave the field and find a new game.

Brainstorming is a bad idea? (again)

It is amazing how a single post by the right person can stir up so much commentary. The latest I have read is One head is better than two or more. As Patricia pointed out in a comment to my previous post on this, The Medici Effect author also goes on to say:

“So, should we all stop brainstorming? I don’t think so. Done right, brainstorming is a highly effective way to actively generate intersectional ideas.”

Brainstorming, like any other human-centric activity, needs a process. Throwing a bunch of people into a room and saying “create brilliant ideas” is not an effective process. To me, this is analagous to putting a bunch of programmers in a room with no process and saying “create a wonderful product” (though admittedly, I have seen a fair number of companies try to do software development this way!). Similarly, badly run, pointless meetings with no clear purpose, and no process, do indeed make us collectively dumber.

Anyone who has ever been on an over-acheiving team (work, sports, or otherwise) knows from experience that the right team, working together with an effective process, can achieve things that none of the individuals could come close to working seperately.

Undertaking any group activity, whether brainstorming, software development, or running a business with no process or a bad process will indeed frequently lead to the result that working alone is more productive and more satisfying than working in a group. Does that mean you stop the activity? No, it means you fix the process.

Brainstorming is a bad idea?

Looking at the quote on Marc Andreessen’s blog post Why brainstorming is a bad idea, I am forced to concede to the evidence presented, even though I am a big fan of group brainstorming. I wonder, though, if similar studies/experiments have been performed using what I refer to as “structured brainstorming”, meaning (to me) group brainstorming using tools/techniques/games designed to drive idea generation? I wonder if the results would differ?