Dan Croak: Agile Principles in Practice - Part 2: Deliver as Fast 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
2. Deliver as fast as possible
3. Decide as late as possible

Principles are meant to be universal. The above list should apply to the software team of any entrepreneur reading this. (Editor’s Note: Last week we covered “Part I: Eliminate Waste.”)

 

 

Deliver as fast as possible

The second major principle, "deliver as fast as possible", isn't feasible without first eliminating waste. The last major principle, "decide as late as possible", isn't feasible without speed.

So how do we get fast?

I believe it starts with a compelling vision of the product. When no one understands the product vision, there's nothing to work toward. When everyone understands the vision, the front-line people are able to make good decisions without asking anyone.

 

This is one way Tokyo kicked Detroit's butt in the 80s. Automakers like Toyota and Honda had their front-line workers make critical decisions without sending questions up the management chain. While GM generated waste in the form of handoffs up and down the management chain, customers waited for a product.

 

In web apps, front-line workers like designers and developers have the best (most frequent) information with which to make decisions. "It will be more pleasant for customers if we submitted this form using Ajax, then briefly flashed a yellow indicator."

Reducing Time

Queueing theory says there are two ways to reduce cycle time in the queue:

• influence how work arrives in the queue
• influence how it is processed through the queue

Think for a second about how work arrives in a "restaurant queue"... most people want to eat between 6-9pm on Saturday night. If the restaurant is empty from 4-6pm and 9-11pm, the restaurant isn't maximizing their night. So, you see restaurants offer early bird specials to spread out demand of diners throughout the night.

 

In an ideal world, each web app's work queue would contain only customer requests. This is sometimes called market pull or "demand pull".

 

In the software world, the only time I've seen that go smoothly is when people build software for themselves.

 

Now think about the last time you stood in line at the bank or the post office and how it was processed... was it one line of people that then broke off to multiple tellers? Entering a concert venue, getting a rental car or going through airport security, and waiting in line for Space Mountain at Disneyworld work similarly... one line of people that then break off through multiple turnstiles or X-ray machines.

 

 

 

Handling it in software...

• The direct parallel to software development is a queue of unassigned user stories that each designer or developer grabs when they're ready for it. We currently use a combination of Pivotal Tracker and Basecamp to manage the story and design queues.
• Academics (MISTER Scientist!) also tell us that small things flow through a pipeline quicker than big things. Every user story in our clients' backlogs have an estimate of 1, 2, 4, or 8 points, which translate roughly to hours in a day. Any feature we can't build in one day is considered too large and is broken down into smaller pieces. 

• The last great customer-facing speed hack is to design and develop for an immediate customer, not future hopeful customers. This not only cuts your time to market down but increases quality by focusing on meeting just one kind of person's needs.

• A developer-facing speed hack I don't hear the Agile world talking about is code reviews. No, I'm not talking about calling a meeting at the end of the iteration where people fall asleep as the group reads the commit log. I'm talking about as new code is pushed into version control, getting another designer or developer to review it before it's merged into the main codebase. This amplifies learning across the team and increases quality. This increases speed because it decreases future defects and handoffs by catching problems earlier and answering people's future questions before they have them.

Lastly, I'll call out three practices for moving fast that are as close to requirements as any practice in this post:

• Version control (for example, git)

• Test-Driven Development (TDD)

• Continuous Integration (CI)

These are so integral to any Agile team that I'll leave them mostly as an exercise to ask your development team about. Have them show you their CI build or git log. If they can't, they should pause everything they're doing and set it up immediately.
 
The reason those three things are so important to speed is that they let developers work without fear of losing work or breaking old features when writing new features. Which leads to the last part: Decide as late as possible...which you'll hear about in the final part, Part III next week.

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