TechStars held a very enlightening information session at Andala Cafe this morning. Shawn Broderick did an excellent job conveying what TechStars is all about and what a TechStars startup looks like. Some other people involved with TechStars provided insight as well.

While I didn’t take notes directly (standing room only), here are a few, quick takeaways I gathered. I think these thoughts go beyond TechStars and really speak towards general entrepreneurship.

It’s about the team first, and the product second

Great ideas without a team to execute on it is about as useful as a car without an engine. Find enthusiastic, passionate people you like working with – you’re going to be spending a lot of time together. Refine the idea together. I’ve heard this quite a bit – investors weigh the team’s capability and dynamic heavily, perhaps even more than the product idea.

It’s common for the product’s vision to change

It’s common for the idea of your product to morph into something different. Perhaps the distribution channel won’t work, or the revenue model needs to be tweaked. Embrace these changes as your product matures and you learn more about your audience and yourselves.

Moonlighters need not apply

The expectation is that you’ll be dedicated to the business and present in the program. If you’re thinking you can work on this in your “free time”, you should have a lot of it! Just like split focus hinders daily productivity, split career focus can definitely hinder the progress of your business. In fact, most TechStars companies had prototypes or initial funding prior to entering the program.

Being a solo founder is difficult

It’s hard to do it alone, and TechStars recognizes that. If you’re a solo founder and you want to apply, recognize the problem and identify the resources you need to make your business a success. Seek those resources out actively. Personally, it was a clear message that I need to make connections with more entrepreneurs.

Apply or Start It Up anyway

Shawn said something really great towards the end of it. I’m paraphrasing, but he basically said the only thing definite is that if you don’t apply, you won’t get in. Don’t talk yourself out of applying – take the time to do it and see what happens. Even if you don’t get in, at least it was a good exercise in thinking about your business.

Even if your business fails, you’ll become a stronger and more experienced entrepreneur in result. Personally, I believe the largest asset of being a TechStars company is the access to those that have tried, failed, and succeeded in traveling on the roads you’re approaching.

One tenet of Getting Things Done is to always have a tool that you can use to capture thoughts and actions as they pop into your head. I get crazy ideas in the oddest places and times, so it’s important to have a tool at my disposal to quickly capture them. I always have my cell phone on me, so it’s a natural choice for a capture tool. I needed a service that I could dial into and leave a message which would be then transcribed and in my inbox when I returned to my computer. For a long time, I’ve been using Jott, but Google Voice has taken over as my tool of choice for capturing next actions and ideas.

Why the switch to Google Voice?

1. It’s free
2. It’s easily accessible – In addition to a great web client, GV has a great Blackberry application.
3. Better transcription quality – I’ve found the quality of voice transcription to be better. That means less corrections to make for me when adding actions to my GTD system.

Set up your Google Voice Account for Getting Things Done

1. Add your cell phone to your list of contacts if it’s not already present

   

2. Edit your google voice settings for the contact you just created. Select “Send to Voice Mail”

   

3. If this is a phone that you’ve connected to the account, you’ll need to navigate to settings and then the phone tab. Click edit and then show advance settings. Set voicemail direct access to “no”. Be sure to save your changes.

   

Calling your new capture tool for the first time

1. Dial your google voice number
2. Press 1 to go directly to voicemail once it starts ringing
3. Leave a message

Setting up more automation

• If you have a GMail account, you can set up filters to have a specific inbox for captured voicemails
• If you use Remember the Milk, You could also set up a rule to automatically forward the email notification to your inbox there.

Google Voice has become a vital part of my GTD workflow. Even if you’re on a low tech system like an excellent Moleskine, using Google Voice as a capture tool when you’re on the road is a safe and free alternative.

Last night I spoke @ Boston.rb about everything that happens around code.

Lately, I’ve been heavily interested in discussing the process behind software development. Our field is still very young, and I think there’s a lot we can do to improve the way in which we do our jobs.

Slides are below. I described the talk this way: We spend so much time focusing on conventional programming. Everyone focuses on standards, code clarity, testing, and what gems to use. Let’s chat about what’s done before your fingers hit the keys. Let’s talk about brainstorming, requirements, stakeholders, mock-ups, and writing solid user stories and acceptance tests with Cucumber. Every project has a story – how will your next one end?

If you attended the talk, I would love your feedback at SpeakerRate

SCRUM is a great framework to adopt if you and your software development team wants to get things done. SCRUM works for us, so we encourage the people we work with to adopt it along with other Agile methods.

Here’s a few reasons why we like it:

• SCRUM can get you the highest business value in the shortest amount of time, assuming your priorities are right.
• It makes the release of your software less of a technical problem and more of a business decision
• It helps to project the amount of value your development team can deliver over a finite period of time
• It helps keep your development team and your product flexible so that it can change with the long-term needs of the business

