Lean CM

I found a couple of great resources on Lean CM that are very compatible with the article we wrote last month on Lean-based Metrics for Agile CM Environments.

• Lean Configuration Management – Supporting Increased Value Delivery from Agile Software Teams
  by Jens Norin and Daniel Karlström, in the Proceedings of the 6th Conference on Software Engineering Research & Practice in Sweded (SERPS'06), October 2006 (and also in September 2006 as a Softhouse Whitepaper on Lean CM)
• Gain flexibility & speed with Lean CM
  by Joe Beckett, Plant Magazine, June 2005

I've added these and some others to the list of Agile SCM Articles on the CMWiki.

Defining Agile SCM

The May issue of the CM Journal is devoted to the theme of CM & Agility. Myself and Rob Cowham wrote an article for it entitled Defining Agile SCM: Past, Present and Future.

In our earliest articles on the topic, we defined Agile SCM as "the pragmatic application of sound CM principles & practices in accordance with Agile values, using Lean thinking, to serve the needs of the business!" We wish to elaborate what that means in terms of SCM for Agile development, but even more importantly in terms of how we should apply Agile, Lean and their related principles to SCM processes and procedures.

Basically, we try to emphasize that Agile CM is more than just CM for Agile projects, it also means making CM itself be Agile and using the principles tools and techniques of Agile, Lean, TOC (and even some Six Sigma) for CM. Give it a read through and then give us your feedback!

There is also (finally) a new forum on CMCrossroads.com specifically for Agile CM. Of course one of the discussion topics is "what is Agile CM?" and a lot of detractors saying there is no such thing - that it's just plain old CM for Agile projects and that CM is still CM. I contend it ain't the same old CM, and that Agile CM does more than simply apply classic CM discipline & principles to Agile projects, it also applies Agile/Lean principles, tools and techniques and is just as different from traditional plan-based CM as different architectural styles.

Five R's of Agile SCM Baselines

Almost a year ago I posted an entry on the "5 C's of Agile SCM Codelines". This time I'm posting on the 5 R's of Agile SCM Baselines. I think these are as follows (note that most of these are not unique to Agile/Lean):

• Repeatable -- The steps to create the corresponding Build (Configuration) from its sources should be repeatable: for any baselined configuration, I should be able to build it the same way, over and over again.
  


• Reproducible -- The corresponding Build (Configuration) should be reproducible: for any baselined configuration, I should be able to reproduce it whenever desired.
  


• Reportable -- The corresponding Build (Configuration) should be reportable: for any baselined configuration, I should be able to report all needed details about its content: what files & versions are in it, which changes/requests are in it, who made which change to what (& when), how it was built and with what tools & options, etc.


• Releasable -- The corresponding Build (Configuration) should be releasable: if I have "baselined" it, then almost by definition, it means it should be of 'releasable quality' to the next downstream consumer. (This implies it should be correct + consistent + complete to the extent agreed upon with the its stakeholders.)


• Repairable -- The corresponding Build (Configuration) should be readily repairable: if, for any reason, it is discovered to have some kind of problem, then I must be able to readily repair it either by retracting it and replacing it with it's predecessor, and/or by removing/repairing the offending content and releasing it as a new (corrected) baseline.

I use the term "reportable" instead of "traceable" here for two reasons: 1) 'traceable' doesn't begin with 'R', and 2) 'traceable' brings to mind many negative associations with manual tracing, rather than simply providing the necessary transparency and ability to trace (without necessarily implying doing all that tracing, much less doing it all manually).

Note also that "repairable" may not imply that the cost of repair is low. Ideally, the repair can be done as quickly as possible by the development organization, but getting it to the consumer(s) may be both costly and time-consuming. So, rather than "low cost", being "repairable" speaks more to maintainability, and the ability to quickly understand the system and what must be done to repair it. We want to repair it with minimal interruption of flow, and with a minimum amount of overhead.

Why is any of that particularly "agile"? Most of it isn't, but the 'take' on reportability certainly is, and the notion of "releasable" may seem agile to those who feel the codeline should (ideally) be in a readily releasable state. CMers would say that "releasability" was always part of what a baseline requires (and they'd be right).

What do you think? Did I miss any other important R's? Or should something else be used instead? Would an additional R-word or two not listed above help differentiate between "Agile" CM versus more traditional CM?

Here are all the other R-words I considered:

Recoverable Reliable Reversible Retractable Retainable Realizable Relocatable Remediable Repealable Replicable Revocable Relapsable Rebuildable Recapturable Reconfigurable Reconstitutable Reconstructible Recordable Recyclable Referable Retrievable Reusable Restorable Renewable Replaceable Representable Respectable Responsible Removable Reachable Readable Receivable Reclaimable Recognizable Recommendable Reconcilable Recreatable Remissible Rectifiable Recuperable Redeemable Reducible

If anyone cares, I looked it up at Dictionary.com searching for "r*ble"

Software CM is Not a Process!

The (hopefully) provocative title of today's blog-entry is inspired by Phil Armour's essay "Software is Not a Product!", which is one of many profoundly insightful essay's from his book The Laws of Software Process.

Armour maintains that:

The core issue with the business of software is that we misunderstand what software really is. Software is thought of as being a product, it is looked at as being a product, it is mostly managed as if it were a product. But it's not a product... The hard part about creating software systems is not creating them, it is in acquiring the knowledge necessary to create them (correctly).

Therefore:

Software is not a product, it is a medium for storing executable knowledge.

Our lack of understanding of this basic fact is one of the key issues facing the software industry. We do not "build systems"—we acquire knowledge. The systems we ship to our customers are actually the byproducts of the real activity, which is to learn.

The business imperative is that the real product is the knowledge that is in the systems we ship to the customer, and we don't manage that at all.

So today, I'll attempt a similarly-themed "riff" about Software CM, beginning with the assertion that Software CM is not a process!

This assertion might seem shocking to some. Other CMers might say they have known this all along, saying CM is a discipline (rather than a process), and that numerous formal definitions of SCM have said this for quite some time: SCM is a "discipline" that "governs" or applies "technical and administrative direction and surveillance" to the functional components of CM (item identification & planning; item storage, versioning & change control; status accounting, audit & review).

If software is a medium for storing executable knowledge, and software development is a knowledge acquisition & creation (learning) activity, then the result of software CM is the medium through which software development changes and collaborative learning must ultimately flow.

If the result of software CM is a medium for the conveyance of changes by executing the knowledge gained from learning, then software CM itself must impose some form of order (structure & rhythm) to achieve this resulting collaborative flow of change-flow.

For me, terms like "order" and "structure" evoke memories from my years participating in the software patterns movement and study+discussion of the works of Christopher Alexander. For Alexander, patterns were all about discovering the innate order in structures that emerged naturally from the recurring attempt to resolve (trade-off) the same set of competings concerns (forces) for the same problem in the same/similar contexts. The resulting structures and their sequencing and interaction is what all comes together as an overall (emergent) architecture.

Hence, I would say that Software CM is an emergent yet intentional architecture that ensures the orderly, efficient flow of software development change & collaboration.

The elements of this Software CM architecture include practices, tools & technology, teams & organizations, valued deliverables & intermediate work-products, changes to and assemblies of these deliverables & work-products, and the set of needed status/tracking reports & measures.

Hmmn, this fits in rather nicely with my 4+2 Views of SCM/ALM Solution Architecture and perhaps even does a good job of tying together SCM with Agile/Lean (collaboration & flow), and software patterns (particularly SCM Patterns :).

So there you have it:

Software CM creates the medium through which software development changes & activities must flow. Therefore, Software CM is the intentional architecture of software development change-flow.

What do you think?