Monthly Archives: May 2010

Being Effective, Being Agile

One of the best ways of learning how to do something better is to see what has worked for other people. Recently, two of the podcasts I listen to, which address very different audiences, independently described the importance of a product getting to market early so that data can be collected on the product.

On a recent episode of the Stanford Entrepreneurial Thought Leaders podcast was an interview with Randy Komisar. Mr. Komisar discussed his new book, Getting to Plan B. The idea behind his book is that while a business must come up with a “business plan,” the goal of the initial part of the business should be to validate and adapt based on data collected. He gave a particular example (about 9:30 into the video) of a company he was working with that the “Plan A” called for $9 million, but by doing a cheaper test the company was able to measure that the product was not going to catch on. The company was able to take measurements and then re-asses and redirect its efforts and move on.

Software Engineering Radio recently had an episode on Agile Product Management, in which Roman Pichler discussed the necessity of a minimum marketable product, which is the same basic idea – identify what the absolute minimum set of features necessary to get a product into customers hands, so they can begin to give you feedback and provide information driving future efforts. He gave the example of how the iPhone shipped without the ability to copy or paste – something which did not really affect the marketability of the product that they were able to fix later.

Rather than looking at what “Agile” organizations do, the focus should be on what effective organizations do. Mr. Komisar and Mr. Pichler gave good descriptions of how to be effective – involve customers as early as possible, collect data on the product to drive future iterations – that happen to coincide with being Agile.

Duane’s Algorithm

In the best lecture I ever had, anywhere, which was counter-intuitively in my Computer Architecture class (a good story itself for another day), Professor Duane Bailey (just “Duane”) described a simple algorithm for learning:

  1. Read
  2. Think
  3. Write

I am always trying to get better at this algorithm – being conscious of the algorithm itself as well as doing each step better and better. Anyone who has found this blog may wonder, “why another programming blog, since there are tons out there already?” The primary reason for me starting this blog is that it is the final step in my personal learning process. I’ve been doing writing in different forms over the past few years – scribbling meeting notes on various notepads for work, keeping a professional journal, and keeping a private blog on my company’s intranet. I figured I would try my hand at keeping a public blog, since writing in public forces me to

  1. Write Better – both stylistically and in terms of content
  2. Think in a more directed manner
  3. Be selective in what I read

The focus of this blog will be software engineering, but I may write other things that I find interesting from time to time (my other hobby lately outside of software has been reading about history). Hopefully, someone will find the posts that will follow in the months to come useful.