Grillin' in the Storm

Developer sneaks - who's really controlling the cooking?

Agile development gives a lot of ownership to the developers.  I think this is great thing from a product management point of view.  One of the developers here at NewsGator recently spoke about this as the developer acting as an "independent contractor" and needing to really understand what the "customer acceptance" criteria really was.  For me, that's the perfect mindset - the developer is working to satisfy me (as a proxy for the customer).

I'm not creative enough to make the "sneak" part of this story relate to grilling, but let's look at a hypothetical situation where you've hired an independent contractor to build a deck on your house.  Let's assume you had a rough agreement on what you wanted done, and one day, the contractor said, "By the way, I put a little something extra into your deck."

This is pretty much the equivalent of what I call a "developer sneak".  Now, in most cases, I would prefer to hear about these things before they are done.  But life can move pretty quickly, and developers may prototype something while they are working and get a good result.  So the real question is how to harness the good from this and avoid the bad.

From a product management point of view, I think three things are very important here:

1. Communicate with the team about what is driving the release - if this is a date-driven release, there really is no room for sneaks
2. Always ask "what are the risks" and "what extra testing will be needed" and be willing to say "No" if the answers are not acceptable
3. Be clear about the point in the release where no "sneak" will be accepted

In an agile environment, a lot of trust and a focus on the overall benefit are needed.  I would certainly never want to hear my contractor say, "I added a jacuzzi and a wet bar to your deck and that cost you an extra $20,000."  But it would be great to hear, "I had some no-slip paint, so I went ahead and put some on the steps - no extra charge!"

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.

Deciding what to make - competitors, customers, and product vision

A co-worker sent me this interesting post on the "Featuritis Curve" yesterday.  If I were to boil it down, it seems to present two ideas:

• don't blindly put in features just because competitors have them
• listen to your customers for feature suggestions

This makes sense.  I like to add a couple more principles, and I think there's one slightly flawed assumption in the Featuritis model.  First the extra principles.

Every product needs a vision.  I'm not talking about some sort of product daily affirmation "I'm fun enough, I'm pretty enough, and, gosh darn it, people like to use me".  I'm talking about a vision of how the product provides value to the user.

For example, part of the vision of NewsGator products is synchronization.  Whenever a person reads an article in any NewsGator interface (FeedDemon, NetNewsWire, NewsGator Inbox, our soon to be released mobile clients, our web reader, etc), that article will be marked as read in all interfaces.  That way, the user never has to read the same article twice, and the value to the user is that we are respecting their time and making it more efficient for them. 

There's quite a bit more to the NewsGator product vision, but the point is that having that vision gives something to test feature requests against.  For example, if a customer says that she would like to flag articles in one client and have them show up as flagged in all the other interfaces, that really makes sense when we think about the core value of synchronization and making reading more efficient.  I'm sure you can easily imagine plenty of feature requests that may not align.

The other thing about having a product vision is that it helps to put competitor features in perspective.  It is very easy to look at something that competitors or media are touting and want to add it to the product, but a strong sense of the core value propositions allows assessing those ideas with a more neutral framework.

The minor disagreement that I have with the Featuritis model is that it suggests that more features inevitably lead to greater complexity.  While this is often the case, a lot can be done to flatten this curve out.  For example, the new Office 2007 interface shows a huge number of features.  But every person I've spoken to who has tried the beta for a little while really loves it.  Good user interface design makes a huge difference in the number of features that can be presented.

Agile betas - the early taste tests

A couple of posts ago I mentioned a release criteria that basically said the "software had enough beta exposure".  That sounds good at a high level, but what does it really mean.

In general, the goal of a beta release is to make sure the changes and new functionality in the software work the way they are supposed to in all environments.  No company that creates software which is actually installed on customer computers can simulate every situation their software will face (and even hosted and appliance solutions can face a lot of interesting variations in customer environments).

Some companies run very long beta programs.  Look at Internet Explorer 7 - it recently started it's third beta.  I think the first beta release for this was in July of 2005.  But when you think about the number and variation of systems running IE and some pretty big changes in features, it makes sense.

In general with agile development, the amount of change in a given release is smaller, so the betas can be shorter.  So one of the tricks is to figure out how much shorter they can be.  I usually go through the release list to assess the impact of the changes and then think about how these changes can interact with customer environments.  From this, I decide a list of things I need to see.  For example, if code that talks to proxy servers has changed, I need to see that it works on different proxy configurations (especially ones that I know might be special at key customers.)  I review the list of proxy testing goals with the rest of the team to make sure I haven't missed any cases.

Then we select the target set of beta testers based on the things we need to prove.  An ideal beta tester meets several criteria - they have a good test environment, they are technically savvy, they are motivated to test quickly, and they give good feedback.  In my experience, having a few good beta testers is typically better than having many testers who don't meet some of the criteria.

