Grillin' in the Storm

Blog tag - nothing to do with grillin'

Hmmm - my NewsGator co-workers have been bitten by a bug to play blog tag.  And I've been tagged, so I've been struggling to think of five things most people don't know about me.  Here goes:

1. I grew up on the Canadian border with Minnesota and spent a good chunk of time hunting, fishing, and even trapping (yeah - like fox for fur coats).  As a kid living in International Falls, you don't think so much about the right and wrong of this sort of thing, but I'm not too likely to shoot a deer any time soon.
2. I love games.  I was fortunate to live in a fraternity in college with a bunch of other people who also loved creating, playtesting, and playing games.  We ran several multi-party, simultaneous D&D adventures (four dungeon masters coordinating four parties in the same dungeon at the same time - using sticky notes on a big map) and created some real-time - real-space role-playing games, board games, and computer games.  Every year about a dozen of us get together on Labor Day weekend to play board games (and some old-guy basketball where the goal is to not get hurt).  I also play an occassional online game - I'm interested in Vanguard: Saga of Heroes right now.
3. I was a bartender in a Japanese restaurant and a Captain in the US Air Force.  I was a bartender because I was waiting for the Air Force to bring me on active duty after they paid for my college.  I can only remember a couple of phrases in Japanese.  The most memorable is "Nodo ga kawakimashita ka?" - which I think translates roughtly to "Are you thirsty?"
4. I've done martial arts off and on (more off than on) since I was sixteen.  I've never earned a black belt, but I'm working on it now at Vision Quest Kenpo (a really good kenpo school).
5. I have no social life.  I'm having a ton of fun, and I don't think I really want more of a social life (though my wife says it's a good thing and she's usually right).  I don't think I ever spend more than 4 hours per week in contact with people outside of work or family and therefore I only have coworker and family blogs to tag.  So here's a few to tag:

Brian Baker's Newsvine Column, Beaker's Brain, Authentic Giving

Grillin' up a Holiday Gift!

I've got a blog post upcoming where I'll get back on the topic of agile product management, but I just wanted to mention that NewsGator has launched a holiday promotion - get $10 off the purchase of any of our products NetNewsWire, FeedDemon, Inbox, Go! for Windows Mobile, and more.

 

You can see all the great products here.  To take advantage of this, you just type "NGHoliday" in the shopping cart promo field.  When you press Update or Checkout, you'll see your savings!

Happy Holidays,

Brian

Thanksgiving Grillin!

Wow I've really let the grill go cold!  Sorry for the long absence.  The good news is that I have some help to deal with all the cool stuff we've got going on.  So I should be servin' up some more agile product management cookin' on a more regular basis.

I am extremely thankful for all the hard work and success we've had at NewsGator in the last few months, and I've tried to list some of the specific reasons below.  But the thing that got my back into my grilling apron was a meeting I had with our online team a couple days ago.

Agile product development is all about focusing on real value and delivering it as quickly and measurably as possible.  Many times this means we focus on story cards and use cases and velocity.  But on Monday, the dev, qa, and support folks took things to a completely new level.  They wanted to talk about the business.  They wanted to understand the key metrics that determine financial success, and they wanted to measure their progress against those metrics!

I've been in some large organizations where some form of metric focus was pushed down on employees by management.  But it was truly heartening to see this team take ownership and drive their efforts at a higher level!

As I mentioned above, I have many things to be thankful for here at NewsGator.  So to round off this much-delayed re-firing of the grill, I wanted to acknowledge a few efforts.

