Grillin' in the Storm

Free products = grillin' in the tornado

As you may have already seen, NewsGator announced today that all client products are free.  At the same time, we released new versions of NetNewsWire, FeedDemon, NewsGator Inbox, and NewsGator Go! for Windows Mobile.  Though we didn't make any noise in the press release about it, we also released an update to our online reader and several important changes to our API's at the same time.  There's more detailed information in the FAQ.

So here's the agile product management thought on this:  OMG!

As is typical here at NewsGator, there wasn't a ton of time between when we decided to do this and when we made it happen.  In a big command and control environment, someone would have built a giant project plan.  That probably would have taken a week just by itself.

Instead, we gathered the first stakeholders with the riskiest changes and had a chat about it.  Then everyone took ownership of their own piece - the client developers, the platform team, the platform team, the online reader team, marketing, support, etc.  We looked for the critical items that one group would need to complete for another group and those were the only things that we put on the calendar (such as it was).  The group of all stakeholders only met about three times.

This just can't happen without tons of maturity and ownership by the people involved.  But that's what makes Agile, and NewsGator, really work.

OpenSocial Grilling

Sometimes when the grill gets really hot, you just have to move the food quickly without necessarily having a complete plan. 

Last week, Google announced the OpenSocial APIs.  We had been working for about four weeks on this, and the application evolved tremendously during that time.  For contrast, here's my original mockup that we used to discuss the use case and features:

So in about one month, we went from a rough concept (with a pretty ugly mockup) to really nice application.  Along the way, we did lots of iteration and even some very basic UI and concept testing.

From a product management point of view, we didn't bother building detailed iterations.  The team was small, and the API information from Google was very sparse in the beginning.  We basically just set a goal of having the primary features working by the middle of October so that we could spend the end of the month focusing on integrating the API's.

As it turned out, that plan worked pretty well because the API's ended up being a fair bit different than we guessed.  Iteration planning definitely has a place, but it is important to recognize situations where there isn't enough information to make a plan of any value.

Here's what the "canvas page" view of Didja Hear!? looked like on Friday when OpenSocial was announced:

 

So where does that leave us now that Google has made their announcement?  As you might have guessed, a lot is still changing.  So the team is still working to a list of top priorities and adapting to the changes in APIs.

This is about as agile as product development gets, and we're staying on top of this by chatting and drawing sketches about new issues and use cases. 

For now, the grill is so hot we've just got to focus on making sure nothing gets burned while keeping an eye on how and when this gets served up for everyone to enjoy!

More whiteboard grillin'

[Insert interesting excuse here about why I have not been blogging :)  ]

A few weeks ago, we were reworking some of the login flow to our online reader at the same time we were changing the overall site design.  Since there are lots of login paths and rules, this is the kind of thing that can end up being a multi-page requirements document in non-agile approaches.

But I only had about seven minutes to get the requirements done (okay, I actually had days to get the requirements done, but I was doing other work - so I only had seven minutes on the day when I actually decided to do something).

So I printed out the relevant pages in the web site, taped them to the whiteboard, and grabbed a marker.  The result looked like this:

The team chatted about it for 10 minutes, pointed out some things I missed, did the work, and tested it.  And it worked!

I have a few more cool stories like this, so hopefully I'll actually get them written up here.  I'm going to try sharing my posts on Facebook, so if you want to add me as a friend, you should be able to see them in my notes.

Have fun,
Brian

Re-igniting the grill

If you've been reading this blog for a while, I'm amazed at your patience waiting for the next post that has anything to do with agile software product management.  It would be silly to say I've been busy - everyone on the planet is busy (although we are running nine different software betas right now...).  The real truth is that I've been holding off to write about something in particular.

Today we launched our beta of our new online reader!  The technology is super cool (both the parts you can easily see and some secret sauce under the hood).  But the part that excites me the most is the team ownership. 

Some agile development proponents are adamant about specific rules (XP's 40-hour work week) or specific terms (it's a "scrum" not a "status meeting"), but I think ownership is the most important part of any good software development.  So the agile product management trick is - who owns what?

