Standard. Methodology.

Professions establish vocabularies. After achieving consensus about definitions, professionals can communicate more precisely and quickly. I offer some candidates to our professional consensus here on terms for software development projects. What would you change here?

Let’s agree with guidance from the American National Standards Institute (ANSI®), quoting a joint standard of the International Organization for Standardization (ISO®) and the International Electrotechnical Commission (IEC®), that a standard is, “A definition or format that has been approved by a recognized standards organization or is accepted as a de facto standard by the industry. (As defined in ISO/IEC Guide 2:2004)”.

I suggest we consider a methodology to be the specific set of training, development processes, tools, templates, and controls a particular software development team uses to structure its work. A methodology includes reference (as needed) to specific tools, communication channels, approval meetings (and lists of attendees appropriate for each), document templates, development languages, and responsibility assignments. Harold Kerzner used the phrase “forms, guidelines, templates, and checklists” during his May, 2007 Omaha presentation advocating effort to detect and document best practices.

There is power in the statement that by this definition, a methodology is a company standard, with corporate leadership taking the role of “recognized standards organization”. Following the lead of the ANSI guidance about standards, I focus here on industry standards.

That definition doesn’t specify that a methodology is documented. (This is the “you cannot not have a methodology” argument. You might not have a repeatable or consistent methodology…) As team sizes and project sizes grow, my impression is that few experienced professionals on either side of the waterfall/agile discussion would recommend no documentation of the methodology.

Many of the agility models (the Agile Manifesto®, in fact) advise caution about excessive documentation. I agree. I have seen methodologies that seemed to have everything “plus the kitchen sink” in them. They were hard to understand and so difficult to use that teams did only those parts that were well enforced. After some point of growth, it makes sense to require that for everything added, something must come out of the methodology. Simple is better. Focus is great!

Examples:

  • The Project Management Institute (PMI®) publishes the PMBOK® Guide as a standard. At one point in its history, many project managers considered it a standard because they accepted PMI as “a recognized standards organization” (from the definition above). I hope that’s still true today (grin). Many people outside PMI probably consider it more powerful today that ANSI listed the same document as a U.S. standard (ANSI/PMI 99-001-2008®) and that IEEE® listed the same document among its standards (IEEE Std 1490-2011®).
  • A company’s methodology is the collection of policies requiring particular practices (perhaps requirements to use particular templates for documents; perhaps requirement to use a particular inter-project corporate-level shared resource for change management or version control or lessons learned (or other); perhaps in a waterfall environment, requirement for a phase-end tollgate or phase review (or any of many similar terms); perhaps in a Scrum environment, a requirement to use a Daily Standup and a Product Backlog).

Non-examples:

  • No company’s methodology is an industry standard, if only because it depends on tools, databases, training, and past shared experience not available outside the company.
  • No standard is a methodology. (Ever read a job ad stipulating that successful applicants will “use PMI methodology”? At one level of precision, that sentence means little!)
  • “Agile” and “agility” are not methodologies. (Recently I heard Susan Courtney (of Nebraska Blue; Apr 2012 AIM Institute Technology Leader of the Year) forcefully and committedly advocate agility and suggest (about software development life cycles, SDLC) that companies don’t understand agility if they want to “implement a new SDLC called ‘Agile'”. I agree with her; a company needs to change more than the SDLC to increase agility. Agility depends on a wider and deeper partnership than that. And provides more benefits than just an SDLC change.)

Between the concepts of standard and methodology is a set of guidance generally not as accepted as a standard or not as specific as a methodology; some call this group models or methods or frameworks or processes. There is considerable variety in the terms used (example). Let’s use model here, though it’s not a perfect label for this group.

Models help us select methodologies. Though the following is a (very!) partial list, examples include:

  • The original paper about waterfall. In my experience, it’s very common to hear reference to “the waterfall model”. (Interestingly, Royce didn’t use the word waterfall, though his central diagram clearly resembles a waterfall. This paper makes a strong point about the need for adequate documentation in a software development effort.)
  • Mary and Tom Poppendieck’s 2003 book, Lean Software Development, An Agile Toolkit (ISBN 0-321-15078-3). (This is a valuable contribution to software development thought and arguably had the most pivotal early impact in associating the concepts of Lean manufacturing with software development.)
  • The PMBOK Guide. (Though also a standard, it provides much of the detail typical of this middle group and allows considerable latitude in implementing company-specific details. Far more than not, agility models are consistent with the PMBOK Guide. The Fifth Edition of the PMBOK Guide is due out in 2012/2013; I’m betting agility models will have lots of impact on the new edition.)
  • The Scrum Alliance® summary of Scrum. (By the same token, I acknowledge the power to the statement, “That’s a standard! The Scrum Alliance is the “recognized standards organization”.)

How best can we make use of these concepts? Here’s one vote for our teams (maybe our companies; in the ideal world, teams have a role) using guidance from standards and models to define everything we need in our methodology (and not a bit more!) And applying the specificity that distinguishes a methodology from a standard.