Wednesday, December 27, 2006

Entrepreneurship and Insubordination

Robert Nardelli is quoted as saying "there's only a fine line between entrepreneurship and insubordination". I found this gem in the Oct 2006 issue of Harvard Business Review, in an article by David Garvin and Lynne Levesque. I'll leave the details to your reading pleasure, but there were a few key points that resonate with me, regarding how to innovate within a corporation.

First, quite a bit of innovation is going to lack data, and what you do have is likely to be ambiguous. Another quote: "it's hard to find marketplace insights for markets that don't exist"; this is the innovator's dilemma. You need "Mavericks" that can cope with that ambiguity and drive the organization forward anyway. You'll need to attach them to seasoned operational experts to help them design experiments that validate or negate hypotheses, and change course accordingly. This totally makes sense and seems to bypass a lot of risk and leverages the strengths of the umbrella corporation.

A perhaps counter-intuitive recommendation in the article is to "learn from small samples" rather than statistically significant large focus group learning. Highly successful examples include Intuit's "Follow Me Home" program, where employees actually watch customers use Intuit's products in their natural environment. Nokia, P&G, and Starbucks have similar programs which are leading to new sights.

The article also talks about skills acquisition and building. This is a variant of the build or buy decision, in this case whether you build the team internally or borrow or acquire a team with the right skills already in place. This is a critical decision but generally can be made by evaluating whether you have the competence to grow the needed skills, how critical it is to have the skills on board, and how long it will take to develop those skills.

Sunday, September 17, 2006

Sirens' call: Agile

I consider myself an early adopter; I am usually the first to try new things. When it comes to Agile software development, however, I have pretty much waited until it entered the mainstream. We are there now. Large, respectable companies are moving to some form of Agile. They had to. It is clear that what we have been doing hasn't led, in general, to higher quality, predictability, efficiency and effectiveness. The systems are too complex and the world is changing too quickly.

One of the reasons I didn't adopt right away, is that Agile seemed like a step in the wrong direction, for the wrong reasons. If you haven't seen the Agile Manifesto, check it out at

The first principle I struggle with is "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." The statement is true, and frankly, is the reason developers love Agile. Many developers I have worked with view documentation as a non-value-add activity. My aversion to this principle is that it ignores a huge problem in software development, which is keeping maintenance costs and quality under control. One of my clients had over 5 million lines of code and no idea how it worked. The people who created it had left the organization. The reasons why things had been done certain ways were lost. Adding anything which required change to the base code was a recipe for unquantifiable risk to the entire release, and many hours debugging under stressful conditions. I'm sure you developers out there will say that documentation is best buried in the code. The problem with that argument is that only developers will read it; and if I may say so, despite their technical prowess, I have seen some incredible oversights committed by developers (including myself).

The second principle I struggle with is that we should "welcome changing requirements, even late in development". It is clear that requirements do change and will change and we must adapt. But I fear that without attention to detail in requirements, people will be lazy about thinking things through, and any organization which behaves that way will waste inordinate amounts of energy refactoring.

Now that I've shown my negativity towards the principles, let me state that I think Agile brings a lot to the table. The number one thing it brings in my opinion has nothing to do with efficiency; it is risk management. In an out-of-control Agile environment, you may have the artist's problem - "it will be done when it's done, and I can't tell you when that is". Assuming you don't have that environment, then you have planned what you need and when you need it to meet your customer's requirements. Using Agile, you define mini-releases along the way to get there. Each mini release could actually solve the customer's challenge in some useful way. Now, if something ends up harder than you planned, and it will, you still have something to ship. You still have goals, you still have a sense of urgency.

My point is this: if you approach this as a potential efficiency drain to create the extra releases, but know that in return you have a ship date that you have confidence in, as well as feedback along the way about how "done" you really are, then delivering "working software frequently" is totally worth it.