How Do You Define "Finished"?

From Project Manager 97Things

Jump to: navigation, search

How Do You Define “Finished”?

Brian Sam-Bodden Scottsdale, Arizona, USA

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 the customer expectations. However, to define total project success we need an accurate, shared definition among the larger project team regarding 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 which passes unit tests, possibly clears limited integration tests, and allows promised software features to be demoed 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 non-programming 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 new component/feature created 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, 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 build-up of those missing items per iteration can alter the way a feature is implemented, tested, and perceived by the customer.

Let’s not over-burden 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”.

Personal tools