Skip to content

Elevator Speech: Part 2 of 9: On Time…

October 18, 2011

In my first post I started out by sharing what I call my “elevator speech”. It is short, sweet, to the point, and the gestalt of what makes me and the organizations that I have gone on to lead tick:

Deliver high quality solutions on time that are innovative, delight customers, win reviews, and disrupt competitors; all while having fun, being ethical and transforming the business.

It also dissected the first part of this: “deliver high quality solutions… It covered deliver, high quality, and solutions. Now let’s talk about what many development managers and teams hate to talk about and that is “on time”…

There is a word in the English vocabulary that many technical teams in the software industry loath and that is the word “predictability”. Because software is an abstract thing that we cannot touch, feel, nor see as we create it we often cringe when we are asked by the business “When will it be done?” We’ve even created methodologies like Agile to avoid the question entirely by saying “We’ll be done with the current chunk of work at the end of this sprint and you can ship that if you decide it has enough merit.”

Truth be told no major commercial software effort was ever completed in just a two to three week sprint. Often it requires a series of sprints, each adding incremental value, but not being a finished product until a number of capabilities came together in to a larger package.

So why do technical managers and their teams need predictability? The business needs it. The business has to be able to coordinate all of its departments and business activities around the launch of your solution. Yes, the technology is a required component, but in many cases up to six months of lead time is required to create sales channels, partnerships, train other departments to be operationally ready, market the solution, drive sales pipeline, etc. Budgets and even entire business plans hinge around the ability of the development team to hit its commitments.

What happens when software development teams are not predictable and don’t hit their dates? Just ask somebody in the game industry: If you don’t ship in September you cannot launch in October; if you cannot launch in October you missed the Christmas buying season; if you missed this window you’ve lost the opportunity to generate in excess of 90% of your yearly revenues; if miss your revenue targets by 90% the company may end up padlocking the doors. Game over…

So where does Agile fit in to this? You cannot have predictably without visibility and Agile provides you visibility like no other methodology. With every iteration you have measurable progress and are able to adjust plans accordingly. With other methodologies you end up going “dark” for months at a time. Going dark ruins your ability to be predictable as you cannot tell how much progress you are truly making nor can you make timely course corrections as required to get back on track. Agile also “keeps the Jell-O stable.” I once heard that developing software is like trying to deploy Jell-O; it continuously wiggles and for that one brief second it quits wiggling you had better push it in to production. With Agile you know that with the end of each iteration you have something that is pretty much “stable” or very close to it.

If by this point you still don’t care about predictability consider this: with predictability also comes credibility. Credibility in this industry is earned and it is earned by shipping high quality products on time. It is as simple as that. The reality of the situation is that no technical manager or team has any credibility without predictability. Without predictability you haven’t earned the credibility required for the business to consider your input beyond simple technical recommendations. Even then, if you have lousy predictability, your technical recommendations will be challenged as the business doesn’t trust you. As technologists we always ask to be included at the strategic table with the business; it just isn’t going to happen until you are predictable and thus credible.

At the end of the day it doesn’t matter how hard you or your teams work, how creative and innovative your solutions are, or fill-in-the-blank-here if you are not predictable. Activity should never be confused as being the same as delivering real results.

Well that’s it for now. Thanks for getting to the bottom of another rather long post. Part 3 will dissect the next part of my elevator speech: that are innovative

Advertisements

From → Agile, Software

6 Comments
  1. bretttr permalink

    I love the jello reference Mark, good stuff 🙂

  2. This line is potent: ‘Activity should never be confused as being the same as delivering real results.’
    Love it!

Trackbacks & Pingbacks

  1. Elevator Speech: Part 7 of 9: Have Fun… « markslawler
  2. Elevator Speech: Part 8 of 9: Being Ethical… « markslawler
  3. Elevator Speech: Part 9 of 9: While Transforming the Business… « markslawler
  4. Demystifying Agile: Rants of a Madman – Estimating Efforts « markslawler

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: