Dan Croak: Agile Principles in Practice - Part 3: Decide as Late as Possible

Why Agile?

We want to make software that is valuable for people cheaply and efficiently. Ideally, the process is also pleasant for the participants.

 
Agile development achieves that goal. Agile teams build stuff customers want. They do it faster with fewer wasted cycles. Developers have more fun and write cleaner code. They do it at a constant pace that can be sustained forever.

Principles

The Agile Manifesto kicked off the movement with some lofty phrases like "people over processes". It proposes that we value "working software", "customer collaboration", and "responding to change" over some other stuff.

Sounds good, if a little vague. Getting a little more specific, the following subset of principles offered by the Poppendiecks in Lean Software Development are a helpful grouping:

1. Eliminate waste (click to read)
2. Deliver as fast as possible (click to read)
3. Decide as late as possible (Today)

Principles are meant to be universal. The above list should apply to the software team of any entrepreneur reading this. (Editor’s Note: this is the 3rd and final part of Dan Croak's series on Agile)

Decide as late as possible

There are some decisions that cost a lot to change later. For example, say you build a web app using ASP.NET, launch it, then can't find any developer who wants to maintain it. Switching to another technology (such as Ruby on Rails) at this point would be very expensive since the whole app would need to be re-written.

However, most decisions are not like that. The cost to change most software decisions later is actually very low.

With that fear gone, consider what happens when you delay decisions until the last responsible moment...

We refuse to look at big, detailed requirements documents before a project starts.

•  Some organizations write RFPs that are over 100 pages and include thousands of feature requests and a detailed schedule over the course of two years. Those are doomed software projects.

 Instead, we ask the startup founder about their product vision and together we form a rough outline of iterations.

• We schedule weekly iterations that begin Monday and end Friday. The week has a theme (for example, in a safety application, "safety inspectors can report violations"). On Monday morning, features from customers in the form of user stories are estimated (1, 2, 4, or 8 points) and prioritized by importance to users and the business. We have more information at the start of each iteration than the startup founder did weeks or months ago, so it is now the last responsible moment to determine what to work on. In this way, we strive to always be working on the highest priority item.

The same principle applies to designing.

•  A problem some people have with Agile is that it encourages working from the customer's perspective first, which means designing the interface before writing any code. That means that developers are waiting (a form of waste) for a part of the project to complete, which is in conflict with a major distinguishing factor of Agile: avoiding sequential steps for concurrent ones whenever possible.

•  Instead of designing all the details up front, however, Agile designers can make a "fuzzy" interface that allows the developers to get going while the designers clarify the details, which will only become clearer to them as working software emerges and users start providing feedback.

This may seem abstract so let's examine one legendary tale of "deciding as late as possible" from the field: the Github Rock Queue.

Many modern web apps push a great deal of processing work "into the background". While users are clicking buttons and commanding the app to do things, the heavy lifting of generating image thumbnails, sending emails, calculating analytics, building graphs of friendships, etc. are done in background queues.

The concept of a queue is the same no matter the specific library you use. Github set themselves for flexibility by abstracting the concept of a queue behind a small bit of code they called their Rock Queue. Their applications always code against the Rock Queue, leaving them free to try a half a dozen different implementations (DelayedJob, ActiveMQ, SQS, and others).

Conclusion: how it feels

An Agile project does not feel fast. It feels steady. It's not like driving a Ferrari 100mph through the Nevada desert to get to Vegas. It's like a farmer tending his field of crops... one day he's driving a plough steadily up and down the rows, another he's steadily spraying to fight against bugs... and anything he can figure out to do concurrently will be a productivity boost (for example, modern tractors till the soil, plant the seeds, and turn the soil over the seeds all in one pass). Each day has a rhythm and depending on the season (and therefore the state of the crop), there's a different thing that takes the highest priority each day.

So... go grow something.

Further reading

If you're interested in learning more, check out these great books or others by Martin Fowler, Dave Thomas, Kent Beck, Mike Cohn, or Ward Cunningham.

• Extreme Programming Explained by Kent Beck
• User Stories Applied by Mike Cohn
• Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck
• Practices of an Agile Developer

Dan Croak is a web developer at thoughtbot. He makes apps for Boston web startups. Email him at dcroak[at]thoughtbot[dot]com.