Saturday, July 15, 2006

The 5C's of Agile SCM

Lean has it's 5S technique. And while Im certain there's a way to translate those into SCM terms (which I may try and do someday, if someone hasn't already), I'm thinking about five important C-words for Agile SCM:
  • Correctness -- the property that the current configuration of the codeline executes correctly and passes its tests.

  • Consistency -- the property that the current configuration of the codeline builds correctly

  • Completeness -- the property that the curent configuration contains all that it should, builds all that it should, and tests all that it should

  • Cadence -- the property that the codeline has a regular rhythm/heartbeat/pulse that represents a healthy flow of progress (and creates a new resulting "current configuration" every time a new change is commited, integrated, and "promoted")

  • Collaboration -- the property that the balance of the above achieves a productive and sustainable degree of collaboration that serves as the source of value-generation
I think that the above represents all the properties that need to be present to a significant degree in order for the codeline to achieve smooth flow and accumulate increasing business value at a steady rate.

Am I missing anything? What about Concordance (via audits or with stakeholders)? Or Customer? Content? Context? (dare I use the word "Control"?)


Unknown said...

Excellent idea! I've thought of a few other ones:

- Constant Change, or Continuous Change
- Collaborative Communication
- "Clockwork Cycles" instead of Cadence
- Clarity of Configurations, or Clear Configurations

Consistency and Completeness may be considered as attributes of Correctness. I propose to make it one.

Completeness is even arguable, as Agile means we strive for minimum, sufficient and necessary functionality

Clarity of Configurations means that it must be simple and understandable which configurations are where, and what is in it. Beit workspaces (sandboxes), test systems, proto rigs or production systems, it must be clear and simple to be Agile.

Brad Appleton said...

Hi Frank and Dave! Thanks for the comments.

Dave, I very much like your idea of Continuity. I think it relates to "availability" as I referred to it in a subsequent blog entry on codeline flow, availability and throughput. I think Frank is perhaps getting at the same think when he writes of "Continuous Clarity."

Frank, regarding "complete" being perhaps more "big-up-front" than "agile", I think that's not a problem the way I described it because it's more about being holistic or "whole" as opposed to parts (e.g., preferring full-builds to partial builds, and running all the tests over partial-testing).

Complete in this context means "whole" rather than "done" or "all up-front" (perhaps Completeness is slightly better at indicating the meaning of both "necessary" *and* "sufficient").