Methodologies across the Organization

Notwithstanding the appropriateness of extracting the project management strategies from the corporate methodology, and the recognition that some tailoring is needed within each project, executives quite reasonably want their projects to have some conventions in common. They want people to be able to understand what is happening when they transfer to another project. This requires having some conventions across the organization:

• Definitions of common vocabulary. People need to be able to understand each other. They need to understand just what is meant and what variations are allowed by particular phrases. For example:

  • Does iteration only mean "planning window," or does it mean that code is also written and unit-tested or even integrated, tested, documented, and ready for deployment?

  • What is really supposed to happen in an iteration planning meeting? Is the demo to the customer supposed to happen inside that meeting or before it? Are the user stories supposed to be written before it or during it? Does it contain design discussion, or is design done later?

  • What does delivery mean? Does it mean real deployment to the full user base, test deployment to a friendly user, or deployment to a machine in the test department?

I was called in once because every team used those terms differently, and they could understand neither what other people meant nor what they were doing on their projects.

• Definitions of common formats. While two teams may not have to create the same work products, it is useful if they use common formats for whatever work products they do have in common.

  • Every project should probably have a vision and scope document.

  • Every project needs a way to report its status. Finding ways to represent status for all possible projects is very difficult (see "A Governance Model for Agile and Hybrid-Agile Projects" (Cockburn 2005c) for a progress-reporting format that covers a lot of projects).

  • The Unified Modeling Language (UML) is a common language for drawing a domain model or sequence chart. The organization may add rules for how those models are presented (naming conventions, complexity in a single drawing, use of vertical and horizontal placement, and so on).

• Communication requirements. The testing and marketing departments need advance notice of upcoming product releases. The organization may set policies in place about how much advance warning they get ("two months"), how reliable the schedule should be ("when the schedule is estimated to be within 10% accuracy"), and what sort of information they are to be given.

• Baseline project management strategies. The organization may require every project to run an Exploratory 360° (see Cockburn 2005a) before receiving committed funding. It may require each project to deliver system increments to real users every three months or less. It may require automated testing and perhaps test coverage policies. These policies may be challenged on a project-by-project basis.

Among the strategies most often mistakenly put within the methodology are the sequence and timing of gathering information. It is common to require that all requirements be gathered before any design is done, or that all user interface design be done before any software architecture is done. By now it should be clear that any strategy calling for "all-of-one-before-another" has severely limited applicability.

Even sophisticated developers and managers fall into this trap. In teaching how to write use cases, I describe how to select what to write and the format in which to write. Peopleeven experienced peopleimmediately jump to the conclusion that I want all of the use cases to be written before any design is done, or that each use case should be written to completion at one time. Neither is true.

The choice of how much of one use case or how many use cases to write at one time should be reevaluated continually during a project. The alert team will come up with different answers at different moments on a project and certainly different answers on different projects. This is in keeping with the cooperative game model.