« When research worlds collide.... | Main | Can you get by for a week with just an iPhone? »

November 13, 2008


Barry Baker

Could you please expand on your definitions a bit? In particular, please explain your distinction between formality and ceremony. To me, "ceremony" is a loaded term often used by "agile" proponents bludgeon processes that don not meet their "agility" standards. Sometimes people classify work byproducts of a development process that do not get seen/used by the end user as "ceremony", while I've also heard others talk about the steps taken to do hand-offs between groups of people/teams as the "ceremony".

A formal process is a mature process composed of proven development practices. However, there are no artificial process gates in place that strictly govern the process. Formal processes rely on the professionalism and discipline of the team to ensure the right thing gets done at the right time. A ceremonial process is a formal process that strictly governs what is done and when it is done. Ceremonial processes are typically marked by milestones (ie. the artifical process gates) such as requirements complete, architecture complete, design complete, etc. Usually, each of these milestones is reached when some artifact is created and signed.

In the original post, the ceremonial aspect of the example is that customer sign-off is required before development can commence. The two samples you cite (work products not seen by the end user and steps taken to hand-off) aren't necessarily ceremonial unless done only to comply with process.


Would suggest that blanket dismissal of ceremony may be too critcal an approach. While the informality of agile processes is admirable, and works well in many environments, it has drawbacks in large projects, and sometimes in those for which software correctness and reliability are primary requirements.
In the latter case, formally mandated checkpoints and formal documentation of accomplishment of specific DT&E objectives may be essential to meet safety, reliability, and legal requirements.
For high-reliability and life-critical projects, the additional formal documentation of specific reviews, checks, and double-checks, while it doesn't guarantee completeness, can go far towards ensuring that processes intended to capture and correct the inevitable human errors and oversights are completed.
For large projects, the likelihood, and the absolute quantity, of defects is greater, due to the greater variety of skill levels associated with a larger workforce and the greater variety of novel problems and unforeseen interactions. In these cases, no one manager, or single small team of managers, has the span of awareness and authority to informally assure a disciplined DT&E process. 'Ceremony' may be essential in verifying that essential team interactions and processes have been accomplished.

Agreed. In some cases ceremony may be necessary, including if the team lacks the discipline.

I saw a definition of ceremony that I thought summed it up well, I believe from Alistair Cockburn. "Dogmatic application of SDLC practices without thinking through whether a specific practice makes sense."

One last note about your most recent comment...I'd argue that agile done right is very formal, but avoids ceremony.

Barry Baker

...I'd argue, because I've seen it, that other processes, include waterfall, done right can be very formal, but avoid ceremony...

How is the completion of a time-boxed iteration not a milestone, especially if you are letting end users get their hands on it? How is the completion of time-boxed iteration not "a formal process that strictly governs what is done and when it is done"? This sounds like ceremony to me as you describe it.

The comments to this entry are closed.

  • Burton Group Free Resources Stay Connected Stay Connected Stay Connected Stay Connected

Blog powered by Typepad