Maintain An Even Strain.

I was in interation meetings today. On the whole it's a lot of fun. I enjoy seeing the demos of completed features, the estimating (well, sometimes), and the customer's selection of stories.
In the course of a discussion there was a recollection. I don't know if it was original or whether our friend Na'im was quoting someone else when he said that Agile didn't reduce the pain of software development, it just spread it evenly. True enough. Developers work hard, while the decision-making pain is spread to the customer. Each iteration's expected velocity is the prior iteration's actual velocity, so each iteration is as hard as the one before it. The feedback loop is so much shorter, so that problems arising from the use of the system (including the pain of having a bad or insufficient requirement as well as the pain of change when a tool's existance demands a new process) are experienced sooner by the customer, and continually. All of the disruption from building, releasing, and deploying a program is felt every time. There is a general restriction against overtime so that the amount of work you can do is kept a bit more constant. There is also the continuing pressure to produce and to make/keep the code base clean. Estimation, measurement, all commences and continues. The process is small and iterative, and the pace is smooth in its way.

I asked one slightly sneaky question, in order to determine whether the customer felt that they were really in control of the process, or whether they felt that it was something that happened around/to them. I was delighted with the answer, which indicated that they very much felt that the project was in their control. It was a good moment as well.

In the movie The Right Stuff I recall repeatedly hearing the phrase "maintain an even strain." I think it's a good analogy for what Agile is doing. The strain is spread out across time, and across the participants.

As I learn more about the techniques and principles, I start to remember my meager acquaintance with Deming's methods. I remember that the first step is never to optimize, but to measure and assess. You get a more even strain. Once you have basic measurement of your products and process, then you can make deliberate and measured changes. It's funny how the idea of "software factory" has found its real expression in the agile processes.

I was also remembering a friend named Ray who was involved with QA. He once told me (long before XP first twinkled in its first eye) that the thing necessary to move software quality forward was "executable specifications". We lived through the whole CASE fiasco, and here in agile methods we find ATs and UTs are the very thing that Ray had hoped for at least a decade ago. I hate to load up on advocacy here (nobody comes here unless they're at least partly indoctrinated), but I have to think that we're heading in the right direction. We're following what so many of the best and brightest really intended or wished for a long time ago.


!commentForm