• The NewsGator Enterprise Team won InfoWorld's RSS Server Shootout
• FeedDemon version 2.1 was released
• We launched the start of beta for NewsGator Enterprise On-Demand (a hosted Enterprise RSS solution)
• We have started the beta for NewsGator Go! for J2ME (a cool mobile reader for Blackberry, Motorola, Nokia, Treo, etc - I wasn't really supposed to announce this yet since the Support folks wanted to wait until Monday...)
• Our partnership with Intel, SixApart, SocialText, Simple Feed, and SpikeSource to deliver the extremely cool SuiteTwo solution was announced.
• And a lot more that I'll need to talk about in another post!

Thanks to everyone who made all this possible.  I'm looking forward to a fantastic holiday season with many more cool announcements on the results of our agile product delivery.

It's the little things

Hmmm...crazy schedules are keeping me from posting as often as I'd like.  Last week, I really wanted to talk about all the cool stuff NewsGator released:  NewsGator Go! mobile reader, NewsGator Desktop Sync, and the new comments feature in our online reader (you can make a free account to try them out).

But the little thing that I've been meaning to talk about is a little TypePad Widget that I prototyped (and then the NewsGator devs fixed!) after a little prompting from Brad Feld.

If you'd like to add your Blogroll to your TypePad blog, it's now just a click of a button (after a little navigating in the NewsGator online reader).  Sign in to the reader and click My Settings in the top navigation, then click Edit Locations, and click the Blogroll link in the top section.

You should see an image like the one below.  After you click the checkbox, you can add your blogroll to your TypePad blog with a click of the button.

Yup - it's a little thing - especially compared to all the other cool stuff we did last week.  But agile development is a lot about doing a bunch of little things really well and really quickly.

Have fun,
Brian

When will dinner be ready? (the joys of estimation)

How long will that take?  It seems like such a straightforward question...

When planning iterations or releases, we always need a sense of time.  For development teams, this can feel like a trap.  If they estimate conservatively, they get accused of sandbagging.  If they estimate aggressively, they get beat up for not meeting their schedule.

Solving this problem breaks down into two parts.  First, you have to take the steady-state cost of maintenance, meetings, etc out of the capacity before you even look at features.  In agile, this is often referred to as setting a velocity for the team.  If you have a 40-hour work week and you estimate a 0.75 velocity, you really only have 30 hours to budget.  From my experience, estimating above 0.8 is very risky.  If you are getting below a velocity of 0.5, it probably means there's something systemic that needs to be addressed (serious product defect, organizational issue, etc).

The second part is actually estimating the work.  Here are the things that I think are most important:

1. Break things down into smaller chunks where possible
2. Have at least two developers estimate the same task when possible - this exposes different assumptions about the work.
3. Force estimates into fairly few categories.  It's really not very helpful to have something estimated at 4.5 hours.  I'd rather have categories like: trivial, half day, full day, three days, five days, and ten days.  If the estimate is in doubt, pick the bigger category.

Sometimes there isn't enough information to make any sort of estimate.  For example, there might not be a known solution to a problem.  In those cases, I think it makes sense to define an investigation task of a finite time to come up with a better estimate.  This could include actual coding, but the main point is that there is a time-capped process on something that is estimatable.  This is often called a spike.

In the end, all of these things don't guarantee accurate estimates.  But they improve the odds.  And combined with other agile practices, they can really help with predicting when dinner is going to make it to the table.

Overcooked and how many courses in a meal?

Two vacations in the same month definitely means I've left a few items on the grill for too long - this blog being one of them.  Sorry about letting it go for a while.

On the plus side, I have a "secrect sauce" idea to share today.  Agile software development suggests frequent releases, but enterprises generally don't like to update software frequently.  So the question of the day is how many releases per year makes sense for an enterprise product?

For very mature enterprise products that are installed on premise, I would suggest that probably once per year is about as often as customers will tolerate.  This depends a lot on the upgrade pain, but that generally seems like a good rule of thumb (plus or minus 3 months).

But startup companies are almost always delivering younger products, so there is a period early in the life of a product that provides the greatest opportunity to evolve it quickly and use agile practices.  As enterprises are in the evaluation and rollout phases, new functionality can be added quite rapidly. 

For our NewsGator Enterprise Server, for example, we have delivered four releases this year.  Now the product is quite mature for its one-year-old age, but we have been able to be extremely responsive to customers and deliver a lot of great functionality (as well as globalize it for delivery via our partners in Japan) by focusing on short cycles.

As the product matures and the installed based continues to grow, the test load increases and, for efficiency purposes, it makes sense to do longer development cycles to balance against the increased testing duration.  At the same time, enterprise customers have rolled out and tend to start prefering less frequent updates.

So the "secret sauce" is to iterate quickly on young products.  Hopefully that makes up a little for leaving the grill unattended for a while.  Talk to you again soon.

Scoping the first version of a new feature - how big of a bite?

Well, the umbrella drinks are gone, so it must be time to get back to work.  On the flight home, I started thinking about some new features going into one of our products. 

One of the interesting challenges with a new feature is knowing how "rich" the feature needs to be before it is released.  In XP (Extreme Programming), the idea is that the customer is sitting with the developer and can say when a feature actually solves the problem.  But usually I act as the proxy for several customers, and new features can be intended for situations the customer has never actually seen.

My general philosophy is to try to solve the key user stories and get the feature to customers to get feedback.  So the trick is separating the critical user stories from the "nice to haves".  A lot of judgement comes into play here, but these are some of the questions to consider when trying to separate the stories:

• How likely is a situation going to be?  How many customers?  How frequently?
• Is there a workaround for it?  How hard is the workaround?
• How far away is the next release of this software?  How likely is it that customers will upgrade?  How much effort will it be to upgrade?

So here's an example that happens with basically every enterprise product - reporting.  One school of thought would be to put no reports into a product and ask customers to query the database.  But if we look at the criteria, the need for reports is very common and the workaround can be a big barrier.  Plus, you give up a big chance to get feedback from customers, and if you change the database, they can be pretty unhappy about the work they've lost.

At the other end, you could put in every reporting bell and whistle on the planet with nifty OLAP functions, extracts, alerts, etc.  But it will take a while to deliver, and most likely, the customers will still need some things that are not included and probably never use some of the bells or whistles.

The agile compromise that I like is to start with some basic reports and listen to what customers like and don't like.  Then iterate quickly to meet their most critical needs.  In the end, smaller bites are much better if you can make sure they are easy to chew and have the tastiness that comes from getting their requests as directly to the chefs as possible.

Umbrella drinks

Sometimes in a startup company you have to slow down to speed up - take a little time to focus on what is really important, plan, prioritize, etc.

This is not one of those time!  Right now, I need to speed up, so I can slow down.  Apologies for the lack of posts recently, but tomorrow I'm taking a few days of vacation.  I'll put together some good blog thoughts on the plane, but for now I'll just leave you with a visual.

Sometimes agile does mean fast cookin'

First of all, we released betas of new Firefox and IE toolbars today!  Beyond auto-detecting feeds and making it really easy to add them, Nick Harris has included some very cool functionality based on our platform.  These versions require the .Net 2.0 platform, but it's well worth installing to try them out.

Second, I thought it would be worth adding some color around Brad's post on the NewsGator blogroll feature.  From my point of view, the story looked like this:

8:58pm - Sitting at my desk responding to the last emails of the day when a new email from Brad shows up.  Hmmm...he's saying we have a cool feature that's hard to find.  I write back an excuse about all the other cool things we're doing and tell him that I am actually planning to write a TypePad Widget to make this easier.

9:16pm - Brad writes back that he's going to blog about this in the next 24 hours...

9:17pm - I go read the developer guidelines for writing a TypePad Widget.  Hey, this really does look as simple as the nice folks from SixApart said...

10:27pm - I proudly send back my Widget code to Brad and go back to getting my real work done

7:42am - I realize I should probably test my Widget (now it probably starts to become obvious why I do Product Management and not things like development or quality assurance...)  Hmmm...there's some problem.  I give our online team a head's up that I've got something brewing and head into meetings

2:38pm - I get some help and realize that I have an invalid API key...hmmm...maybe I should have read the instructions more carefully.  A quick edit and TA DA - working widget!  The folks at SixApart really deserve credit for a super-simple API and, of course, all of the cool Blogroll functionality was actually provided in a single line of code from NewsGator!

So now you can see two Blogrolls over in the right column.  The one with the bold black title is coming from my NewsGator online account - very cool!  And we'll have this available for other TypePad users soon.

Not much of this has to do with Product Management.  And this is another example of unplanned items leading to increases in cumulative flow for our online team (they still need to integrate the Widget code into our site and test it).  But it does represent the spirit of agile in terms of listening to the customer and building something quickly that delivers value. 

We're committed to continuously improving our products through customer feedback.  So back to my first point, try out Nick's cool new toolbars and let us know what you think.

One chef at the grill but hundreds of idea cookers

One of the cool things about startup companies is that everyone can (and should) feel ownership of the products.  It's necessary to have product management to make the final decisions efficiently, but everyone can provide input.

One of the ways I try to encourage this is through internal contests.  Every couple of weeks, I ask people to send me emails with answers to different questions.  The contests have quite a bit of variety.  Sometimes I'll ask people to use specific features in one of the products.  Sometimes I'll ask for stories about how they use something or how they would like it to work.

Right now, I'm running a contest where I'm asking everyone in the company for a completely new use for RSS.  It's amazing!  The ideas are extremely creative, and some of them will make great additions to NewsGator products (or maybe totally new products...hmmm)

The reward for winning a contest is some public recognition and usually a gift certificate (though one winner asked for a cowbell...seriously, and I bought it for him).  It's fun and it really helps drive real-world feedback into the products - which is what I think agile is all about.

So how do you leverage your "idea cookers"?