How Do You Define "Finished"?

It is hard for a software development team to succeed if there isn't a clear definition of what success means. For developers, success entails delivering a product that meets customer expectations. However, to define total project success, we need an accurate, shared definition among the larger project team of what it means to “finish the project.”

To embrace the overall project scope, the core tenet of traditional, iterative software development is divide and conquer. The project is broken into deliverables, which are then divided into work packages. Those are ultimately broken into activities assigned to a specific person.

Using an agile approach with one-to several-week iterations, or work periods, the necessity to consider overall project scope can be masked. Finishing the goals of one iteration can be clearly set out as creating working software that passes unit tests, possibly clears limited integration tests, and allows promised software features to be demo'd to the stakeholders for their approval and feedback.

The problem is that at the macro level, a project has many other considerations beyond the code and its accompanying tests. Using the traditional waterfall method, testing was relegated to the end of a project and became a flaw in the process. In a more agile approach, developers may erroneously defer or dismiss all the nonprogramming items or activities as not having a place in their view of what a software project entails.

Some of these items may be unit and integration testing between a newly created component/feature and the components/features created in prior iterations.

These often-overlooked integrations underscore a fundamental problem for development teams. The complexity of software seems to be geometrically proportional to the number of component interconnections. Don't ignore the time needed to craft a demo environment, and do write user-level/acceptance testing scripts and create accompanying documentation. No matter how light your methodology, shippable software requires a certain level of documentation.

When these items are not ignored, the macro definition of what it means to be “finished” differs significantly from the accumulated finishing of a set of features within an iteration. And, the delta created from a buildup of those missing items per iteration can alter the way a feature is implemented, tested, and perceived by the customer.

Let's not overburden our developers with administrative or business issues. The underlying concept we need to spread is that iterations are not just for software developers. They must be coordinated with tasks important to the larger, general software project team members. Business analysts, software project managers, and quality testers must coordinate their crucial activities with those of the developers.

The person responsible for this coordination is the software project manager, who must understand and spread the overall definition of what it means to be finished at the macro level so that the non-code-based activities are performed side by side with the weekly iteration work. The project manager must be the arbiter between the development team and the other stakeholders to define what it truly means to be “finished.”