No, not the book and personal productivity method by David Allen, though somewhat related in intent. I’m talking about getting things done in software development.

Traditional phased software development processes tend to have a long delay between starting to work on something, and having something working that people can use. During this time, there may be a lot of work expended on partial products and artifacts to support the process, but little or nothing that could be used for its intended purpose.

Both timebox-oriented [e.g. Scrum] and flow-oriented [e.g. Kanban] methods try to emphasize getting things done so that they can be used earlier and provide value. Even if you decide not to use them earlier, at least they can be evaluated for suitability of the intended use, and progress toward a larger collection of functionality that will be deployed for use together can be more reliably tracked.

The strategies for getting things done vary.

The use of timeboxes provides impetus to slice the work into small slices so that multiple of these slices will fit within a fixed time period. This allows tracking progress within the timebox, as well as across timeboxes.

If all of the slices of work become usable at the very end of the timebox, then the visibility of progress within the timebox will be nil. The risk that they won’t be done goes up. We have to take it on faith that they are progressing. We may end up with all of them partly done. Or, better, we can limit the number of slices we work on at one time. If multiple people collaborate on one slice, we can get it done and usable before starting the next. Then our risk is reduced. We risk having some of the slices not done, but not all of them.

It’s possible, but not advisable, to break the work up such that accomplishing an explicit piece of it does not result in usable functionality. I’ve seen people create analysis, programming, and testing “user stories” that defeat the purpose of routinely getting functionality done.

When we work in a flow-based model, we explicitly limit the work in progress (WIP) at each station in the flow. This does not necessarily get working slices done and ready to use more quickly, but it does make bottlenecks and buffers more visible. Dealing effectively with the bottlenecks and buffers should help improve the lead time for the work item. If you find yourself blocked by an output buffer full to its WIP limit, or starved by an empty input buffer, you can collaborate with the bottleneck to alleviate the situation. You can also arrange the work flow so that there is not a correspondence between people and activities, so that collaboration is normal even without flow blockages.

It’s possible, but not advisable, to have enough work steps and large enough WIP limits that you don’t improve the cycle time of producing working slices. Often people select a measuring cadence to check that functionality is routinely getting to done and guard against long cycle times.

Whether you emphasize the cadence, and make WIP limits secondary, or emphasize the WIP limits, and make the cadence secondary, success at Getting Things Done usually depends on paying attention to both.