Marcato

What happens when you wait too long to ship?  What happens when you go through a dreaded multi-month hardening phase?

We know the benefits of shipping early and often, but it is useful to revisit the pain that occurs when you don’t.

If you don’t ship often, your organization won’t develop the “muscle memory” of going through the ship cycle.  It will be a complete fire drill every time it happens.  When you finally do ship, the rapid response needed to satisfy your long-delayed customers won’t be natural for the org at all.  You’ll need that rapid response, though, because the long ship cycle virtually ensures that there has been a disconnect between customer expectations and the delivered code.

If you don’t ship often, the errors in the assumptions you’ve made have far longer to compound – leading to really big errors in the delivered product.  (All models/assumptions are approximations of the real world your software will live in – but when you ship often, you get more chances to correct.)

If you don’t ship often, you’ll likely talk yourself into maintaining multiple branches of source code that are extremely unwieldy to merge.  Merge hell will be frequent and de-stabilizing.

If you go through a multi-month hardening phase (because you haven’t created the testing infrastructure to avoid it), your organization will assume that is what is “always” required.  The cost of that hardening phase will weigh on project members in a way that causes everyone to grow increasingly conservative about making any future change at all – no matter how badly it’s needed.

Convinced yet? 

The longest any organization will comfortably wait for you to ship something is 4 months – ship at or more often than that rate and you’ll be a hero.  In the long run, ship rate wins out over scope every time – and even if that’s not universally true, the perception will be that you ship more product.

The easiest thing in the world is to "not ship" – we’ve never shipped a perfect product, as we’re always reminded when we decide to ship.  We all have fear, uncertainty and doubt about whether the product will meet the needs of our customers, so we find it easier to keep building to meet the needs of the mythical future market rather than find out with the customers we can have today just how close we are.  In the end, the best reason to ship is simple – because you said you would.

We’ve been doing (and will be doing) some talks around the Twin Cities on Microsoft’s “AppFabric Caching” technology – a distributed cache not unlike the open-source memcached library.

What has this to do with agile?  Well, we’ve found that it can address a core component of agile teams – the desirability of being self-sufficient and avoiding the bottleneck of scarce experts. 

Let me explain: For projects/products that reach sufficient scale, when a database is present, it becomes the bottleneck for performance.  This often leads to the need for That Guy With Awesome SQL Chops to come to the rescue.  After sufficient time/energy/dollars, your application is performant – but you may have had some intermediate pain, and the data layer (including stored procedures) may have taken a hit in terms of maintainability.  You may now need an expert to touch that code in the future.

For some classes of data, however, a good caching solution can eliminate all that.  A cache that can scale to large volumes of data (by being distributed across a cluster of machines) and yet presents itself as a unified cache logically (so that you have a single place to invalidate cache items) will allow you to tackle a broader class of problems than simple per-node caches.

So, if your team has a good caching solution in the tool belt, you’ll be more agile – able to reach greater scalability while staying self-sufficient.

You can catch this talk on May 20th (Microsoft’s Connected System User Group) or June 8th (Twin Cities Developer Guild.)  Slides are available here.

The Cabin - Potato Lake, WI

A couple weeks back I had the chance to present our use of Microsoft’s Team Foundation Server for managing our Agile development process at Kardia.  As part of this session, we also had presentations on Version One and Rally from other users, and in summary it seemed that while the other tools offer an easier to learn implementation of Agile through a user interface designed to support the natural workflows, TFS shines in providing the most complete “out of the box” Agile life-cycle management tool.  It comes with version control, continuous build, defect tracking, and test case planning, execution, and tracking all linked together to provide traceability from end to end.

For more info on what we did and why, check out the presentation below:

SEG TFS Presentation