ScrumAlliance ™

On the scrumdevelopment Yahoo! group, a discussion revolves around user group concerns over the trademarking of the phrase “Sc*um User Group.” (Note that I’ve starred the name in order to avoid trademark violations.) A few inquiries resulted in an official response from a Sc*umAlliance representative.

I find it odd that (a) no one belonging to the “Sc*umAlliance” (whoever they really are–I’m suspecting maybe Mars, but given their legal nature, maybe Uranus) frequents the scrumdevelopment group, (b) none of them chose to respond directly on the group once apprised of the concerns, and (c) Ken Schwaber didn’t have an immediate answer (regardless of his affiliation with the Sc*umAlliance). I suppose there must be people (lawyers, no doubt) who don’t have to be at all interested in the product they support, but it just seems wrong somehow.

Agile requires lots of communication and continual negotiation. Bits of command and control have their value at times, but in most cases C&C begins to eat away at the trust relationship required for continual negotiation. I suggest people considering or doing Sc*um dispense with the trappings of a trademarked process and look instead to understanding what agile is really about.

The progenitors of agile–i.e. the agile manifesto signatories–rightly eschewed “heavyweight” processes–processes centered around lots of documentation and meetings. I think there’s a new category of “heavy” that should be spurned, and that includes processes controlled by people so heavily wrapped up in legal and licensing protections that they can’t bother discussing changes with the community who would be affected.

Unit Testing Maturity Scale

  • Level 0 – Not Performed: Tests? We don’t need no stinkin’ tests!
  • Level 1 – Performed Informally: Test-after development (TAD). Sporadic coverage, individual-level process adherence.
  • Level 2 – TDD:
    • TDD Level 0: Chaotic. Some developers do TDD. Others don’t care if the tests break.
    • TDD Level A: Performed Informally. The team agrees that unit tests must pass in the build. Developers pick and choose what should be test-driven.
    • TDD Level B: Performed Consistently. All team members build unit tests. Some unit tests are not focused enough (tendency toward integration tests). Tests do not “document” very well. Sporadic production code refactoring enabled as a benefit of having tests.
    • TDD Level C: Breakthrough. Team members use each TDD cycle to refactor production code and tests, but constrain to single classes (test+target). Most tests clearly document class capabilities.
    • TDD Level D: Optimizing. Standards around test organization, naming, and structure are evident from the code. BDD in heavy use. Team actively looks for reuse across tests, and continually refactors “mother” and other test utility classes.

This is a work in progress! Please help me iteratively and incrementally improve it.

Atom