Agile Development versus Agile Delivery

While I’ve been thinking a lot recently about the project Governance, and how Agile fits into the organization’s governance structure, I’ve become to believe more and more that Agile isn’t a software development framework at all really.  Its actually a software DELIVERY framework.

My Product Marketing VP came to me the other day.  “I get Agile” he said.  “I’ve worked with Agile teams before, but what I don’t get here is why I’m being told by Technology that I can’t tell the market what we are delivering in a year.  In all the other places that we’ve worked, the Agile teams have been able to do that.”  I nod wisely, yes I agreed that other companies were saying what they were working on in the future, and were selling stuff that they didn’t have, and yes, I could see that might be frustrating when trying to sell our product.  (sort of, but what idiot would buy$100,000 of software on the basis of what their Sales representative was claiming might come out in a years’ time … but I digress).

There are two possible responses to this type of question (which is extremely common, as it is one of the main objections that Sales and Marketing have to Agile).  The first one goes along the lines of:

I understand where you are coming from, but how many of those other companies will actually deliver what they say, and when they say they will?  Selling those types of futures is difficult for us because we are trying to stay focused on trying to not plan too far ahead, because long range planning isn’t very accurate.  Besides, we don’t even know what it is you are hoping to sell in a year’s time, and so couldn’t possibly tell you when we might be done building it.

This is great, and all very true.  The trouble with this answer is that it leaves the questioner the impression that you don’t want Sales or Marketing to mention next year’s features because you can’t be bothered, or because you don’t like being held accountable (presumably because you are lazy) .  Ultimately all you have really succeeded in communicating to the executive in question is that agile itself is the problem because it is too short term to be suitable for a longer marketing campaign

The second answer is the one that I’ve recently become more conscious of recently.  It goes like this:

I understand what you are saying, but you are thinking of this in the wrong way.  Agile is there specifically to help Product Marketing – the developers aren’t doing all this for their own amusement!  Agile is 100% about shipping the most valuable things to market (or doing the most valuable tasks) as fast as possible.  The trouble is that what is the most important thing changes on a regular basis.  Whether that is because an operational issue crops up which needs to be dealt with immediately, or a request from Sales or Client Support to add a feature to close a deal, or the market changing, requiring different features to be delivered than originally planned.  Agile allows the business to completely change its mind about its priorities at the minimum cost to the business. The business gets to change its mind every development cycle or planning period: whether that be every 2 week iteration, every 6 week cycle, every quarterly release, or every year.

This actually is I think a great answer which explains the true value of Agile in business “outcome” terms, rather than in terms of development.  However in order for it to be truly realizable entails that development  on any particular feature or “unit of marketable value” is completed within the planning period.  If you are to change your mind “completely” at the planning period boundaries, then in order to minimize waste there must be no over-hanging work from period to period.  Such overhanging work represents development momentum – like a supertanker that takes 10 miles to stop, a badly scheduled and scoped backlog will take time to ‘wind up’ to a position where work can be halted, and something else started afresh.

This is the real meaning of ‘shippable software’ at the end of every iteration.  Not only does it needs to be technically shippable (fully tested and done done), but it also needs to be sufficient so that it can be released (value can be extracted from it) so that the business can move on to something else, while not losing the benefit of having done the work.  This is the subject of another post Committing to Value versus Committing to Stories

Another way to look at is, is that regardless of your ‘actual’ development iteration length, the ‘true’ iteration length is the period of time that it takes to develop ‘shippable’ software…(the Agile goal is to reduce that to a short a time as possible!)