small medium large xlarge

Way of the Agile Warrior

The Way of the Spartan Warrior

by Jonathan Rasmusson

Generic image illustrating the article
  Jonathan explains the benefits of startin’ Spartan.  

There’s more to successful projects than time and money, but if you ask the people with the money, they’ll tell you that time matters a lot.

In this column I am going to show you one sure-fire way to quickly figure out how realistic your budget and schedule are and how to reset expectations like a pro when you need to.

How Much Can You Afford?

One of the great strengths of agile development is the leeway you get in building any given feature or story.


You can build it cheap. You can give your customer something with just a few bells and whistles. Or you can build them the Taj Mahal if they want that.

This looseness around high-level stories gives customers a lot of flexibility when making decisions about features. They can go light on user interface spit and polish if they are building a back-office invoicing system. Or they can invest heavily in look and feel for the tablet application insurance adjusters are going to be taking with them to into the field.

The challenge for you (and your customer) is to get a sense of how much they can afford right at the start of the project. We’d all like the deluxe version of whatever it is we are building, but not at the expense of the budget or the schedule. As Steve Jobs likes to remind us, “Artists ship.”

To help our customers figure out this balance, we need a way of quickly confirming that we

  • have enough time and money to build the system they want, and

  • have a sense of how much they can afford in terms of bells and whistles that would improve the product and experience.

One way to get there is to start Spartan.

The Way of the Spartan Warrior

The Spartan Way is built around one really simple, common-sense premise: If we can’t build the Ford Focus version of the system with the time and money we’ve got, there’s no way we can build the BMW.

So the way we figure out what we can afford is to build a few bare-bones core features, measure how long that takes, and then take a fresh look at the plan and see how realistic things are looking.


Once you can see clearly that the current plan doesn’t support the scope of what’s on your plate, having this conversation with your customer is much easier.

“Yes, we’d like to build the world’s greatest automated invoicing system, too. It’s just that we can’t get the bare functionality in place (much less any of these other whizbang features you’re asking for) with this schedule and timeline—we’ve tried!”

No wishful thinking. No guessing. The truth is self-evident.

This is really the crux of agile planning. We don’t know when we are going to be done until we build something of value, measure how long that takes, and then update our plans accordingly. I realize that some people (i.e., executives) don’t like hearing this, but this is the reality of software delivery. All we are doing here is eliminating as much schedule risk as we can up front, giving them a heads-up early on about how things are looking.

What to Do if the Plan Is Wrong

If the the plan is wrong, we have two options for bringing reality back into the fold:

  1. We can reduce scope (recommended).

  2. Or we can flex on the date.

Reducing scope is how agile developers prefer to keep their commitments and avoid the pain that comes from asking for more time and money.

There is always going to be more to do than the time and money allow (that’s just the reality of any interesting project). And if we keep adding features we’ll never ship anything.

So when given the choice we’d rather fix our dates and flex on scope.


If, however, there is a core set of bare-bone features that just have to be delivered as a whole, we can commit to delivering that core set of features. We just have to be a little flexible on the date.


Even in this scenario we will still need to flex on scope a bit (because new things are always going to come up). But we can go in with the understanding that these high-level core features need to be there and that we are going to ship as soon as these are done.


Pushing out the date a little is OK, but it’s not a good habit to get into. For one thing, it’s just too easy. Secondly, it puts your project in danger of delivering no value. Until you get it into production you haven’t an ounce of value, and agile hates that.


So if you suspect that your project has some scheduling challenges, try building a few spartan core features, see how long that takes, and update your plan to reflect that reality. If things are going well, swell. Keep on truckin’.

Otherwise, work with your customer to set them up for success by either reducing scope or suggesting they be prepared to wiggle a bit on dates.

Doing this early will enable you to have this conversation with conviction in an open and honest way. And your customer will appreciate knowing the facts at the start of the project instead of near the end.

Jonathan Rasmusson is the author of The Agile Samurai. As an experienced entrepreneur and former agile coach for ThoughtWorks, Jonathan has consulted internationally, helping others find better ways to work and play together. When not coaching his sons’ hockey teams or cycling to work in the throes of a Canadian winter, Jonathan can be found sharing his experiences with agile delivery methods at his blog, The Agile Warrior. For more information on the Agile Inception Deck check out The Agile Samurai.

Send the author your feedback or discuss the article in the magazine forum.