For Agile Program Iterations, Short Is Beautiful
When talking with people new to agile about how much projects will cost, I've often heard the following question: "For programs, don’t you want longer iterations so people don’t have the overhead of planning, retrospectives, demos, and of all of that?"
(Note: When you hear the word “overhead,” you are talking with 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.”)
You might decide to measure run rate, the amount of salary and overhead the program uses every iteration or every month. That might keep the accountants happy. That also provides you the excuse to ask everybody, “You’re not working on any other project or program, are you? Because I’m taking your salary hit on this program. So if you’re working on something else, let me know!” Multitasking is a disaster on a program. It’s insidious and slows a program to a crawl faster than anything I know.
Because you have many teams in a program, you want shorter iterations and small stories. You want 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 so that 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, author and leader in retrospectives 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 other small pods of people frequently. That means short iterations and 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 my mantra: “Short is beautiful.” (For those of you who have never seen me, I’m five feet tall. So I love being able to say that!)
