Dan Croak: Agile Principles in Practice - Part I: Eliminate waste

This post on "Agile" continues a mini-series on misunderstood terms in technology. Previous terms were the cloud and NoSQL.

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.


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: Today, we’ll cover “Eliminate Waste” with Part II coming next week for delivering and deciding.)


Practice, on the other hand, must always take context into account. I believe there is no such thing as a universal "best practice". There are only practices that work well for your situation.

With that in mind, I'm going to share some examples of Agile, mostly from our experience at thoughtbot. Take these not as a checklist for your situation but as case studies of Agile working in practice.

Eliminate waste

The only thing that matters to customers is a working product, in production, that delivers value to them. Any intermediate artifact is waste from their perspective. Consider some of these waste culprits and ways to eliminate them.

  • Stop tracking time.
    • It's a burden for designers and developers and it doesn't help customers in any way. We unceremoniously stopped tracking our time a few years ago.
  • Wireframes and other prototypes don't matter to customers.
    • They're hard to eliminate, however, because they can help focus design and development. We've tried paper prototypes, HTML mocks with Flutie, and sketching on an iPad. The approach isn't as important as remembering that this phase should not last long. We try to learn what works cheaply on paper then iterate quickly toward working software.
  • Avoid running extra servers.
    • This is becoming easier to eliminate with the advent of the cloud and services like Heroku.
  • Don’t make features customers don't use.
  • Stop waiting for sign-offs (from a product manager, marketing person, QA engineer, etc.)
    • We try to solve this by only having people on staff who make stuff: designers and developers. Our clients have one person responsible for quickly accepting (or rejecting) features we've delivered. That sign-off is probably a waste, though. We, like other Agile shops, like to keep at least one branch of our apps in a deployable state so that it can go to production as soon as it is accepted.
  • Minimize task switching.
    • If you're working on multiple projects or are often interrupted, it can take a while to get back in your groove. Our designers and developers usually work on one project per week rarely more than two projects each week.
  • Avoid unnecessary handoffs.
    • Handoffs are like a hitch in your golf swing: extra motion that doesn't help you hit the ball. How much motion does it take to get a question answered? Not as much if everyone works the same hours (we work roughly bankers' hours) and is available for answering and asking questions without being interrupted (our company is in Campfire all day long). How much motion does it take for wireframes to be shared and understood between client-designer-developer via Basecamp?
  • Eliminate defects that go undetected or unfixed.
    • All software has bugs. What matters is how quickly a team is alerted and can fix the defect. Tools like Hoptoad and New Relic RPM can handle the identification and notification. Humans determine the severity. An Agile team will replicate the defect with a test, watch the test fail, write the fix, watch the test pass, and commit the code to version control. Since the code base has at least one branch of always-deployable code, the fix can go to production immediately if the defect is severe enough.

Stay tuned for Part II – Delivering & Deciding next Tuesday.

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