In my last post, I talked about the importance of focus. Nowhere is focus more needed than on Agile projects, where change is king. I particularly recall an excellent article by one of the Agile founders, Jim Highsmith, where he talked about Oscillation vs. Iteration.
As Highsmith pointed out, with short iterations and close customer interaction, it can be tempting to switch gears more than once. In fact, in some Agile projects, the gears are switching constantly. The customer keeps changing their mind. Multiple customers chime in with different needs. An emerging business imperative forces a change in tactics. Or worst of all, you didn’t quite understand the need to begin with (or it wasn’t articulated well enough).
This is where I always point out the need to be an “anthropologist.” Using the Toyota’s lean manufacturing principle of Genchi Genbutsu (go and see for yourself) or Honda’s Sangen Shugi (“three actuals,” representing the actual place, actual product, and actual situation), you shouldn’t just assume that what a customer asks for is what they need or want. Go and see for yourself what the situation is. At the very least, you’ll have a better understanding of what they’re asking for.
Likewise, just because you have an iterative, Agile project doesn’t mean you shouldn’t have design guidelines or requirements, or even an understanding of scope. Agile doesn’t mean no planning or scope. It simply fixes the time and cost, and estimates the features and scope (as opposed to Waterfall, which does the opposite, estimating time and cost to deliver a fixed scope of work). With Agile, you’re estimating what can and should be delivered to meet a certain objective, both in terms of defined iterations and for the ultimate project (typically a targeted release).
But back to our oscillation discussion, Highsmith cautions that it’s not always easy to tell when you’re oscillating vs. iterating. For instance, if government regulations keep changing or there are legitimate learnings that dictate a new course, then it’s a normal part of Agile iteration.
In any case, the point is to be aware of when you may be oscillating, and if so, take corrective action before it gets out of hand. And to avoid unnecessary oscillation to begin with, be sure to gain an understanding of the goals and objectives of your initiative (seeing the situation for yourself where possible).