When I met with the online team a little while ago, we talked about overall goals for our consumer business and then we decided as a team how we were best going to achieve those goals.  One of those goals was to make the reader much, much faster. 

As we've worked on the reader over the past weeks, the online team has had ownership of how we would make the reader faster and when they would complete each part of the work.  I have had ownership of the business decisions about what we would specifically deliver.  There has been a ton of great collaboration, and the lines between those areas blur.  But when push comes to shove, everyone knows what they own - and the team has delivered.

So what's the right division of ownership?  I think it varies greatly.  We have products where my only role is to help clear roadblocks and facilitate communication for the real owners and other products where I take a much more detailed role.  At the end of the day, I hope everyone feels like they own something really important, because they do.  NewsGator could never deliver all the truly amazing things that it does with this relatively small staff if everyone did not feel ownership and deliver against it.

So please take a look at the new reader beta.  You'll need a NewsGator online account, but you can get one for free!  Then just point your browser at:

http://www.newsgator.com/ngs/subscriber/beta.aspx

You'll be asked to sign in if you aren't already, and then just click the "Try the beta reader now!" button.

We still have some cool features to add that will make your reading experience faster, easier, and better.  You can check out the release notes on the main page and the tips to see some of the current high points.  Personally, I'm having a lot of fun watching YouTube videos inline.

As always, we value your feedback, so please let us know any issues, things that you love, or things that you would prefer to work differently on our forum:

http://www.newsgator.com/FORUM/Forum52-1.aspx

Thanks again to our online team for taking ownership of this!

P.S.  Stay close to the grill - I have some more good stuff cookin

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.

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"?

Cookin' when the grill is full - the challenge of managing iterations

I find moments in grilling when (even if it's not raining), there's just too much going on to make everything come out just the way I want.  I know the corn takes longer to cook and typically won't burn if it's wrapped in foil and put around the edge of the grill, but getting everything else on and off and flipped and basted and having it all get done around the same time can be a real challenge.

Iterations can be like this.  The theory of an iteration is that the development team selects a set of tasks (or stories) that they can complete and test within the timeframe (here an iteration is typically a two-week period).  The challenge comes the tightness of the cylces, difficulty of estimation, and additions or interruptions.

When a team is working in two-week chunks, time is tight.  On the end of the first day of the iteration, the team needs to know basically what they are going to be doing for the remaining nine days.  This means that some significant planning needs to be done before the iteration begins.  Today, for example, I'm building the "proposal" for two different teams and next iterations.  I'll run these through review with stakeholders, so that by tomorrow I can review it with dev managers for adjustments before the teams plan on Monday. 

To make these proposals, I need to know how things are going in the current iteration which still has 20% of it's time remaining (it won't finish until end of day tomorrow).  Now if every iteration always completed exactly the way we proposed it at the start, this would be easy.  But just like that hot dog that gets wedged in the grill, things tend to come up that throw off the plan a little.

One of the most common of these challenges is estimation.  Since we work with lightweight requirements on rapidly changing projects, it can be pretty challenging to determine how long something will take.  I think task estimation is worth a blog by itself, but the bottom line is that there is always some error in estimates.

The second issue is that change is the only certainty in planning.  Even in two-week periods, priorities can shift or new items can come up.  Some approaches to agile say that no change can be accepted once the team makes their commitment for the iteration, but our teams are more flexible (thanks folks!).  The diagram below shows part of a cumulative flow diagram where new work was added (the bar got taller) and then some work was removed (or the estimate revised) to bring it back down to about where it was.

The good news is that the yellow portion (the completed work) was constantly growing during this period and the blue portion (the work in progress) stayed pretty constant, so the changes in scope weren't too disruptive to productivity.  Not all teams can work this way - thanks again folks!  (And thanks to Rally for the cool graphs in their product.)

The general principle in agile is to estimate a "velocity" for the team to take into account things like interruptions, but this is also a guess.

So the bottom line is that managing iterations depends a lot on doing some reasonable work before it starts, making the best possible estimations quickly, and minimizing the changes and disruptions to the extent possible.  Without this, it's like dumping 100 items on the grill and flipping like crazy with the hope of good results.