Agilely over the Waterfall

I assume you are following some form of an agile development process because I haven't met anyone in the past two years who doesn't say they are. Even with stand up meetings, backlogs, and burn down lists, many Systems Engineers and Software Engineers still develop following a waterfall like process. They build all the specification/code at once, THEN compile and test it. There is an easier way.

Instead of completing everything in one fell swoop, focus on creating working code or a verified specification model. I find it must faster to perform many, short, micro-cycles of design/build/test instead. Remember, I think in pictures, so the steps in my micro-cycles are diagram related:

• I create a use case diagram (or augment an existing one) to specify the new functionality. I refine the use case with an activity diagram or step-by-step instructions. This step ensures that I've thought about all of the needed interactions and services before moving on.
• Next, I add the structural items (classes or blocks) to the code/model. A class diagram (software) or block definition diagram (Systems) shows the existing structure. I decide to whether to add the functionality to the existing constructs or if I have to add new ones. Often, the new functionality is spread out among many classes or blocks, and thus I'm required to create operations in both new and existing classes/blocks.
• Most of the code I write is event driven. A state chart diagrams tied to the classes/blocks represent most of the behavior of that class/block. I define the states, transitions, and guards. Frequently, I'll identify additional operations that create the triggers to move between states during this step.
• Sequence diagrams identify the interactions between the structural elements. These diagrams help me keep the call order straight and create the needed operations. New operations begin life as stubs. Once I know the call order is correct and the state behavior is correct, I complete the operations, one per micro-cycle.
• Compile, debug, test
• Repeat

HERE'S THE KEY -- I don't build everything at once. I only work on one operation at a time. In fact, I often only build a small part of the operation with each micro-cycle. To assist the effort, I create stubs that return constants (or output strings) for each called operation. I also create temporary drivers that call the operation on which I'm working to make sure it computes and returns correctly.

This method is quick, agile, relatively painless, and easy to understand. No pictures needed!