Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

The goal of every sprint should be to create something that gives the business a sense of perspective, a frame of reference to use to direct future activities. What you deliver needs to work, at least in some respect or with some limitations, in order to offer the business that sense of perspective. If what you deliver can not be seen by the business, it adds no value.

“But it adds value to the development effort!” you might be thinking. Sure, assuming that your understanding of the direction that you need to go is correct.

Note that you are not simply taking a traditional development project and breaking it into 2-week chunks of work. You are creating a functional piece of software. It is all too easy to fall into the trap of breaking things down functionally, and then trying to map your functional decomposition into a backlog. Too often, you end up with pieces which can not stand alone, which do not deliver value to the business. The business can’t prioritize those kinds of things.

The problem is diving too deep. It’s so easy to do, too. You want to understand the problem, so you divide and clarify, divide and clarify, and at some point you magically and invisibly have gone beyond what you are trying to accomplish and have transitioned into the how of accomplishing it.

Therein is the secret of making sure your backlog includes only items that add value: They only tell you what it must do for the business, it does not specify how it is done. Review every user story, and ask yourself: “Is this telling me what the system needs to do, or is it telling me how the system works?” If it is the latter, change it to be the former. If you can’t, then you probably broke down the functionality too far, and that story needs to be rolled into another one that it supports.

It takes discipline, and maybe even a shift in ways of thinking, but you need to deliver something that “works” every time. It may be a mock-up or a prototype, it may not do everything it needs to do when initially delivered, but it is something that the business can see and wrap their brains around. The purpose of this is to empower the business to give their guidance sooner rather than later, and save everyone the frustration of wasted effort.

“But isn’t a prototype a waste of time?” Not really. Build it right and you can simply refactor it as necessary to make it into what it needs to be. And in the worst case, if you have to throw the whole thing away, you still ended up with valuable understanding of the problem, and that all-important frame of reference for the business to guide forward progress.

So, deliver working software. But deliver it often. Very often. Here’s why:

• If you have a term paper due in six months, what is the likelihood that you will finish it tomorrow? What is the likelihood that you will do the bulk of the work the night before it is due? The longer the sprint length, the more this tendency might rear its ugly head.
• The bigger the sprint backlog, the more overwhelming it can feel, whether there is any reason for it or not. So, the longer the sprint, the bigger the sprint backlog, the harder it is to focus, for some people.
• The shorter the duration, the sooner the business can give its feedback, the more Agile you become.

1. quick and well-coordinated in movement; lithe: an agile leap.
2. active; lively: an agile person.
3. marked by an ability to think quickly; mentally acute or aware: She’s 95 and still very agile.

No plan can make it unscathed from concept to implementation.  No matter how meticulous the planning, by the time you can get it half implemented, half of what you built will be irrelevant, and there will be things you never thought of that are more important than anything you planned to build.  Reality in the software development business is the continuous attempt to hit a moving target.

The playing field is never static.  Business needs change.  Technology is continuously evolving.  “Agile” software development is a way of working that recognizes the inevitability of change, and embraces and readily adapts to it.

The difference between Agile and more traditional development methods (such as Waterfall) lies in the speed with which they facilitate adapting to change.  Through deliberately planning out only enough work to get through the next few weeks, and by revisiting the priority of upcoming work on a regular basis, changes to the playing field can be adapted to quickly, and in stride.

It’s simple, in principle.  But old habits die hard.  Truly Agile development is a paradigm shift, a complete change in thinking as well as methodology.  Attempts to adopt the methodology without understanding the reasons behind them will be frustrating at least, and may not reap all the rewards that it promises.  If you are going to adopt the methodology, invest in the people who will be exercising it.  Get them the training they need to be successful.  It will pay for itself before the end of your first Agile project.