In part 2, I explained how we’re breaking down our work into tight, four-day-long iterations, but I didn’t get into what everyone is doing during the cycle.

It goes a little something like this: The design team sketches designs of the software that the development team will build during the following iteration, which will be tested by the consumer insights team during the iteration following that one.

The design team applies insights from testing to new and redesigned sketches, which will be implemented by the development team in a later iteration, which will be tested by the consumer insights team… you get the picture.

Design, develop, test, repeat!

In action it looks like this (slightly modified) schedule of our past three weeks:

Iteration 4 Iteration 5 Iteration 6
Design Short form comments
Comments by your friends
Letters to the editor
Facebook info
Q&A ratings
User comments and following
Comments on Facebook
Letters to the editor ratings
Develop Q&A
Facebook Connect
Short form comments
Comments by your friends
Letters to the editor
Facebook info
Q&A ratings
Test Is Facebook good for them?
Facebook Connect
Short form comments
Comments by your friends
IMG_3605.JPG by nautical2k

IMG_3605.JPG by nautical2k

The benefits of a small vessel

By working in a tight cycle like this, we’ve been able to very quickly create testable, demoable work each week, while remaining flexible to changes in our feature list.

For example, this past week we’ve learned more about the requirements and terms-of-use for Facebook Connect applications.  If we were working with set-in-stone-up-front designs, we’d be scrambling to correct our course.  Instead, we’re just tacking as the winds change.

In part 1, I wrote a bit about the origins of agile, without going into how it translates into a day to day practice.  So, what do you do once you buy into the principles of agile software development?  Get ready for some rules.

(Disclaimer: If you’re at an organization that’s ready to take the plunge into agile, please please please don’t use this blog as a guide.  I will present an incomplete list of things we’re doing, which is an small subset of things we ought to be doing, presented by a guy with a teensy tiny knowledge of the full canon of agile practices.  If you want to do this right, read Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin, and The Pragmatic Programmer, by Andy Hunt, and Dave Thomas.  Or even better, go to Ann Arbor and learn it from the badasses at The Menlo Institute.)

Finished the Foundation by chaim zvi

Finished the Foundation by chaim zvi

(Also, read Getting Real by the folks at 37signals.  Please, just trust me on this one.  It’s important.  Much more important than reading this silly blog post, that’s for sure.)

At the beginning of this project, I presented to the team a set of rules by which we all need to abide.  The following is a subset of those rules regarding our weekly schedule.

  1. We will scrum every morning.
  2. We will work iteratively, regrouping and correcting our course once a week.
  3. At the end of each iteration, we will have built and deployed a working piece of software.
  4. At the end of each iteration, we will demo our work to the entire team, including stakeholders at the client.
  5. Following an iteration, we will gather feedback from end users, stakeholders, etc., and we will adapt.


A scrum is a five-minute long, stand-up (no sitting!) meeting with everyone on the team in attendance.  (Not just the worker bees.  The boss.  The client.  Everyone.)  We go in a circle and briefly recount what we accomplished in the previous day, and what we will to do today.  Keeping everyone in the loop might be the most important thing we can do to make this work.


We work in iteration: tight, discrete chunks that usually a week or two, tops.  This way, there is always a working product, just in varying stages of completion, that can be loved, hated, and rated by the folks who matter most: the users.  (Software joke: Name the other industry that calls its customers “users.”)

This is also about keeping everyone in the loop, but we work this way for many other reasons.  It makes it much easier to change direction.  It prevents the development team from bullshitting everybody else.  (Sure.  It’s practically done!  All we’ve got to do is write the code!)  And it lets the stakeholders (client, instructor, your boss) see what they’re getting for their investment of time and/or money.

Our schedule

We meet Tuesday thru Friday.  So we’re doing 4 day iterations (pretty short, but we’re making due with what we’ve got) resulting in a weekly schedule for everyone on the team that looks like this:

  • Scrum, 5 minutes, 9:30 a.m. Tuesday thru Friday
  • Iteration Kickoff, 30 minutes, 9:35 a.m. Tuesday, following Scrum
  • Iteration Review, 1 hour, 11:00 a.m., Friday

All other meetings will be held in accordance with the rules defined in Getting Real: Meetings Are Toxic (<– click this!):

For those times when you absolutely must have a meeting (this should be a rare event), stick to these simple rules:

  1. Set a 30 minute timer. When it rings, meeting’s over. Period.
  2. Invite as few people as possible.
  3. Never have a meeting without a clear agenda.

So, that’s it for today!  Stay tuned for more on our agile process.  Next week: how we break down big scary problems into little tiny problems that aren’t scary at all.

Team Crunchberry has adopted an agile software development process.  I’ll be writing about our process and sharing the outputs here on the Crunchberry blog every week.  But before I get down to business, let’s talk about agile.

Au Lapin Agile Fence by daveknapik

Au Lapin Agile Fence by daveknapik

How we did things back in the day

Traditionally, the software development process looked something like this:

After realizing that you need some new software, a team of ambitious people spend a long time, say, 6 months, writing a functional specification.  That is, a fat, three ring binder describing exactly what the software should do.

Then they hand the binder to another team, the developers.  (They’re the unusual chaps who don’t leave their caves much, but who hold the magic keys to make the computers work.)  They spend a long time, say 6 months, translating the functional specification into a piece of software.

They then hand the software back, a year after it was first conceived.

“Life moves pretty fast. If you don’t stop and look around once and a while, you could miss it.”

What can happen in a year?  Twitter catches on.  The stock market crashes.  Your competitor releases a new product.  A new congress is elected, and they change the laws.  It’s discovered that margarine is healthier than butter.  Your business model becomes obsolete.  And you’ve invested nine months in a product that nobody needs anymore.

And let’s just say that you’re living in a time warp, and the world remains completely static, who’s to say that you even got the requirements right in the first place?  If you’re wrong, you just invested a year of work in a system that doesn’t work for your users.

What is agile?

Agile software development is about accepting that it’s impossible to design up front.  It’s a tough idea to shake, but by embracing the chaos, you save yourself from perfectionism.  You’ll never get it perfect.

A common misconception is that agile is a free-for-all, anarchy even.  How can you develop without a plan?  Oh, there’s a plan.  Agile development is very strict.  Everything but the requirements is super tight.  Only with discipline, can you become free.

With agile you plan less up front, and correct your course along the way.  You design a little bit, build a little bit, test a little bit, and then look up.  Are we still on course?

(Though when a team tries to do a few things agile and skip the hard stuff, you gain little, and often get anarchy.  For instance, if you design and build in short cycles, but don’t ever ask a user what she thinks, how do you know if you need to correct your course?  It’s no better than the old way.)

There are many schools of thought on the correct rules for an agile team, but they’re all based on a basic set of principles.  In my next post, I’ll describe what we’re doing to be agile.  (And if you’re dying for more reading, the wikipedia (of course) has much much more.)