Grillin' in the Storm

The disappearing calendar

I've had a few blog posts floating through my head for months - and now a business trip gives me an opportunity to let them float through the pipes of the internet.

A lot of agile methodology is around estimating and working in small increments to drive better predictability of delivery date.  I've teneded to find that as a product gets more mature and installed at more customer locations, it takes a longer period of time to close out a release.  The agile planning helps with the earlier phases, but at the end we need a little bit different planning and monitoring tool.

Whiteboard to the rescue!  As we get near the end of a release cycle, I often draw a calendar on a whiteboard.  I usually draw this in front of the whole team, and I draw the weekends on the calendar as well.  Then I grab an eraser and wipe off all the Saturdays and Sundays.  Then I erase any holidays or company events.  Then I ask the team where to mark the milestones like truly feature complete, feature testing complete, and regression testing complete.  Each day after that at the scrum, I erase the previous day.

I think this exercise does a couple interesting things.  First, the concept of "weeks" can sound like a lot - as in "oh, I'm sure we'll be done with that in a couple weeks".  When you draw the calendar and erase the non-working days, you're now looking at an exact number of boxes.  Second, when you start putting marks on this calendar, you see how close together things really are.  If you say you're feature complete on Tuesday and you say that you'll be done feature testing by Friday, it's clear there's only two boxes between those days.  Hopefully feature testing has been going on during the development iterations, but having the calendar illustrates the margin of error.

Lastly, erasing the days helps illustrate the sense of urgency.  The calendar is getting physically smaller on the whiteboard which should raise some questions about whether there's enough boxes left.

Here's hoping your calendar has all the days you need!

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!

Grillin' Social Sites at microwave speed

I'm not a patient person by nature despite the "immersion learning" lessons from my kids.  Grilling is one of the few activities around food where I actually invest a little time.  Most working days, I toss a frozen lunch in the microwave between meetings and eat at my desk - and that's the pace I really want software development to follow.   Thunk, slam, beep, beep, beep, grab a soda, ding - eat!

This sort of attention-deficit life pacing makes agile development really appealing for me.  But with enterprise software, sometimes it can take a little longer than that.

Not so with the NewsGator Social Sites release that we announced today.  We started this effort two months ago.  In enterprise software development pacing that's the equivalent of having the food cooked before you can close the door on the microwave!

A lot of hard work went into making this possible.  The team had tremendous focus (and has a ton of talent of course).  From an agile product management point of view, the two biggest tools for this release were a couple of powerpoints and the whiteboard.  The real key, of course, was that there was a lot of timely, focused communication. 

Ashley (enterprise product mgt) and I had lots of quick meetings looking over a developers shoulder at a screen.  We pointed, asked questions, and drew pictures on the whiteboard.  We talked through tradeoffs, demo'd the prototype versions to key folks along the way, and used the software on our internal SharePoint server for almost the full time we were developing.

It's pretty rare that even the best of agile practices can produce this much great functionality with high quality in this short of a time period.  And while some releases are best grilled slowly, this was one was just perfect out of the microwave!   

Agile widget grillin'

The Syndication Services group at NewsGator is really great example of the power of customer involvement and rapid iteration.  They work so quickly and in such close partnership with customers, that they don't have any product management resource assigned for the widget production.

But they do have a lot of product management experience in the people who guide the team, and that lets them make decisions quickly.  And they have very skillful account managers who make sure expectations are understood and communication happens quickly (along with very strong support staff who back everything up.)  EDIT:  Just realized that I probably didn't make it clear enough in this paragraph that it is the very experienced and talented development and QA folks who are the linchpin to getting the widgets built quickly, correctly, and beautifully.  I probably should have shortened this whole thing to say that this is an excellent team!

The end result is really cool!  Yesterday, the new travel widgets for USA Today were released!  These are sexy widgets built in Flash that allow USA Today to be the first national newspaper to make content available in detachable widgets.  I have travel news on my Facebook profile page now!

At the same time, the Associate Press wrote a great story about the trend of newspapers toward widgets.

The point of all this from an agile product management point of view is that when customer communication is great, iterations are really rapid, the team is really skilled and experienced, and the scope of the work is not huge, product management is not really necessary.  I'd love to have some claim to the credit for their great work, but the Syndication Services team churns out awesome, customer-pleaseing widgets all by themselves!

If you'd like to see some of the other cool widgets this very agile team has produced, you can just hop over to http://www.newsgatorwidgets.com/

Grillin' with NewsFriends

Today we launched NewsFriends - a free social news application for Facebook.  It's a cool application that lets you choose friends to get your news.  The idea is that some of your friends are likely to hunt down cool news, blogs, video feeds, podcasts, etc and you can just benefit from everything they add.

Launching a Facebook application is tricky, and we sure learned some things today.  But I've already found two cool new feeds from Jennifer and Zoe!

The reason for this post, however, is to bring up an agile development point.  The vision for NewsFriends when it started out was quite a bit different than how it looks today.  In effect, everyone who worked on the project acted as a customer to give input into how the application should work.  It wasn't quite as simple as having a single customer to say "yes" or "no" to a feature, but some of the best parts of NewsFriends came from the two developers - Brad and Noel - talking through how they wanted it to work.

Now that it's released into the wild, NewsFriends will be driven by a larger number of customers.  But I think the first version is a pretty good testament to how well ownership and dialog can shape an application.

If you want to give it a try, just go to the NewsFriends information page to learn more and add it to your Facebook profile.

Priority and time

The kids got me a gas grill for Father's Day, so I've been getting in more grillin' lately.

Last night we had an impromptu gathering, so I fired up the grill.  I have a bad habit of overcooking things, so this time I decided to give the actual grilling more attention (priority).  But as is often the case for me, I had lots of other things to do and I ended up not managing the cooking time very well.

This got me thinking about how we manage some teams here.  Many times here, we have so much going on that we just focus on managing priority.  We keep a list of tasks or projects from most important to least important, when someone finishes a task they look for the next available task in priority order.

On the teams where we use this, it tends to work great.  But often you can't predict the time something will be available without having some more specific controls.  So typically, we have additional milestones that we use to drive things to a little more predictable schedules - loads of our online services, demo days, etc.  These teams basically don't work in fixed sprints but have weekly priority reviews and daily scrums.

It's not perfect, but I have to admit it's more accurate than my grilling time management :) 

Anybody else use a hybrid method like this?

Have fun,

Brian

P.S.  Anybody want some slightly charred beef?

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

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.