So then the time comes when you need to decide if the code is ready to release to beta testers.  One of the challenges I've faced (sometimes not so successfully in prior companies) at this stage is that a company can have multiple goals for a beta.  The paragraphs above describe the goals from the point of view of getting quality software released quickly - sometimes there are other business goals that need to be balanced in (more on this in another post).  Generally, our criteria for releasing to beta is that it is feature complete and has no critical defects (bugs that stop the program from functioning or cause data loss).

The type and amount of beta testing guidance (preliminary release notes, known issues, test plans) depends on the goals of the beta, number and types of testers, and readiness level of the software.  In any case, I always find it important to let the testers know that I appreciate their help and give them an easy path to provide their feedback.  At NewsGator, our Support team runs the beta testing in conjunction with our Client Service managers, and they do a really nice job.

The bottom line here is that you never really know how good the grillin' is until someone tastes it.  The beta testers are those trusted souls will tell you quickly and honestly whether it's ready to serve (and usually give you a lot of great feature suggestions in the process).

A screenshot is worth a thousand words (and five minutes of arm-waving)

One of the tools I find most helpful (just below the whiteboard in value) is SnagIt.  Most likely I only scratch the surface of what it can do, but it saves me a ton of time just by allowing me to quickly capture a screen or part of a screen.

For instance, right now I'm playing with, err I mean analyzing, the FeedFlare interface from FeedBurner.  This is nifty tool that allows for a lot of interaction options with a post (both on the site and in the feed).

I like the control for ordering and previewing the different options, so I press PrintScreen, select the area I want, and throw in a comment and an arrow.

I use this for requirements docs, pointing things out to QA or the developers, competitive analysis, and creating product documentation.

What about you?  Have any favorite tools you use in your agile software product management?

It's cooked when everyone says so

Some products allow for agile development where the code is actually released directly to customers at the end of each iteration.  So far, I have not been able to do this with products that are installed in enterprises and need testing on multiple platforms, upgrade validation, etc.  And most enterprises I've dealt with don't want new software installed on site every two weeks.

So while the development and QA teams are flying along churning out progresss and checking things on the white board, there comes a time when you need to decide if the software is ready to go to a customer.

My solution for this is a release checklist.  The idea is that each stakeholder has to agree that the release meets his or her needs.  Any person is free to say "No", and any "No" will veto the release.

The current release checklist for the enterprise product looks something like this:

• PM decisions - Release is feature complete, documentation is complete
• Dev mgr decisions - No showstopper issues, code has remained unmodified for long enough
• QA decision - release has had adequate regression testing
• Support decisions - internal "dogfood" testing successful, beta testing successful, support team has adequate training and info on the release
• Client services - advance customer notifications are complete, client services team has adequate training and info on the release
• Sales - advance channel notifications are complete, sales team has adequate training and info on the release
• Marketing - any required marketing / PR items are complete

The interesting thing about this approach is that it doesn't end up with everyone turning to QA and saying, "Can we ship it?".  Everyone has buy-in and visibility to the release decision without having a huge amount of bureaucracy.

The other cool thing is that one person signs off on each item.  So there's ownership at a detail level.

Lastly, it's nice to be able to run through this as the release is coming to a close and double-check with the smiley-face indicator to see if they both tell the same story.

So how does everyone else decide when their release is cooked and ready to be served?

I know it's cooked by lookin' at it

My wife bought a nifty electronic fork that tells me the internal temperature of things on the grill.  It's a neat device, but at the end of the day, I feel the need to cut open the steak or chicken and look inside to decide if it's ready.

One of the great things about agile development is that you usually know the software is done because you get to see it working.  But while the work is going on, it's nice to have publicly visual indicators that tell me at a glance how things are coming.

In my last post on priorities, I mentioned the "Happy Brian List".  Below is a current example.  I had to smudge out a couple of areas, but hopefully the idea is clear.

Every day when we have our short status meeting (a "scrum"), it's easy to look at this board and see where we are.

Toward the end of a release, attention turns to the other end of the room where the QA team lists any key defects that need to be closed.  And as we get closer to releasing, we use the very high-tech release status indicator shown below.

Originally, I only drew the happy, neutral, and unhappy faces.  But someone on the team added the "arrow through head" status and taped next to it is this picture.

We've never been at "arrow through head" or "scream" status, but it probably helps to have them there to put things in perspective.  The point of having this is that the qualititative assessment of the team is actually a pretty good indicator of release readiness.  And I think it's fairly motivating not to have an unhappy face circled on the board that everyone can see.

So back in my very first post, I mentioned that we use Rally to manage our development.  And underneath the fun of the whiteboard, we are tracking storycards and tasks in Rally.

The online team here at NewsGator has chosen to make their whiteboard actually directly reflect Rally by putting their stories on sticky notes and moving them from column to column as the work progresses.

This is a more traditional scrum approach, and it has great value from a visual point of view as well.  If the cards are moving along smoothly throughout the iteration (the two-week development and test cycle), it is clear on the board.

So what kinds of systems do the rest of you use to visualize the product development process?

The happiness of priorities

First of all thanks for the encouraging comments and a special thanks to Brad Feld for mentioning my fledgling effort here.