We try to help all of our clients refine their product development process, so we’ve seen a few roadblocks that get in their way when adopting SCRUM. These are the top 5 ways to cause a SCRUM misfire:

1. Too Much, Too Soon

   Traditional development shops sometimes try to change their ways overnight. If you overwhelm developers with sweeping changes, it’s unlikely that everything will stick. There are many aspects to SCRUM and Agile, so why not take it one step at a time? First, you could start writing user stories. Second, you could start time-boxing your release plan. You can spread out the adoption and sell each facet of SCRUM on its own merit. Being a curmudgeon myself, I respond to change much better when it is spread out over time.

2. Being dogmatic and following the procedures to the letter

   SCRUM is a framework, not a dogma. It annoys me to no end when people criticize others for not having an “up to the letter” implementation of SCRUM. If you’re not changing your ways from iteration to iteration, you’re missing a lot of the benefit that SCRUM provides. During your retrospective, discuss what’s working and what isn’t. Change your ways for the next iteration, and see if things improve. Every company’s culture and operations are different, so why should you try to fit a round peg into a square hole? Bend SCRUM to your team’s will, and find what works for your organization.

   That being said, a lot of people think SCRUM is about having an open floor plan or rapidly changing requirements and development priorities without forethought. If you do only these things, you’re not practicing SCRUM or reaping any of its benefits.

3. No executive buy-in

   We’re getting warmer. It is so important to have C-level support for the long-term adoption of SCRUM and Agile methods. Take considerable time and effort with getting your executive team on board. When you miss your last few stories in a sprint (it will happen), your management team needs to understand the complexity and uncertainty around sprint planning, and how you already have a plan in place to address it.

4. A Bad Product Owner

   I’ve unfortunately seen this more times than I’d like to admit. Bad product owners mean bad user stories and priorities, which translates to sprints that miss the mark in terms of business value. Naturally, if stakeholders and board members aren’t seeing the results you’ve been promising, SCRUM will be forgotten as quickly as what they had for lunch two weeks ago. In the early stages of trying SCRUM out, work with your product owner intensively to make sure he or she is doing a good job of getting the right stories and priorities from stakeholders. If they can’t get make it work within a few sprints, you’ve got to respond quickly and find someone else to fulfill this important role.

5. Split Focus

   So you’ve got this great idea for implementing a framework where you can demonstrate predictable and reasonable estimates of what your team can do in a given slot of time. Your team members, though, are on about 4 different project teams and have their quarterly TPS reports due somewhere towards the end of the sprint. In my opinion, resources that are spread across multiple projects is the #1 cause of SCRUM death in an organization. Fight for your resources! If you can’t get a predictable and dedicated amount of time from your SCRUM team, how can you get can you accurately gauge velocity? If everyone has to work on multiple projects (which is a horrible idea), see if you can get them for dedicated times for every sprint. This will be really hard to do as the project priorities shift and fires need to be put out, so this should be a last resort. If you have some pull in the company, see if you can try restructuring project teams to be more dedicated. Nothing is more important for the successful adoption of SCRUM than protecting your team from distractions and the ever popular “Can you do me a favor?”. As a technical leader or someone that wants to see your product and SCRUM succeed, this is the battle you want to pick.

Are you struggling to get SCRUM working for you? What’s killing the adoption of SCRUM in your organization? We’d love to hear from you in the comments.

Are you looking for a web wrapper for the Amazon Advertising API for your Ruby on Rails Application? ramazon_advertising is a library that provides this. It supports request signing.

The Amazon Advertising API allows you to retrieve Amazon catalog data and use it in your application. It can be really handy if you’re participating in the Amazon Associate’s Program

There are a few users of Amazon Associate that might want to know that I’m deprecating the library in favor of ramazon_advertising. Amazon Associate was an older library that I was maintaining. It uses HPricot and really doesn’t jive well from a design standpoint, so amazon_associate is deprecated in favor of ramazon_advertising

Ramazon Advertising uses John Nunemaker’s awesome library happymapper along with nokogiri selectors. It’s much more object oriented and cleaner, so I hope you’ll enjoy using this library.

Right now, it supports product data acquisition via the ItemLookup request. Here’s a simple example where you can find the product data for a given asin:

@products = Ramazon::Product.find(:item_id => "B000NU2CY4", :response_group => "Medium")
@products[0].title
@products[0].asin
@products[0].upc
@products[0].large_image.url
@products[0].url
#you can also use a nokogiri search string to get elements that don't have built-in accessors
@products[0].get("ItemAttributes Actor").collect{|a| a.content}

The ruby gem is available on Gemcutter and the documentation is available at rdoc.info. Patches and feature requests are welcomed!