Throw away the crystal ball

Almost everyone has acknowledged that long term project estimation needs to be a thing of the past.  If you are still doing waterfall development where you are trying to estimate projects 9 months or a year in the future, I’m sorry.  You are stuck in a pointless time loop.  It’s time we call these long term plans what they really are, guesses.  Why is a long term plan a guess?  In that period of time, things will change.  That is a guarantee.   Your customers’ needs will change.  The technologies you are building with will change.  Market forces will change.  You may be able to predict some of these changes but why would you want to?  Predictions are guesses.  You’re much better off setting yourself up to adapt to change.  If you can roll with the punches, chances are you will exit the ring standing up.

This is why agile development has become so widely accepted.  The core premise behind agile is that it allows a company to embrace change rather than fight it.  Conversely, this is why a lot of anachronistic big companies struggle so much to innovate.  When they take the waterfall approach and finally release product, the product they release would have been relevant a year ago (or two years depending on how late it was) but is not relevant today.

The onset of AgileFall

Even most big companies have started to recognize that waterfall is not getting the job done.  They have seen the studies.  They know they are losing more and more to innovators.  So, they decide to give the whole agile thing a try.  But, they don’t go all in.  It’s like watching Grandma adopt a cellphone.  Sure, she figures out how to use it, but she never picks the damn thing up when you call her.  Even worse, she leaves it sitting on the kitchen counter anytime she goes somewhere.  Might as well leave it plugged into the wall.

There’s many reasons why companies struggle with committing to agile.  Many of these reasons are good ones, at least to management.  Here’s the big three I’ve heard again and again:

1. The folks on top don’t get it and aren’t that interested in learning
2. ‘My enterprise customers will never take releases more than once a year’
3. We need the time to build buzz and marketing campaigns around the upcoming release

For those of you that came out of the gate with SaaS, count your blessings.  You’ve never had to deal with this crap and probably never will.  For those of you with legacy code bases or working for larger companies, this is most likely the norm.

Break big things into smaller things and ship the smaller things

You’re chances of going from annual releases to releasing every day or every sprint are effectively zero.  Your best bet to get to real agile is by doing it piecemeal.  Treat it like any other engineering problem: break the big problem into smaller ones.  If you are doing annual releases, shift to quarterly releases.

This step by step approach allows you to combat the three most common pushbacks.  Convincing the folks on top that this is the way to go becomes a hell of a lot easier once you start hitting dates.  The logic here is sound and easy to manage up: if we’re doing less, there is less risk and less change.  Therefore, our predictability will increase dramatically.  If you take this approach, make damn sure you hit your dates or watch it all blow up in your face.  More on that in another post.

Another bit of ammo to use in convincing those at the top is the well-known project failure.  Take your pick, there’s a mighty graveyard of failed projects at your fingertips.  Keep it topical.  I’m in Colorado so it was easy for me to reference DIA (Denver International Airport) which opened sixteen months late at a cost overrun of $2 billion.  Talk about your big project failure.  If you’re on the east coast, use the Big Dig.  The argument becomes even stronger if you can reference a similar, smaller project success.  For us, this was the second round of the light rail once Denver’s Union Station was completed.  They didn’t try to launch it with all lines opening at once.  Instead, they first launched the train to the plane.  Then they started opening up another line every quarter.  To my knowledge, they haven’t missed a date.  Each successful line opened is another feather in the cap that builds trust.

As for enterprise customers not taking releases more than once a year, this is not a tough argument either.  Make sure that these customers don’t HAVE to take each quarterly release.  If they still want to take just one release a year, fine, let them take every fourth release.  The trick to this approach is in making sure that each release builds on the previous one and you are using only one code line.  The minute you break into multiple code lines, you’re done.  The support nightmares will take down your company.

Somewhat surprisingly, your sales and marketing teams will quickly become your allies.  With the quarterly release cycle, you’ve now given them a lot more to do and a lot more to talk about.  This is again only true if you hit your dates.  You miss your date once, they may forgive you but more than once and the trust is most likely permanently broken.  This happens and folks lose faith in the product and you can wave goodbye to your best sales folks.

Do it once and doing it again is a LOT easier

Once you successfully switch over to a quarterly release, a monthly release is the next logical step.  If you had any success in the quarterly release cycle, the monthly release cycle is a much easier conversation.  You have already established yourself as an expert.  Chances are your value to the company at this point is pretty high and you don’t have to convince the folks up top.

Where the battle gets more interesting here is with sales, marketing and your deployment teams.  They’re going to feel overwhelmed.  Those teams that cheered you on when you hit your quarterly releases will turn on you.  Take a minute to put yourself in their shoes.  All of a sudden they have to constantly learn new features.   I can hear all of you SaaSers giggling but keep in mind that these folks came from annual releases.  Many of them have never experienced things like quick feedback from their customers and pivots based off of that feedback.  This is a sea change that requires their roles to change.  That’s scary.

The pain of this transition can be eased by making the first two monthly releases of the quarter ‘internal’.  You still cut a build and move on to the next one but you don’t actually ship it.  This gives you time to continue building trust around the monthly release.  It gives them time to come to grips with how their roles need to change.  They are now selling and marketing an ever-evolving product instead of incremental releases.   It also allows your deployment teams the time to turn into devOps teams.  It takes time to make those process changes.

Once the other teams have become comfortable with monthly release cycles, moving to releasing every sprint is a very easy step.  Now you’re doing agile!