It has been rainy the whole day here in Denver, so I haven't even considered firing up the grill.  But as I walked around the office, I saw something that always makes me smile - even on a dreary day like this.

One of our development teams has a white board with two very handy visual indicators (I'll bring in a digital camera on Monday and try to update this post with the image).  One of the indicators is "The Brian Happy List".  It's simply a prioritized list of what I want done.  I have (I think) a good relationship with the team, so the fact that it's my name is pretty much a shared joke.  But the really cool thing is that it makes it clear to everyone what should be worked on.

The other really cool thing is that there are some nice secondary effects to this format.  I can (if I need to) erase or add priorities or move something in the order, but it makes the board messier and it reminds me that shifting gears has a cost for everyone.  Also, the board doesn't get any bigger, so if I were to keep trying to add stuff I would run out of space - and this is a good reminder that the team has a finite capacity.

Also, the board is really visible.  Management, sales, other teams, etc can easily see it when they are walking around.

And finally, the team has made it their own tool.  The other day I noticed checkmarks appearing as developers started marking off things that they had completed.  I'm waiting to see what the QA team does with it.

I'll save the story of the other visual indicator that the team uses for a later post, but just to add a bit of suspense, here is the image that the team members added to that part of the board.

Rainy days and requirements

July 4th was another grillin' day and another thunderstorm.  I'm not superstitious, I'm sure it had nothing to do with starting this blog...

In any case, while I dried off and started munching some corn, my mind drifted to some requirements that I needed to write.  Agile development favors "working software over comprehensive documentation" and "individuals and interactions over processes in tools", so what does that mean with respect to requirements?

In the ideal case, it means that the bare minimum is written down and developers work directly with customers asking questions and refining concepts through conversations and quick sketches on white boards or bar napkins.  My favorite book on this is User Stories Applied by Mike Cohn.  He does a really nice job of explaining a user story as requirement documentation in a sample chapter on his web site.

Many times, the customer is external and cannot work directly with the developers.  This puts a lot more pressure on Product Management to act as an effective proxy for the wishes of the customer.  But the same concept still applies, if you can have lots of direct communication between developers and the "virtual customer", less needs to be written down.  A key part of this concept is that the testers need to be part of these conversations and ideally document the test cases as the decisions are made. 

For more complicated features, however, this can break down pretty quickly because it's just too easy to have a quick conversation that only involves a one or two people and nobody ever documents it.

So the guidelines I try to follow for requirements documentation are basically like this:

• For simple features, I write a one-sentence description of who is doing what in the system for what output.  I will do a verbal review with the testers to make sure they understand.  (Of course, "simple feature" is a judgement call, but the developers usually call me on this if I'm being too casual)
• For more complex features, I tend to write a handful of sentences that describe the major cases that I see and the "must have" capabilities.  I will often talk this through with the developers and testers with some quick sketches on the white board where necessary.
• For the most complex features, I tend to start with a discussion among all the developers and testers to explain the scenario and go through the proposed solution.  The feedback I get here tends to be extremely valuable, and I include that when writing the requirements.  I will typically do a review of those requirements before the work starts and again during the testing.  But it's extremely rare for these requirements to be more than a couple of pages of text and a few sketches I've done in Word or screen shots taken of the existing product with quick annotations.

I've definitely heard my share of "we need more/better requirements", but I've also seen this process work extremely well.  Many times, the developer will implement an idea differently than I envisioned, but the solution is better for the customer, easier to implement, and easier to test. 

So I'd be interested in hearing how everyone else does this. How are you managing requirements in your agile development?

Agile software product management - what's this got to do with grillin?

I love analogies.  One of the best parts of my job is that I get to communicate between different groups and hopefully make things more clear for everyone.  Analogies are a great tool for that (stay tuned for my thoughts on running through the woods with your eyes closed...)

So this weekend as I was attempting to grill some food for my relatives during a thunderstorm, it struck me that this was a pretty good analogy for how I think of agile software product management.

Quite a bit has been written about agile software development.  There are some pretty passionate people on the subject, but the basic principles make sense to me (at least in small companies).  At NewsGator, we use adaptations of the scrum methodology using the Rally management platform.

But not as much has been written about how product management works with these methodologies, so I thought I'd share a few ideas (and mistakes) and this is what brings me to the analogy with grilling.

In a nutshell, I think agile software product management is about responding to change.  You clearly have to have an idea about where you want to go - nothing's gonna be cooked if you don't leave it on the grill for at least a little while.  But the best results come from monitoring feedback and making lots of small adjustments.  From a software point of view, I think that this means trying to break up the longer-term vision into parts that can be delivered incrementally and then learning as much as possible from the feedback on those parts.

I won't guarantee to maintain the whole "grillin" theme throughout this blog, but I look forward to sharing more details and experiences and, most importantly, hearing what you have to say!

P.S.  The storm passed pretty quickly, and the grilling went fine (other than one portabello mushroom that got a little crispy because I didn't notice that the coals under it were especially hot)