Efficiency in an iterative mode of working requires that we have little overhead in all our processes. For example, if building a release candidate takes us several days of manual work, we will have a hard time working in two week iterations, since so much of the iteration will be consumed by release work. Add to this slowness in detailing specifications and test cases, and we’ll get even less product created in the iteration. Then add cumbersome and manual design/coding (developers have not yet learned how to utilize whiteboards to visualize holistically, and refactoring tools to fluidly change the source code), and we start to understand why so many development organizations have a hard time adopting iterative modes of development.
What to do? Well, for starters, maybe we can try to look at our organization and how we work, and see where the time goes. Create an overhead scorecard, a simple table outlining how long activities take. Or try the value stream mapping technique, in an attempt to really nail down how you spend your development time.
Then, attack your worst bottleneck. And, no, you do not have to be an expert in theory of constraints or some other thinking technique. Just scrutinize your own behaviour, and do something about the things that look bad. The need for this way of approaching challenges is, paradoxically, becoming greater and greater in the software industry as ideas about new ways of working spread. I see lots of people interested in learning about things like Scrum, lean, theory of constraints (of which I know very little myself), test-driven development and so on, but when it comes to going home to your back yard and do some cleaning up, many fail.
So: try approving a bit, pluck some low-hanging fruit (there’s typically lots of it). When you start to see the limits of this simple approach, go ahead and learn about advanced techniques. There’s lot to learn out there, but you don’t have to know it all to be able to improve.