Agile Means "No End Game"

I've seen a lot of places maintaining their own flavors of "agile" (or, more specifically, their own flavors of SCRUM).  And this is good, agile is all about self-organizing teams and finding what works for you.  You should develop your own flavor.  Well... To an extent...

The most prominent barrier I see is adoption at every level of the business.  How many proponents of agile have given their pitch, presented the benefits, even attached precious numbers and values to the whole thing, only to be met with the same question:  "That sounds great.  So when can I have my finished system?  8 months?  10?  What will it cost?"

Something was lost in the exchange.  There are a couple of problems with the response:

1. When you can have it is up to how you steer priorities.
2. There's no such thing as a "finished system."

The first one is the more obvious of the two.  When can you have it?  We don't know.  That's the point, really.  Even if we were to estimate and plan the whole thing up front, we couldn't give you an accurate number.  It might be wildly high, in which case you'll waste time and money on something you could have had sooner.  Or it could be wildly low, in which case you'll burn out your team and end up with an inferior product.  Right now, before any discovery has been done, is the worst possible time to make such an estimate.

This is the basic paradigm of agile.  You're not getting work done faster; You're not getting work done better; You're trading one piece of control for another.  You're gaining the ability to quickly and easily change direction and adapt to new discoveries, and you're giving up the long-term planning to get this ability.

Of course, you don't want to give up anything.  You're a CFO, you want numbers.  This is going to go on a budget sheet and be locked away in a cabinet somewhere and, well, forgotten.  You demand these numbers.  But... did you ever really get these numbers in the first place?  How much do you value wildly inaccurate guesses?   Why is it so critical to write down a number that you're willing to do it at the worst possible point in the project?  Wouldn't you rather have more control of the number going forward?

It requires a change in how you want to handle those numbers.  We can't tell you with certainty that you're going to need to give us $1.6M for an 8-month project.  What we can tell you with certainty is that, if you can allocate $200K per month as a budget, we can begin work immediately.  With each passing month (hell, with each passing week) you'll have more information presented to you about the status of the project.  We could get $200K into it and realize it's going to be a lot more, or even a lot less.  You'll have feedback much sooner and can adjust and steer accordingly.

This begins to touch upon the second item above.  The lack of an end game for the system.  Now our budget is periodic, not absolute.  You can adjust it at will, even cut it entirely, and the team will respond accordingly.  Want to cut it down to $100K per month?  No problem.  You'll get half the velocity out of the team.  It's not the end of the world (though it could mean the end of a job for team members, so standard turnaround cautions apply), it just means that you're turning down a knob somewhere to get less throughput from an ongoing process.

It makes sense from the perspective of software itself.  We all know that the real costs are not in development, they're in support.  That ongoing $200K per month isn't going to go to waste after the initial production release.  In fact, if your plan is to bring in a team temporarily, have them build a system and release it to production, and then send them on their merry way... Get ready to spend a lot of money.  Software does indeed rot, sir.

If, on the other hand, you maintain an ongoing budget for the team in general, support and upgrades will just be a standard part of that budget.  Bug fixes, new features, etc.  And, as I said before, you can tweak that budget without a problem.  Even cut it entirely (if you decide, as a business, that you want to cut support for your software entirely).

Because there is no end game.  Software doesn't stop.  It's never complete.  It's an ongoing cycle (assuming your business genuinely relies on this product, of course, and it's not just a temporary scaffold that will be thrown away after you've used it).  Unless you plan on your business coming to a stop, don't plan on the software which supports your business coming to a stop.

The amount of money you spend on your enterprise software can fluctuate.  And, again, it can even dry up entirely in a dire enough situation.  But the point is that it's a periodic cost, not an absolute one.  Your big $1.8M project that's planned from the beginning is going to cost you a lot more than $1.8M, you just don't know it yet.  Which means you haven't planned for it yet.  That additional cost won't come out until after the project is "done."  Operational costs, IT costs... it'll all be there.

"You don't know that yet" is, in fact, exactly the point we're trying to relate to you in this pitch.  We don't know things yet either.  So, rather than make up numbers, we're proposing a paradigm shift in how we manage uncertainty.  Instead of pretending that we do know, let's assume that we don't know and plan our approach accordingly.  To adjust for this uncertainty, we build agility into the process.  So that as soon as we do know something, we can immediately react.  As a whole team.  As an entire enterprise.

"Agile" isn't just something the developers do.  It's something the corporate culture adopts.  And it either adopts it wholly or not at all.