For Programs, Short is Beautiful

In my talk, How Much Will this Project Cost? at Agile 2012 last week, I got to say, “Short is beautiful.” For those of you who have never seen me, I’m five feet tall.

The question was something like this: For programs, don’t you want longer iterations, so people don’t have the overhead of planning, of retrospectives, of demos, of all of that?

Note: when you hear the word “overhead,” you are hearing someone who has not yet fully transitioned to agile. Overhead is code for “we have impediments and we don’t yet realize what they are, so we are calling them overhead.”

For programs, since you have many teams, you want shorter iterations and small stories. Why? To make sure you have as many interconnection points with the rest of the feature teams as possible. You want to make sure you integrate often and demo informally to anyone who will watch. Why? So you can get feedback and make sure you are on the right track.

For programs, the risks are too high to have longer times between integration points and demos. Waiting too long increases potential delays which increases risks. You have many people on a program. You want to see that they are all working together, so you want to see that their work comes together as often as possible.

At Agile 2012, Esther Derby talked about scaling agile teams being like a network. When you have networks of people and teams, you don’t always need formal communications. You know the rumor mill in your organization and how well that works. The information on it might not be so good, but the rumor mill itself works quite well. That’s exactly the model you want in programs. Small pods of people who connect with small pods of people frequently. Short iterations, short stories, that connect often with each other all over the place. (I don’t care if you work in flow. I’m using iterations as an example.)

These reasons all add up to “Short is beautiful.”

I gotta tell you, I was thrilled to be able to say that in a talk. I almost did a happy dance.